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.
"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.
"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.
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.
> Engineers: All a meeting does is distract from work.
> Every leader ever: if we could do the right work, we could have less meetings.
Guess who defined “work” in the first place? I wonder if it’s some kind of manager schizophrenia where they define shitty requirements and outcomes and then act surprised when they get subpar result, which they try to promptly mitigate with more meetings.
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.
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 instance (apparently a small company, high accountability, no diagonal lines or conflicting organizational incentives). 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.
Instead of your claim, I'll tell you the key organizational symptom that I found actually determines accountability, or lack of: (discreetly) find out what happened to the careers of CXOs/VPs/directors/execs/managers on projects that failed: were they promoted/ given bonuses/ retained/ demoted/ reassigned/ fired? (sometimes they get a token punishment/demotion, leave, go found a startup/sit on the beach, then get reacquired at a higher level than what they left).
I will say I've seen this work across organizations as small as 2 person startups and as large as 100k organizations (though, to be honest, I was embedded in a team as a contractor in that org).
I'm sure there are orgs where it doesn't work, which is why I said "One effective solution is to schedule a standing meeting".
I like your perspective--accountability is the basis; the meeting is one method, but I'm sure there are others. Do you have other solutions that you've seen work?
But you posted here under the overly broad headline (not "Meetings can be forcing functions", or "How to make meetings forcing functions") with its overly broad claims.
Also you asserted "One effective solution is to schedule a standing meeting" not "... can be a solution, under some conditions".
>
I've seen this work across across organizations as small as 2 person startups and as large as 100k organizations*
and I've seen it fail across orgs as small as 15-person startups and as large as ~100k organizations; and sometimes work. How large was your sample size N?
> Do you have other solutions that you've seen work?
As I emphasized above, the mantra to ask is "Who in this organization is actually incentivized to make this project succeed... where specifically is there accountability?" If there isn't any such person running/chairing the meeting/ or at absolute minimum reading its minutes, you just get a meaningless talking shop, which as other people here are saying is negatively productive and intensely annoys engineers, rightly so. a) A meeting is only as productive as the subset of people invited (or, equally, excluded). b) You can only enforce or appeal to as much accountability as the management chain intrinsically has (unless you or the senior mgmt or shareholders get them replaced, which is usually major power politics. As a consultant in particular, beware of fighting other people's battles, especially executives.).
(and to help answer the conundrum about who's actually incentivized to make a project succeed, I said you have to do some archaeology on what happened on their previous projects in that org (or previous orgs); the pathological case is if they failed repeatedly but kept getting rewarded, or developed an old-boy network around them.)
> In others, clarity comes from making the point and assuming above average intelligence of the readers to know that context is always relevant.
It's not cool to insult the readers' intelligence when someone makes a shaky overly broad claim. Better to retract or modify the claim. The headline "Meetings are forcing functions" is borderline clickbait. Most of us here have been in companies that meeting'd themselves to death, or at minimum, underachieved. And those companies had scheduled meetings too, so beware success bias and survivorship bias. My key positive message to OP is to emphasize cultural signs of accountability (or lack of), without which everything else (like standups and progress reports) is out the window. For example, how many of you have ever seen someone organizationally punished for accurately reporting status in a meeting?
‘Well, achshully, too much water can drown someone, so it’s not a universally true statement that it’s critical to life’
Meetings are forcing functions. They force me to sit in stupid recurring nightmares that are wastes of time, in many cases.
In the right context, as the author has called out, they offer a rhythm to work that drives behaviors.
You are tying meetings to all the woes of the modern white collar job, and raising ill-constructed arguments that don’t pass muster.
“Meetings are forcing functions” - Clickbait?! “The Secret to Driving 10x Better Work” is clickbait. The title is as succinct a summary of the work as one might endeavor toward.
The criticism is just "you dared to be confident in expressing your view". It's metacriticism, not criticism of the view itself. That makes a metacriticism level response legitimate.
You can make a confident statement and assume your readers are smart enough to understand it as "this may not be true in all situations always" but then they may be so desperate to insert stupid memes into their responses that they miss the point entirely, anyway.
> 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.
Not to mention that having a standup doesn't actually solve the need for 'maintenance, admin, and firefighting'. If your team needs to do a lot of maintenance and firefighting, that work will eat up the whole week until you pay off the technical debt that's accruing it. A meeting won't solve that on its own. If the owners don't prioritize investing your time in paying debt down, you'll be firefighting until the end of time.
meetings have their role, but the hate at least in my case is when they become a distraction and/or a waste of time. They are susceptible to the organizer and to the highest ranking person in the room and many managers are not up to the task of doing it correctly.
> Without it, maintenance, admin, and firefighting will expand to fill the entire week. The meeting forces space for focus, clear commitments, and basic accountability.
Release manager, or whoever manages incidents, will just schedule weekly meeting of their own.
The problem is that management will see that it's useful, and embrace this meeting. It doesn't take long until the meeting is no longer short, switches up to daily, isn't standing because there's too many people and/or everyone is WFH.
I think one of the biggest problems in management is that managers are super focused on making their management tasks easier at the expense of their reports actually doing the work. In general, they prefer a meeting with 20+ or 50+ engineers in one place, each giving 1 minute or longer feedback, because they can do that every day and in an hour, they know what everybody is doing. But they seem completely oblivious to the fact that now every engineer has an hour less time to do actual work, they've been taken out of their flow state to attend an hour long meeting of which maybe 2 or 3 minutes is relevant to them, and they've tuned out of everyone else's progress reports because it doesn't impact them at all. Management simply don't see that 16% of the productive day for the entire team is wasted, because it's made their job marginally more efficient.
I've worked in exactly one place were the standups literally were a small group of engineers and one PM, and it was literally "I'm working on this, no problems" or "I hit this issue, I'd like to chat to X about it after the meeting" and the entire thing was over in 2-3 minutes - nobody sat down because there was literally no point. In that company, the manager would just catch up with each personal individually to find out what everyone was up to, taking maybe a minute or 2 each day AND after checking whether they were in the zone or happy to be distracted. In that place, once every 2 weeks we'd also have an hour scheduled 1-to-1 about anything the manager or report wanted to discuss about non-project things, but that could end early if nobody had anything else they wanted to discuss.
You don't tell them they're not allowed. You ask them what they need from the meeting and how so you can free up the time from their calendar, or what they need to comfortably delegate the responsibility to you.
Managers don't do this stuff for funsies they do it because they don't trust that their team won't go off track because of something they don't know.
A lot of people are talking past each other in this comment section.
A good boss definitely doesn't want you spend their time making you do performative work. A bad boss gleefully engages with this as it shows they are big and important.
A good boss will see the inefficiency and work with you to try and manage it so you are not doing a bunch of PM work (wasting your time) while the important stuff happens and clear communication continues.
A bad boss will see that you are not catering to their emotional needs which implies you are a very bad worker and thus you will be keel hauled into every meeting they can invite you to because obviously the more time you've spent talking to them the more efficient you've been during the day, you are a finger on a hand and you should not flex unless the mind controlling you wants to.
I had a bad boss move me across the country as the most important thing so we could have face to face comms, and then would only come into the office once a month or so to talk - but to him that once a month in person conversation was worth upending my entire life so it was marginally easier than a zoom call for him. There's a lot of rich assholes who operate like this.
> In general, [managers] prefer a meeting with 20+ or 50+ engineers in one place, each giving 1 minute or longer feedback, because they can do that every day and in an hour, they know what everybody is doing.
Most of the time they don’t even know what everybody is doing, or why, or how. But they like to fool
themselves into thinking that, because ??? it given them the warm fuzzies, I guess.
Then they just wasted everybody’s time for absolutely no reason at all.
As a manager, I would hate that. Have small groups of 5-8 do standups. There's no reason to waste ten thousand dollars a day on that many people waiting for each other's status updates.
The small standup you describe works because it is basically an interrupt router: say what you're doing, surface blockers, then move the real discussion to the relevant people
In general, they prefer a meeting with 20+ or 50+ engineers in one place, each giving 1 minute or longer feedback, because they can do that every day and in an hour, they know what everybody is doing. But they seem completely oblivious to the fact that now every engineer has an hour less time to do actual work, they've been taken out of their flow state to attend an hour long meeting of which maybe 2 or 3 minutes is relevant to them, and they've tuned out of everyone else's progress reports because it doesn't impact them at all. Management simply don't see that 16% of the productive day for the entire team is wasted, because it's made their job marginally more efficient.
Uh, I'm a manager and that meeting format gives me a visceral negative reaction.
I have a team of 15 directs (+ 2-3 on loan at any given time) and I would never require all of them to attend a single meeting with individual report-outs. What a waste of time for all.
Currently, the group is split in two. Out standup are are you describe in the last paragraph - what you did, are doing, and blockers. If there's need for deeper discussion, we table that to the end (or schedule a separate meeting), so anybody not required can get back to "real" work. On a good day, the meeting takes ~10 minutes (and that involves some chit-chat) and maybe once/week it take the full 30 minute block.
Maybe relevant - 4 of the 15 are right out of college, still learning the job, the daily meeting gives them an opportunity to discuss work without feeling like they're pestering anybody. If the team was more mature, I could see going to 3x/week stand-ups or similar.
I manage teams and a standup with 20+ attendees sounds like hell to me. We keep standups to team scope and 10 minutes long (20 minutes in the case of our largest team, but it almost never goes the full time).
We have some larger meetings that are closer to what you are describing, but they are for higher-level management, not line engineers.
This is the way! I run a remote only company, and when the game is on, one meeting per week, 30-60 minutes (at most!) is essential!
However... there has to be an agenda, the agenda needs to be followed, and meeting monopolizers need to be cut short. (americans are very good at expanding meeting participation and to take up all the time, care needs to be taken with them. This is cultural, they love to talk.)
That's about all that is necessary. Then individual syncs can be done per email the rest of the week, or phone in case of emergencies.
I strongly agree that the agenda must be published upfront.
Moreover, when something more substantial must be discussed, e.g. the accomplishment of some project milestone, or a work plan or a proposal for new features or for a new project, a document should be prepared and sent in advance to the participants with the description of the obtained results or of a plan or of a proposal, enabling them to prepare suggestions for improvements or for alternatives, or criticism.
Nonetheless, I may agree with what the previous poster said about Americans and conciseness in meetings (i.e. the lack of thereof).
I also run an online company but I dont like meetings it is always re hashing things already shared and written before. But it seems like a lot of humans absolutely need meeting to properly collaborate. Why ?
Someone does, I guess. Whoever writes it hopefully read it at least once, though that's not guaranteed these days. Most other people would rather do anything else, so if they can possibly get away with just hearing it, they will. Reading and comprehending is much harder work.
I have the same experience. Literally no one wants to read anything, they will always try to minimize the work done and pretend they've read. And when they've read, they weren't focused and the information isn't used for the project. I have no idea what to do here
Weekly meetings and weekly activity reports are typically fine and useful.
What is bad is that there are plenty of companies that want daily meetings and/or daily activity reports, which always greatly reduce the productivity of developers/designers for no benefits.
meetings are a tool, and when used properly, an indispensible one at that. meetings bloody meetings by John Cleese is an absolute must-watch for conducting great meetings.
however, if all you have is a hammer, then every problem looks like a nail: it's when meetings are used inappropriately or to solve the wrong problem that it becomes an issue, and many people make this mistake, which is why meetings end up so universally despised and get such a bad rep
> A short weekly standing meeting […] is actually a powerful tool.
The problem is they never stay short, they never stay on topic, they always expand beyond one a week.
Then managers want everybody to say something, so they feel in the know and in control, even when most of the time they are not. So it devolves into everybody just saying something useless to make the manager happy, and nobody listening anymore, because they know that 90% of what is said is just noise.
I have a theory that these short meetings are not the root cause, assuming a trustworthy team.
Having these standups... weekly, daily, whatever-y... it forces the PM to track deliverables. Which means you have to DEFINE the deliverables. And it sort of trickles from there.
The actual hard part is doing the PM Work. Defining deliverables, making tasks in jira (or excel :p), estimating work, and assigning reasonable due-dates.
Thats what these status meetings really do. Once you have that, and you track to it regularly, I would wager you could work asynchronously with a well disciplined team.
Yes, and - there is also something about the visceral feeling you get when your turn comes up in standup and you didn’t update any tasks and you don’t know the status of the thing you promised for this week.
If the PM does the task list and then chases the engineers 1:1, it’s a different chimpanzee brain mechanism at play. Very easy to forget/ignore you are letting down a whole team in this mode.
(And the flip side is true too, shared victory is more motivating.)
> there is also something about the visceral feeling you get when your turn comes up in standup and you didn’t update any tasks and you don’t know the status of the thing you promised for this week.
Never really experienced this. But daily are boring when it goes past the act of sharing updates and into musings by the PM, design discussions with a few of the team while the rest idle…
This is exactly why I do it (as a PM). The average engineer gets way more of the important work done when they have to say what they did and when, if they're blocked, they know I'll actually help unblock them.
And when the standup itself is five minutes, people are still refreshed enough to talk about a book or tv show or show off the progress they're making building a deck or let their kid say hi.
In my experience a good async culture is sustained by regular, high-quality check-in meetings. They serve as connecting moments that support team cohesion and camaraderie.
Many times, across companies, sometime between the day and half an hour before a meeting, I see a flurry of actions—including responses, decisions, deliverables/drafts, etc. In that sense, I think a meeting works because people don't want to show up empty handed, so it adds psychological urgency.
I think small teams can be an exception here, but across most teams (particularly quickly growing ones) and across functions, a weekly sync is irritating but obvious, proven, solution to getting things done.
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.
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
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.
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.
In contrast, I always advocated for my teams to stand up in the morning as a way to set the agenda for the day and make sure everyone was clear about what they were going to work on, as well as have an opportunity to schedule meetings with each other if needed. After that, we were done and the rest of the day was yours.
Glad I’m not part of your team. Morning is the most productive time for me, the less human interaction about “accountability” and “agenda” for the day I have the better.
Do that at the end of the day, not the beginning - review the work you've done and the work you are going to do, and then do not waste my mornings where I am productive on meetings - I probably spend less than 10% of my creative effort possible because of this morning meeting crap.
Daily is a very different psychological load. Even when it's "only 15 minutes" it can dominate the start of the day and make every morning feel like a small performance review...
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.
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'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.
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.
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.
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".
I work at a (ahem) war contractor and at least 50% of my calendar in any week is filled with meetings. As the week progresses, the incidental meetings that people throw at me the day before fill up at least another 25%. I am the chief architect for two major projects, but it does leave me wondering when I'm supposed to be doing any architecting.
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.
Hello. For what it's worth, I'm in a similar role (Security Architecture) in a different sector. It's the same here.
The trick is to block your calendar with 30min slots to approx. 80% of capacity. If your calendar is private, these won't be challenged. This leaves you some space to do the work, some other space to get random meetings in and if you're lucky, everyone is happy.
I think this is the price to pay for a high-profile role.
IMO this is such a manager-brained take. If your long-term strategic goals aren't being advanced, you have to figure out why. Talk to your team and figure out what the deal is. Talk to other teams too, while you're at it. You might accidentally solve a problem.
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.
You know what, I read it again and I don't even disagree with the concrete advice in the post—weekly meeting, starting with open tasks from last week—which I would characterize as a basic, ubiquitous, almost anodyne organizational coordination tool. My problem is this part:
> Everyone has other obligations, fires to put out, and emails to answer. It’s easy for long-term strategic, high-impact work to sink to the bottom of everyone’s todo list...this creates pressure on everyone to make progress.
One experience among many: I spent a very painful six months as a new grad, in a particularly dysfunctional corner of a mildly dysfunctional organization, in hours of daily back-to-back arm-twisty status meetings with team after team who wanted something from me and were sure this would get it (after which I would stay up all night working, since that was the only time I had left for that).
You know how it ended? The tech lead on my team cornered me in a conference room to find out why nothing was getting done, and I fully lost it with the guy. Like just started shouting that the actual consequences of ignoring the things people wanted ignored were transparently not acceptable, and I was barely sleeping trying to hold everything together. He got very quiet, said "ok," and we started going to meetings together and saying no to stuff. The amount that was collectively being demanded from me/us exceeded what could be delivered, but no one was on triage duty.
I've learned quite a bit since then (including spending a few years in management), so I've gotten better at understanding what's happening and asking for what I need. I've just also decided that "it's not my role to figure it out" managers (and PMs) are like rocks in the bowels of an organization. They’re in the way, subtly, quietly making everything bloated and painful as long as they’re there.
My point being, in case it’s still unclear, that “I’ll create pressure on everyone and then progress will happen,” is IMO bad management.
Sometimes the problem is not enough motivation, though I think that if you hire well, that’s rare—the best engineers are intrinsically creative and motivated. Often, lack of progress is due to some other organizational problem—too much toil, unclear priorities, conflict, etc—and just adding pressure until progress happens is the manager equivalent of whining until your sister does your chores for you.
Even if it works, either
1. the team is working around the problem (which the manager doesn’t know about or understand, and isn’t dealing with it) and will eventually get fed up and leave, or
2. someone pushes extra hard and solves the problem for everybody else. Now, that person the de-facto leader, though they’re not recognized, and in fact are often penalized for getting distracted from the paper priorities, since the managers who do this are rarely interested in the mechanics of how their problem was solved. Respect for management is lost, because they don’t understand what’s happening. Eventually everyone gets fed up and leaves.
Managers can’t solve every problem themselves, of course, but the manager needs to understand what the problems are, explicitly set the priority of solving them, and understand and celebrate the solutions when they’re found.
Nah. A forcing function creates pressure toward an outcome...a standing meeting just creates pressure toward the meeting. Those aren't the same thing.
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.
Yeah. The real thing that creates pressure is the people applying that pressure if progress is not made. If people act that way the meeting is an effective way to do this on a weekly base instead of letting it languish over month(s).
If nobody in the meeting actually cares that the feature isn't getting finished, then the meetings value is rather small.
If a meeting doesn't have a focused agenda and expected outcome, it's usually a waste of time for most participants. Standing meetings are the worst offenders, unless you're in a crisis situation. If you're using meetings to get status updates, my condolences.
I've been fascinated by the dynamic of large scale OSS projects operating without management vs. industrial scale software development since I was working on my PhD around 2000. Basically, something like the Linux kernel involves thousands of contributors and yet ships reliable as clockwork every 8-10 weeks. Their management structure is basically a simple hierarchy of lead engineers gate keeping their source trees with the ultimate authority in the form of Linus Torvalds who merges changes only if they meet his criteria. Anything that receives the thumbs up goes in. And thumbs down means the contributors get to work on their patch some more.
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.
Sync meetings can help some people feel pressure but it's an extremely inefficient mechanism.
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.
I had to check the date because this sounded so much like 1996 advice.
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.
Speedrun to annoy the hell out of your developers. If the purpose of your meetings is to “create pressure to make progress” then I’ll just stop attending. It’s not a middle school, stop patronizing adults. If someone is dragging their feet, then let their manager handle it, they just might have too much on their plate without additional useless meeting.
The problem is long-running projects. Projects are too large in scope. They lasts for months to a year with nothing being delivered. Meetings don’t fix that.
Whenever I hear people talk about meetings and / or (internal / arbitrary) deadlines as a scheduling / productivity tool, I can't shake the thought these people have probably never even heard of concepts like scheduling optimization, bottleneck / queing theory, or async event-loop pipelines.
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]
Working solo right now. The bit this misses is that meetings are forcing functions for OTHER people, not just yourself, which is half the reason they exist.
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.
A recurring meeting is useful but I think the real forcing function is the public review of commitments, not the meeting itself. And the tricky part is keeping it from becoming a substitute for actual work...
Just a note regarding meeting hate (that's a common topic in this thread.)
(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.
I have recently began driving projects with multiple contributors that are following a plan I laid out and got buy-in on.
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.
I've been working on a side project with 2 other people for a few months and i inevitably reach out to them to meet for an hour (which always turns into 2-3+ hours) to brainstorm next steps.
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.
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.
"[...] 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.
It reminds me of the guy who recommended structuring software tasks to provide small regular dopamine hits rather than one large hit.
"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.
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.
> Every leader ever: if we could do the right work, we could have less meetings.
Guess who defined “work” in the first place? I wonder if it’s some kind of manager schizophrenia where they define shitty requirements and outcomes and then act surprised when they get subpar result, which they try to promptly mitigate with more meetings.
I too thought the math analogy was quite interesting. Add some recursion and we can have GEB for meetings. Ha!
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.
Instead of your claim, I'll tell you the key organizational symptom that I found actually determines accountability, or lack of: (discreetly) find out what happened to the careers of CXOs/VPs/directors/execs/managers on projects that failed: were they promoted/ given bonuses/ retained/ demoted/ reassigned/ fired? (sometimes they get a token punishment/demotion, leave, go found a startup/sit on the beach, then get reacquired at a higher level than what they left).
I will say I've seen this work across organizations as small as 2 person startups and as large as 100k organizations (though, to be honest, I was embedded in a team as a contractor in that org).
I'm sure there are orgs where it doesn't work, which is why I said "One effective solution is to schedule a standing meeting".
I like your perspective--accountability is the basis; the meeting is one method, but I'm sure there are others. Do you have other solutions that you've seen work?
Also you asserted "One effective solution is to schedule a standing meeting" not "... can be a solution, under some conditions".
>
I've seen this work across across organizations as small as 2 person startups and as large as 100k organizations*and I've seen it fail across orgs as small as 15-person startups and as large as ~100k organizations; and sometimes work. How large was your sample size N?
> Do you have other solutions that you've seen work?
As I emphasized above, the mantra to ask is "Who in this organization is actually incentivized to make this project succeed... where specifically is there accountability?" If there isn't any such person running/chairing the meeting/ or at absolute minimum reading its minutes, you just get a meaningless talking shop, which as other people here are saying is negatively productive and intensely annoys engineers, rightly so. a) A meeting is only as productive as the subset of people invited (or, equally, excluded). b) You can only enforce or appeal to as much accountability as the management chain intrinsically has (unless you or the senior mgmt or shareholders get them replaced, which is usually major power politics. As a consultant in particular, beware of fighting other people's battles, especially executives.).
(and to help answer the conundrum about who's actually incentivized to make a project succeed, I said you have to do some archaeology on what happened on their previous projects in that org (or previous orgs); the pathological case is if they failed repeatedly but kept getting rewarded, or developed an old-boy network around them.)
In others, clarity comes from making the point and assuming above average intelligence of the readers to know that context is always relevant.
We can be assured that assumption incorrect, in this case.
It's not cool to insult the readers' intelligence when someone makes a shaky overly broad claim. Better to retract or modify the claim. The headline "Meetings are forcing functions" is borderline clickbait. Most of us here have been in companies that meeting'd themselves to death, or at minimum, underachieved. And those companies had scheduled meetings too, so beware success bias and survivorship bias. My key positive message to OP is to emphasize cultural signs of accountability (or lack of), without which everything else (like standups and progress reports) is out the window. For example, how many of you have ever seen someone organizationally punished for accurately reporting status in a meeting?
In either case I think you might be coming in a bit hot. OP is just sharing their perspective. No one wants to get into internet fights.
‘Well, achshully, too much water can drown someone, so it’s not a universally true statement that it’s critical to life’
Meetings are forcing functions. They force me to sit in stupid recurring nightmares that are wastes of time, in many cases.
In the right context, as the author has called out, they offer a rhythm to work that drives behaviors.
You are tying meetings to all the woes of the modern white collar job, and raising ill-constructed arguments that don’t pass muster.
“Meetings are forcing functions” - Clickbait?! “The Secret to Driving 10x Better Work” is clickbait. The title is as succinct a summary of the work as one might endeavor toward.
You are acting the fool, my man.
Not to mention that having a standup doesn't actually solve the need for 'maintenance, admin, and firefighting'. If your team needs to do a lot of maintenance and firefighting, that work will eat up the whole week until you pay off the technical debt that's accruing it. A meeting won't solve that on its own. If the owners don't prioritize investing your time in paying debt down, you'll be firefighting until the end of time.
meetings have their role, but the hate at least in my case is when they become a distraction and/or a waste of time. They are susceptible to the organizer and to the highest ranking person in the room and many managers are not up to the task of doing it correctly.
Release manager, or whoever manages incidents, will just schedule weekly meeting of their own.
The problem is that management will see that it's useful, and embrace this meeting. It doesn't take long until the meeting is no longer short, switches up to daily, isn't standing because there's too many people and/or everyone is WFH.
I think one of the biggest problems in management is that managers are super focused on making their management tasks easier at the expense of their reports actually doing the work. In general, they prefer a meeting with 20+ or 50+ engineers in one place, each giving 1 minute or longer feedback, because they can do that every day and in an hour, they know what everybody is doing. But they seem completely oblivious to the fact that now every engineer has an hour less time to do actual work, they've been taken out of their flow state to attend an hour long meeting of which maybe 2 or 3 minutes is relevant to them, and they've tuned out of everyone else's progress reports because it doesn't impact them at all. Management simply don't see that 16% of the productive day for the entire team is wasted, because it's made their job marginally more efficient.
I've worked in exactly one place were the standups literally were a small group of engineers and one PM, and it was literally "I'm working on this, no problems" or "I hit this issue, I'd like to chat to X about it after the meeting" and the entire thing was over in 2-3 minutes - nobody sat down because there was literally no point. In that company, the manager would just catch up with each personal individually to find out what everyone was up to, taking maybe a minute or 2 each day AND after checking whether they were in the zone or happy to be distracted. In that place, once every 2 weeks we'd also have an hour scheduled 1-to-1 about anything the manager or report wanted to discuss about non-project things, but that could end early if nobody had anything else they wanted to discuss.
Only if you let them. We don't let management attend our weekly. They have nothing to contribute anyway. Just set boundaries.
Managers don't do this stuff for funsies they do it because they don't trust that their team won't go off track because of something they don't know.
A good boss will see the inefficiency and work with you to try and manage it so you are not doing a bunch of PM work (wasting your time) while the important stuff happens and clear communication continues.
A bad boss will see that you are not catering to their emotional needs which implies you are a very bad worker and thus you will be keel hauled into every meeting they can invite you to because obviously the more time you've spent talking to them the more efficient you've been during the day, you are a finger on a hand and you should not flex unless the mind controlling you wants to.
I had a bad boss move me across the country as the most important thing so we could have face to face comms, and then would only come into the office once a month or so to talk - but to him that once a month in person conversation was worth upending my entire life so it was marginally easier than a zoom call for him. There's a lot of rich assholes who operate like this.
Most of the time they don’t even know what everybody is doing, or why, or how. But they like to fool themselves into thinking that, because ??? it given them the warm fuzzies, I guess.
Then they just wasted everybody’s time for absolutely no reason at all.
Uh, I'm a manager and that meeting format gives me a visceral negative reaction.
I have a team of 15 directs (+ 2-3 on loan at any given time) and I would never require all of them to attend a single meeting with individual report-outs. What a waste of time for all.
Currently, the group is split in two. Out standup are are you describe in the last paragraph - what you did, are doing, and blockers. If there's need for deeper discussion, we table that to the end (or schedule a separate meeting), so anybody not required can get back to "real" work. On a good day, the meeting takes ~10 minutes (and that involves some chit-chat) and maybe once/week it take the full 30 minute block.
Maybe relevant - 4 of the 15 are right out of college, still learning the job, the daily meeting gives them an opportunity to discuss work without feeling like they're pestering anybody. If the team was more mature, I could see going to 3x/week stand-ups or similar.
We have some larger meetings that are closer to what you are describing, but they are for higher-level management, not line engineers.
However... there has to be an agenda, the agenda needs to be followed, and meeting monopolizers need to be cut short. (americans are very good at expanding meeting participation and to take up all the time, care needs to be taken with them. This is cultural, they love to talk.)
That's about all that is necessary. Then individual syncs can be done per email the rest of the week, or phone in case of emergencies.
Moreover, when something more substantial must be discussed, e.g. the accomplishment of some project milestone, or a work plan or a proposal for new features or for a new project, a document should be prepared and sent in advance to the participants with the description of the obtained results or of a plan or of a proposal, enabling them to prepare suggestions for improvements or for alternatives, or criticism.
Nonetheless, I may agree with what the previous poster said about Americans and conciseness in meetings (i.e. the lack of thereof).
What is bad is that there are plenty of companies that want daily meetings and/or daily activity reports, which always greatly reduce the productivity of developers/designers for no benefits.
however, if all you have is a hammer, then every problem looks like a nail: it's when meetings are used inappropriately or to solve the wrong problem that it becomes an issue, and many people make this mistake, which is why meetings end up so universally despised and get such a bad rep
The problem is they never stay short, they never stay on topic, they always expand beyond one a week.
Then managers want everybody to say something, so they feel in the know and in control, even when most of the time they are not. So it devolves into everybody just saying something useless to make the manager happy, and nobody listening anymore, because they know that 90% of what is said is just noise.
Having these standups... weekly, daily, whatever-y... it forces the PM to track deliverables. Which means you have to DEFINE the deliverables. And it sort of trickles from there.
The actual hard part is doing the PM Work. Defining deliverables, making tasks in jira (or excel :p), estimating work, and assigning reasonable due-dates.
Thats what these status meetings really do. Once you have that, and you track to it regularly, I would wager you could work asynchronously with a well disciplined team.
If the PM does the task list and then chases the engineers 1:1, it’s a different chimpanzee brain mechanism at play. Very easy to forget/ignore you are letting down a whole team in this mode.
(And the flip side is true too, shared victory is more motivating.)
Never really experienced this. But daily are boring when it goes past the act of sharing updates and into musings by the PM, design discussions with a few of the team while the rest idle…
And when the standup itself is five minutes, people are still refreshed enough to talk about a book or tv show or show off the progress they're making building a deck or let their kid say hi.
It does force the management to manage the team, yes. But it will also remind the team they exist, and everybody that they can talk to everybody else.
That said, weekly is on the limit of how often you can make those. And you have to make sure your people are not formally in too many teams.
I think small teams can be an exception here, but across most teams (particularly quickly growing ones) and across functions, a weekly sync is irritating but obvious, proven, solution to getting things done.
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.
I don't use forcing functions enough, which may imply missed opportunities to trade slightly higher-stress and increased busywork for greater productivity.
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.
Ah yes, because sending meeting invites is such a burden you need another meeting to do it in, wasting the time of everyone else involved.
Were 90% of the agendas "working on the same thing as yesterday"? Did no-one know what they were doing that day until they had the daily meeting?
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.
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 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.
So it's a bit of a tautology. Managers who manage time better are more effective. Who knew?
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.
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.
Communication larger died, except a smaller "friendship minigroup".
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.
The trick is to block your calendar with 30min slots to approx. 80% of capacity. If your calendar is private, these won't be challenged. This leaves you some space to do the work, some other space to get random meetings in and if you're lucky, everyone is happy.
I think this is the price to pay for a high-profile role.
Depends on the bank, some certainly offshore and/or underfund their developers just as badly as any other industry can.
They may have all the money but stockholders demand a very high rate of return for that same reason.
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.
> Everyone has other obligations, fires to put out, and emails to answer. It’s easy for long-term strategic, high-impact work to sink to the bottom of everyone’s todo list...this creates pressure on everyone to make progress.
One experience among many: I spent a very painful six months as a new grad, in a particularly dysfunctional corner of a mildly dysfunctional organization, in hours of daily back-to-back arm-twisty status meetings with team after team who wanted something from me and were sure this would get it (after which I would stay up all night working, since that was the only time I had left for that).
You know how it ended? The tech lead on my team cornered me in a conference room to find out why nothing was getting done, and I fully lost it with the guy. Like just started shouting that the actual consequences of ignoring the things people wanted ignored were transparently not acceptable, and I was barely sleeping trying to hold everything together. He got very quiet, said "ok," and we started going to meetings together and saying no to stuff. The amount that was collectively being demanded from me/us exceeded what could be delivered, but no one was on triage duty.
I've learned quite a bit since then (including spending a few years in management), so I've gotten better at understanding what's happening and asking for what I need. I've just also decided that "it's not my role to figure it out" managers (and PMs) are like rocks in the bowels of an organization. They’re in the way, subtly, quietly making everything bloated and painful as long as they’re there.
Sometimes the problem is not enough motivation, though I think that if you hire well, that’s rare—the best engineers are intrinsically creative and motivated. Often, lack of progress is due to some other organizational problem—too much toil, unclear priorities, conflict, etc—and just adding pressure until progress happens is the manager equivalent of whining until your sister does your chores for you.
Even if it works, either
1. the team is working around the problem (which the manager doesn’t know about or understand, and isn’t dealing with it) and will eventually get fed up and leave, or
2. someone pushes extra hard and solves the problem for everybody else. Now, that person the de-facto leader, though they’re not recognized, and in fact are often penalized for getting distracted from the paper priorities, since the managers who do this are rarely interested in the mechanics of how their problem was solved. Respect for management is lost, because they don’t understand what’s happening. Eventually everyone gets fed up and leaves.
Managers can’t solve every problem themselves, of course, but the manager needs to understand what the problems are, explicitly set the priority of solving them, and understand and celebrate the solutions when they’re found.
I'm willing to cut her some slack, since I tried her job for a while and hated it.
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.
If nobody in the meeting actually cares that the feature isn't getting finished, then the meetings value is rather small.
Ultimately yes the true source of the pressure is coming from the "tribe".
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.
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
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.
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]
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.
(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.
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.
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.