As a developer I have absolutely no qualms with the weekly meetings and since we're fully remote, it's actually nice to be in touch with my team mates, even if they talk about the part they're doing right now for a while.
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.
There’s a lot of meeting hate here and as a developer, I used to feel the same.
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.
> Without it, maintenance, admin, and firefighting will expand to fill the entire week. The meeting forces space for focus, clear commitments, and basic accountability.
Author here. You said it better than I did in the post.
No, your claims are too broad, generalizing from specific case (apparently a small company, high accountability). A standup meeting to try to ensure visibility and accountability are necessary but by no means sufficient; you only get as much of those as the underlying company culture, plus the seniority of the person running the meeting. People can still turn the thing into a talking shop, filibuster, perpetually roll deadlines, specs that are never fully nailed down, "hidden dependencies" that no-one is held responsible for not spotting, cross-department issues that don't have a single owner. I've been in situations multiple times where I had to call a meeting to diplomatically shine a light on different branches of an org not working well together, or sometimes even actively undercutting each other (or working on a cost-plus/time-and-materials basis).
So your claim "One effective solution is to schedule a standing meeting... works across organizational boundaries too." is way overly strong. Just because you've had an instance or two where it did work, doesn't mean that works in general, for other orgs.
Meetings may or may not be forcing functions, depending on the organization. Sometimes they are. Oftentimes they aren't.
The better mantra to ask is "Who in this organization is actually incentivized to make this project succeed... where specifically is there accountability?" Sometimes, believe it or not, the org doesn't have much of that.
"It’s easy for long-term strategic, high-impact work to sink to the bottom of everyone’s todo list."
"[...] 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.
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.
Organizational power comes in various forms. If an executive cares about the project and believes the junior PM is capable of running it, then that can be all the "power" that the PM needs to herd more senior engineers. If the engineers really have that much of a problem with it, they can go complain and be promptly told to stop complaining and get back to doing their job, i.e., contributing to the project.
As an aside, whether you're a PM or not, this is a good way to get promoted. On more than one occasion in my career, I've effectively led a project whose participants were on my boss's boss's staff. All I did was identify something that was strategic and important to the organization but that nobody at the next level currently had time to lead. I'd present the idea to my boss, then we'd present together to their boss, and I was in.
There are the status updates that it's often good for people to know about even if only in a half-listening and simultaneously replying to emails sense. They're at least aware in a way that they wouldn't if they didn't read the memo.
There are decisions that really just need to be made, even if not critical, so they don't get strung out.
And there are meetings that don't require a decision today but do have a timeline and need at least a plan for a plan.
Meetings are one type of forcing function. Anything with concrete, time-bound deliverables is a forcing function, too. In a well-managed organization with trained & competent staff, it should not require meetings to ensure progress.
Some meetings, especially one on one, can be useful. It's very hard to say no to someone you've met, especially when your only other interaction is over the phone, email or chat.
Recurring meetings, especially at the developer level, are a waste of developer time.
I always found it easier to walk around, get personal updates one on one and integrate the information.
That way I wasted only a few minutes of each developer's time, instead of boring them all for an hour per week.
> That way I wasted only a few minutes of each developer's time, instead of boring them all for an hour per week.
I've been in companies where a standup with 6 people takes 45 minutes.
The company I'm in finishes standup with 8 people usually within 10 minutes and often enough within just 5 minutes.
The companies have very different approaches to information sharing. The first wants in-depth information and for everyone to have opportunities to speak up to offer help. A true team effort is what they want. The second wants everything to be as brief as possible, so you can get back to doing what you're paid to do.
I saw a lot more "progress" at the second company. I also saw a lot less collaboration and more "oops we need to fix this now" happening too -- even into production.
The first company definitely did things a bit slower. But that slower generally translated to better quality software: software that generally worked correctly on the first try, or problems were at least caught before reaching production. When an issue did arise in production, it could be safely and quickly handled and rarely with downtime, because rolling back was part of the extensive test suite.
Coming to truly understand the differences between approaches has been eye-opening, and has seriously changed my biases about "how" to go about writing software on a day-to-day and week-to-week basis. Collaboration is good, but you have to have buy-in from the developers for it to work well. That was key and it took a lot of convincing each developer of the benefits.
What other forcing functions is everyone using? (externally-imposed like meetings, or self-imposed)
I don't use forcing functions enough, which may imply missed opportunities to trade slightly higher-stress and increased busywork for greater productivity.
I’m so much more of a quick huddle/sync up rather than a meeting with 10 people who each speak (in the best case) 10% of the time. Having standing meetings for war and feasting (war being sprint planning, feasting being retro/demo) is essential. Standup/status meetings are largely a bane if they last more than 10m
To get the mathematical analogy back off track, some meeting series are "off-resonance" and result in lower amplitude. I'd have titled this "Weekly Meetings are Motivational".
100% agree that there are more and less valuable meetings. Agendas and todo checkins are signals of worthwhile meetings. And having a meeting end or change is a good sign too.
Meetings are too easy to game. I worked with a bunch of new managers from LEGACY_CORP and learned the extremes of how to BS.
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.
No way, this is terrible! There are so many great work tracking tools to use or more efficient ways to communicate that accomplish the same thing. Without making a bunch of people take time out of their day so you can ask them if they remembered to do part of their job. Good management creates systems so this kind of thing isn’t needed.
"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.
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.
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.
Author here. You said it better than I did in the post.
It's really about creating space!
So your claim "One effective solution is to schedule a standing meeting... works across organizational boundaries too." is way overly strong. Just because you've had an instance or two where it did work, doesn't mean that works in general, for other orgs.
Meetings may or may not be forcing functions, depending on the organization. Sometimes they are. Oftentimes they aren't.
The better mantra to ask is "Who in this organization is actually incentivized to make this project succeed... where specifically is there accountability?" Sometimes, believe it or not, the org doesn't have much of that.
"[...] 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.
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.
As an aside, whether you're a PM or not, this is a good way to get promoted. On more than one occasion in my career, I've effectively led a project whose participants were on my boss's boss's staff. All I did was identify something that was strategic and important to the organization but that nobody at the next level currently had time to lead. I'd present the idea to my boss, then we'd present together to their boss, and I was in.
There are the status updates that it's often good for people to know about even if only in a half-listening and simultaneously replying to emails sense. They're at least aware in a way that they wouldn't if they didn't read the memo.
There are decisions that really just need to be made, even if not critical, so they don't get strung out.
And there are meetings that don't require a decision today but do have a timeline and need at least a plan for a plan.
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.
Recurring meetings, especially at the developer level, are a waste of developer time.
I always found it easier to walk around, get personal updates one on one and integrate the information.
That way I wasted only a few minutes of each developer's time, instead of boring them all for an hour per week.
I've been in companies where a standup with 6 people takes 45 minutes.
The company I'm in finishes standup with 8 people usually within 10 minutes and often enough within just 5 minutes.
The companies have very different approaches to information sharing. The first wants in-depth information and for everyone to have opportunities to speak up to offer help. A true team effort is what they want. The second wants everything to be as brief as possible, so you can get back to doing what you're paid to do.
I saw a lot more "progress" at the second company. I also saw a lot less collaboration and more "oops we need to fix this now" happening too -- even into production.
The first company definitely did things a bit slower. But that slower generally translated to better quality software: software that generally worked correctly on the first try, or problems were at least caught before reaching production. When an issue did arise in production, it could be safely and quickly handled and rarely with downtime, because rolling back was part of the extensive test suite.
Coming to truly understand the differences between approaches has been eye-opening, and has seriously changed my biases about "how" to go about writing software on a day-to-day and week-to-week basis. Collaboration is good, but you have to have buy-in from the developers for it to work well. That was key and it took a lot of convincing each developer of the benefits.
I don't use forcing functions enough, which may imply missed opportunities to trade slightly higher-stress and increased busywork for greater productivity.
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.
"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.