Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I very much doubt that leaders believes that developers should be involved in every conversation in the space for the majority of the day.

The funny thing is for software/tech companies they probably should be. The people who will be doing the work should probably have input into the work to be done at every stage of the process. Tech companies should value the informed input of the actual people who build their company.

But most leaders who value open plan offices see developers as unimportant ticket robots who take in JIRA tickets and output code and who need to know nothing about what exactly they're building.



You're right, teams should collaborate, but I've never been in a place-where only one team was in the space. It's a handful of teams from a bunch of practices all taking the same space.

I've never been in a company where the couple dozen people all on the floor are on the same project. I'd imagine even if they were there would be subdivisions there - do 30 people all effectively work on the same stuff?


I've been on projects of 100 developers all on the same floor. However the only way to sanely manage such a thing it break things into smaller parts. You then have a a bunch of small teams (around 10 people) that need to work together. When one person on your team says/asks something you should pay attention because it will affect you, but if someone on a different team says something ignore it.


Given that at any one time that means that at least 90% of the developers will be trying to ignore one or more conversations (while trying to work or having their own) it comes back to the question the intent of that space and if that's actually helping productivity.

Is that team of 10 collaborating and trying to ignore everyone else while doing so more productive in that space than they would be in their own team office or sets of offices? And are the other non-talking developers not being less productive because of the distraction? It doesn't take a lot of distraction for a team of 10 to drag down the productivity of the other 90 people into a net loss for the room.


LOL. Unfortunately what people say that you can hear can affect your team because of product interactions. And people tend to talk about other things than work. Additionally, they are often wrong which requires correction.


> Unfortunately what people say that you can hear can affect your team because of product interactions.

Absolutely. However that is a lot less common than things that you hear that don't affect you. If you want everyone to know everything than you can't have more than 10 developers - a team of this size (or slightly smaller) will be far more productive than larger teams because they know all the interactions - but the larger team because of the larger numbers gets more done at the end of the day anyway (and good architecture will minimize the interactions and thus help productivity)

> Unfortunately what people say that you can hear can affect your team because of product interactions.

When it is only a small number of people those non-work conversations make your teammates more human and thus gel your team and so are worth thee cost. However if the number of people is too large it is a distraction.

> they are often wrong which requires correction.

If they are your teammates you should be correcting each other. If they are not - you shouldn't be the expert in the subject and so you won't know they are wrong in the first place.


The problem with the model where everybody is inputting all the time, is that nobody is actually doing any of the work to turn that noise into product. It's not a sustainable model for actually accomplishing anything, unless you've got engineers taking things off-the-clock and turning that discussioning into code in the late night or early morning hours.

Been there, done that, it's not any fun, and a good way to get resentful and burned out. It's really helpful to formalize communication to a greater degree.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: