But after bootstrapping a SaaS company and at times struggling through cross-team execution, I’ve come around. A short weekly standing meeting, like the one described in the book The 4 Disciplines of Execution, is actually a powerful tool.

Without it, maintenance, admin, and firefighting will expand to fill the entire week. The meeting forces space for focus, clear commitments, and basic accountability.

It’s not obvious early in your career, but once you’ve got some scars, it starts to make a lot more sense.

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.

"[...] But one where the tasks to accomplish the project are not anyone’s full-time job."

Sounds like the organization's leadership are incapable of balancing short term and long term goals, and it's falling to people who are paid less to "step up" and try to swim against the current for the good of the company.

or

Whatever the author is talking about is some engineering pipe dream disconnected from actual business value, and someone is dragging a bunch of other people semi-willingly along trying to execute on it without a mandate/funding from leadership.

Impossible to say which from the outside. But I've known several instances of both cases.

What I had issues with in the past is forced daily meeting (on top of other meetings) that just created stress and fatigue for me. Starting my day with a standup was literally the worst way to start it ever.

The moment you put a recurring block on the calendar, the implicit contract shifts from "we make progress on this work" to "we show up on Tues at 2". The meeting becomes the deliverable. And it always stays long after the original need has passed because nobody wants to be the one who kills it.

What you want is to call a meeting when you need one. When there's a decision to make, a blocker to clear, or a plan to align on... get the right people together and do that thing. A meeting you call as needed stays honest, or at least has a higher chance of staying honest. A standing meeting just becomes calendar furniture and most of the people in it know it.

The number of managers who've successfully convinced themselves that knowing things and making decisions aren't part of their job, and just fill their days with arm-twisting and event-planning, is literally unbelievable to me. I've never met a founder with the attitude "yes I'll just put the stakeholders in an alignment meeting and my company will build itself," but somehow half the of the rest of leadership thinks that's a job.

These types of meetings only work if the person who organized it has organizational power over the other participants. In my experience, these types of meetings always get deferred or cancelled if all participants are of the same level or worse, the organizer has less organizational power than the participants.

A progress meeting by a junior PM with a bunch of senior+ engineer is _guaranteed_ to get cancelled or gutted very quickly.

---

In the vein of other comments though: agree. The necessity of these types of meetings is an organizational stink and the problem lies with priorities and amount of work to be done.

If something really needs to be done, time and resources will be found for it.

Every leader ever: if we could do the right work, we could have less meetings.

I agree with the sentiment. And also understand the rage you’ll get.

(Something that this article should mention)

People (managers) who advocate for meetings need to keep an eye out for:

1: People scheduling meetings as a form of group procrastination.

2: People scheduling meetings as a form of pontificating or having people listen to their ego trip. (These quite literally feel like someone "holding court.")

3: Confusing meetings for general collaboration on work. 2-3 people working together on a problem is not a meeting. > 3 people collaborating around a table should only happen long enough that everyone gets enough information to break apart into smaller groups so that they can get their job done.

4: Meeting overload: I think there is a "healthy target" of ~1 hour a day of meetings for an IC, slightly more for an engineering leader, and significantly more for a manager.

Meetings become a problem when the ICs are pulled into more than an hour of meetings on a typical day, or an engineering lead being pulled into more meetings than they are comfortable with on a typical day. The managers need to shield them from too many meetings.

There are no planning meetings, no stand up meetings, no product management, etc. There is a yearly conference; but that seems to be mainly a social event. Meetings don't really factor into the process. There simply are none. They've completely removed meetings. Many other OSS projects likewise have no meeting structures.

Meetings are synchronization bottlenecks. Everybody stops what they are doing to wait for a meeting where some kind of decision process takes place. Anything blocked on that decision has to wait until then. And then work progresses. The more meetings you have, the more bottlenecks you create. The larger your team, the less practical this gets. OSS projects are huge and cannot afford to drop everything they are doing to have a meeting. Meetings are way too expensive at scale.

What the OSS world does is resolve decisions asynchronously so they don't end up blocking anything important. Individual contributors and stakeholders might have side meetings of course but having meetings is not part of the overall development process. They do their thing and then changes get submitted.

