Comment by tikhonj | Hacker News Reader

Comment by tikhonj | Hacker News Reader

Parent Full thread

I've gone in the opposite direction: on projects I've led, I decided to have no recurring meetings at all, very much going against the flow of the broader organization. Instead, I would set up a time when we had something specific to talk about. I wrote a short but hopefully clear description of what we needed to cover on each event that I scheduled.

I found this worked really well in practice. We actually talked more as a team compared to the ones using a fixed process with recurring meetings or "ceremonies", but the discussions were consistently useful. There was a lot more time spent figuring things out together and developing a strong shared mental model for what we were doing—some non-trivial but not quite research-level machine learning work—and no energy wasted on glorified status updates that only one person on the team cared about, or "syncs" that became increasingly less useful week-over-week.

Most other teams I've been on had this seemingly contradictory dynamic where we had too many meetings but also did not talk nearly enough. It's amazing how a bunch of recurring meetings can take up a bunch of time and attention, but somehow not leave enough space to dive deeply into non-trivial technical or strategic questions, or meaningfully talk about "meta" team topics.

A real risk is that a recurring meeting can pull out the oxygen in the room to talk about a given topic. It's too easy to put off talking about something important until the next scheduled meeting—by which time you have less context and less time—and then, if the recurring meeting isn't long enough to go deeper, the discussion gets put off even further. A team I worked on recently had a quarterly "retro", never had enough time to cover anywhere near every "retro" topic we actually needed, but also didn't consistently talk about that kind of topic outside the retro. We'd just wait until the next one rolled around. (Worse yet, this still put this team ahead of a number of other teams I've seen...) In contrast, the best teams I worked with never had explicit retros because we just talked about things that needed talking about as part of our day-to-day.

I have no doubt that this approach works better than recurring meetings, but I do want to point out the trade-off, which is that this approach requires much more management attention and energy to keep their finger on the pulse and ensure all concerns are handled, compared to their time management being on autopilot with recurring meetings.

So it's a bit of a tautology. Managers who manage time better are more effective. Who knew?

I’d also give some pushback based on scheduling: fixed meetings are a known quantity people can schedule around.

For coders and people with lives, knowing what their week looks like is critical to planning and stress management (ie in X work hours topic Y will be landed, I have X - 2 hours to have my facts in line; daily 9:15 meeting ends at 9:30, everything after 9:30 is a predictable block I manage).

Now, to the issues and whattabout’s that implies:

1) bruuuuutal meeting discipline: off topic gets killed, new topics insta-popped onto next agenda, scripts of expected responses prepared and shared (“we are green, need approval by X”). Stand if ya gotta, chess-clock if ya gotta, bring in a non-teammate for secretary duties as needed. Meetings are not gab sessions.

2) if that agenda isn’t lava hot with everyone actively getting something, W-O-W, end the meeting. Split off, 1-on-1, task-group it. Fixed project meetings are to make manager-me not have to chase anyone or anything, we are racing to get that done ASAP and the second we’re done it’s time to get the fu… <ahem> grab a coffee, and return to the activities everyone is being paid for. Gab sessions naturally follow, as needed, dynamically adapting to needs and pressures.

Managers who manage meetings manage to meet without meetings managing them. Manage time or time will manage you. The real MBA was the one inside you the entire time.

This sounds horrible to me.

I think it seems tautological to us because it's obvious to us. But other people do not understand or care to understand or even care to think about it. You can see it in this very comment section that there are people swearing how amazingly helpful fixed standups supposedly are even on a whole org level. It's obviously absurd but they have different jobs and priorities, they don't have to understand the inner workings of the product and for them it's invisible that the meetings are almost entirely worthless for the actual workers. The meetings are helping them in their job and so it must be great for the org, that's how many people managers think.

I’ve been on both sides of this. Engineers who complain loudest about the waste of time from too many meetings will also complain the loudest about how they feel disconnected from the decisions and from the product IME.

Decisions rarely need to be made on-the-spot in synchronous meetings. You can have asynchronous approaches with shared documents and RFC processes, where you make everything available if people want to contribute to areas that they find interesting. This does not, of course, mean that decisions need to be made by committee, and people who provide feedback should understand that getting the privilege to provide input does not mean that they also get a veto.

It's quite rare to find companies that do this for the same reason it's quite rare to find companies willing to "do agile correctly" and really scope out work before sprints and not put additional work in the middle of a sprint. It takes too much effort and gives up too much flexibility for most managers to make the investment and see if it pays off.

I've had the same experience with picking specific things to discuss over recurring meetings. A few coworkers and I have frequent, short, high-signal conversations over Slack huddles almost daily, and sometimes we need to converge with others to tackle bigger problems so we set up meetings around those topics.

I really prefer this over recurring meetings. The gist of it is that you're communicating early and often when you can't solve things in isolation, avoiding putting things off or letting understandings of problems atrophy while you wait. Ironically, I do this most with my remote coworkers. They're amazing. The coworkers I have in office are much less keen to give up time for communication. They're great too, in other ways, but harder to communicate with.

Your point about shared mental models is huge. Ironing these things out with another person is invaluable, but having more than one person do it at once means it's multiplied across the team. So many people we work with are building this model in isolation with LLMs, and I'm certain it's harming our collective grasp on what it is that we're actually doing. Very strange times!

It has never seemed more important for humans to communicate with each other and have these shared mental models. To simplify rather than add complexity, to cultivate that meat-space context that gives software purpose in the first place, to understand that purpose, and so on. Interacting with each other fluidly and regularly is such a great way to make that a reality.

We had that and major part of communication just stopped. People stopped talking about issues or solving them, unless those were super large. The bar to "and now trigger meeting in a team where manager seems to dislike" was too high.

Communication larger died, except a smaller "friendship minigroup".

The worst pattern is having a calendar full of rituals and still never having the right conversation at the right time

This is the way

Reply on news.ycombinator.com