21–30 of 123 posts
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.
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.
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 fo…
> 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. 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).
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 develo…
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.
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 fo…
Earlier quoted context omitted.
> 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. It's really about creating space!
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…
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?
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.
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.
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…