Indeed. One gig I was at consisted of spending 9-5 doing nothing but meetings/groupwork/collaborating/email and dealing with bosses who kept asking why the coding wasn't getting done and behind schedule in one breath while dragging me into a 3hr+ meeting the next. Getting work done meant getting in before the boss, coding as much as possible until the boss showed up, waiting for the boss to leave, then coding again for another 2-3 hours to keep up. It does get ridiculous.

The problem is we've turned asynchronous communication and decision making into a near-real time short loop without considering the cognitive costs. Switching from my editor to email, parsing the 30 new messages, identifying the content to reply to and fabricating the correct reply costs the mental software model being used to guide the coding and it takes time to get it back into place. Switch in/out all day and your only bit of peace comes when the email writers go home.

If you have 3+ hour meetings that sounds like a bug. Maybe figure out why they take so long or why there are so many and address that.

Maybe get fewer people in the meeting? Push as much discussion as possible out of the meeting so it only involves the people who care? More delegation and indirection?

Managers and leadership should be showing up to more smaller meetings not front line people showing up to fewer longer meetings.

I think a reasonable scheduled meeting budget is averaging 1-1.5 hours per week and that is an upper limit not a target. Unscheduled (as in does not repeat every week at the same time) are something to be avoided for a product development team.

I think it was part of the management culture and how they got things "done" back in the day. The CEO came from a background where solution finding was sticking people in a war room for hours churning through things to find solutions. That works when you're sitting together analyzing data but not when you're writing the code to create the data being analyzed.

It also comes from time valuation. They value their work at $X and my work at $K where X > K so it's oK to burn my $K value because the $X-$K delta is high enough to justify prioritizing their work needs.

Another trend I've seen emerging is devs almost always bring in their laptops to meeting and zone out (doing their real work) when they don't care about what's being discussed. Don't know if its good or bad. Or maybe people now even expect you to bring your laptops in case you don't have any input.

Sounds nice in theory but the managers set the meeting.

What they never seem to realise is a 2 hour meeting with 10 people means they use two hours of their time and 20 hours of their subordinates, most of which is spent waiting for the other 9 to finish.

Lots of those managers simply don't see the inefficiency since from their point of view it looks OK.

My theory pertaining to non-technical supervisory staff is that meetings for some fill up an otherwise very empty day. All the technical managers that I have worked for never seemed too eager for meetings - they were too busy building real things to waste time in meetings.

"If you have 3+ hour meetings that sounds like a bug."

Not to management :(

"Maybe figure out why they take so long or why there are so many and address that."

Cause meetings, especially long meetings, are how management shows that they're on top of something and getting things done.

> Maybe get fewer people in the meeting? Push as much discussion as possible out of the meeting so it only involves the people who care? More delegation and indirection?

Totally with you here. I also make it mandatory that everyone coming to a meeting read the offline discussion before hand. When someone shows up and we have to summarize the back history again it is selfishly wasting everyones time. I finally started refusing to do it and will leave and tell the PM to reschedule.

Yeah, we have an open-office plan, but we've successfully lobbied to have developer meetings largely moved to one day a week, and engineers on important projects get "office hours" to allow for interruptions during a defined time. It's important to separate meeting cultures from open offices.

We have a hybrid space. Cubes surrounded by white boards. Probably 20feet of whiteboard / associate and a few associates with offices with doors and 10 feet of whiteboard. Doors are seldom closed. We use chat for both my team and with another similar team across campus. We are very aware of the penalty of context switching so the spaces tend to be quiet except when there are operational issues. We use a scrum lite approach (daily stand ups but very lightweight).

We agree with the comments here that chat should be used for operational or time and sequence sensitive task coordination. We call quick meetings to collaborate on issues and opportunities right after standup and they tend to last about 10 to 20 minutes at most. These don't occur very often (1 or 2 a week). All of this works very well.

We have tuned the space a lot over the years. We also have a small table in the space so we can do demos (big monitor on the wall) or have meetings when we want and not be tied to formal meeting space availability. We maybe have 2 to 3 meetings a week in the space and usually they involve everyone (there are 3 of us).

My last gig was at a bank and I had no desk. I had a file cabinet and a shared admin (across maybe 80 people). Was expected to find space to work. I carried my office on my back. At times it was great. I could hide from my associates when I needed to get work done. I had 8 people working for me. But when we needed to collaborate or meet we could hardly ever find quiet space to talk through operational issues. We were never allowed to use chat so when operational problems arose people had to assume I was looking at my email.

Net net was I hated this approach. I love what I have now.