The interesting thing is that most large scale OSS development is dominated by corporate contributors. Most full time contributors are employed and their employers have a big stake in these projects. But it seems they skip all the meetings when doing OSS. And then they switch back to having lots of them for all internal development.

The results don't lie. Many OSS projects have been around for decades, maintain a high pace of development, and seem to do a good job of staying on top of technical debt and quality issues. Without having meetings.

I attempted to run the project entirely asynchronous, where we had a slack channel, ICs had their section of goals and milestones, and I was there for them to consult with, provide feedback, unblock obstacles, and proactively come up with interfaces across the objectives. I thought this would be a nice high trust method of doing things that gave people ownership over their respective parts.

What happened was one person made an AI copy of the doc I had and began vending that out to everyone else, progress was quite slow and really complex in original proposed PRs (unsure if thats AI or author doing that), people did not really follow through with their implementations and it all ended up taking longer than I expected for no good reason. In the end, I lost trust in these ICs as I now feel the need to chase them and have low desire to work with them.

For the next XFN project, I will be driving a brief weekly meeting. Unfortunately the pressure seems to be important. I think there are things I could've done better communication wise at the beginning and throughout as well, but overall I felt disappointed that I had to check in to see progress.

While meetings have their place, they're not how you convince people to work on your project. Meetings are purely a reporting and sharing method and don't work as a shame-based incentive to get work done.

After a while, people simply don't care about you or your project because they have other projects that their manager values more, and they have no problem telling you so, even during the meeting.

You're waiting a whole week for an update or to push people.

I'm a huge proponent of "async over sync" and "sync as soon as necessary". Don't wait to the next meeting in 3 days to escalate.

People whose calendar looks like meetings only and are always willing and able to throw complexity to others won't feel the pain of not having a meeting budget [1] but other roles will want to avoid eating up all their time on this type of admin.

I encourage people to explore how extremely simple Agent Skills workflows can already do a lot of the admin legwork than an executive assistant would and free their time from admin bureocracy and red tape, as much as possible. If there's no programmatic endpoint or MCP, use something like playwright. A little goes a long way.

- [1] https://alexhans.github.io/posts/meeting-budget.html

When you're alone you can cosplay urgency for weeks without actually shipping. A weekly check-in with literally anyone external is the only real deadline that bites.

Tried public commits as the substitute. "Shipping X by Friday" tweets, working in public, that whole genre. Doesn't work for me. You end up optimising for the post not the ship. Worse outcome than no deadline at all.

I think this experience has taught me a lot about the POTENTIAL value of meetings. We meet up when one of us feel 'stuck' or are spinning our wheels or getting lost in the sauce, and it ALWAYS helps clarify immediate next steps.

this is the kind of advice you need and takes months or years to understand when you are starting out running a club or associative project and yes p much goes for all coordination effort

"A recurring meeting serves as a powerful forcing function for long-running projects."

No it doesn't. It serves as a burden ball that gets kicked around on the calendar field once the value of the series has been tapped out but no one wants to cancel it.

I'm willing to cut her some slack, since I tried her job for a while and hated it.

I don't use forcing functions enough, which may imply missed opportunities to trade slightly higher-stress and increased busywork for greater productivity.

Oh, and half the company leadership expects me to also stand up a professional "agile software development capability" in the rest of my time while the other half parrots a sentiment from before we grew from 500 to 3000 people that "we aren't a software development company." Well, neither is a bank, but banks employ armies of software developers and they don't tend to underfund them. When exactly I'm supposed to perform my supervisor functions and annual trainings is left as an exercise to the unpaid overtimers.

Sigh I need a new job. I never wanted to be a defense contractor in the first place.

Deadlines don't make things more efficient by definition, unless it's a case of "within-task" inefficiency (i.e. "laziness"). But while this is almost always assumed to be the case by managers, it almost never is the case on the ground. And then you get into this hare-brained vicious cycle of "oh we're falling behind despite the deadlines (read "context-switching interruptions with non-trivial overhead enforcing suboptimal task selection"), we should probably add more!" [facepalm]

As an example, if you think there might be any sort of pushback, just never stop talking. Once a manager talked for 35 straight minutes to answer a question on an unpopular decision. By the end there were no follow-ups because everyone was too confused and checked out to care.