> This was less disruptive than taking 30 minutes (less than 3 minutes per person) for the daily standup, which often dragged to 45 minutes and sometimes even an entire hour!
More than anything, this sounds like no one was actually leading or moderating the standups. If you have standups daily, you should be able to give an update on what your status is in a minute tops, given it's business as usual. If there's any followup discussions to be had or questions to be resolved, the startup is not the right place to do that, everyone who is interested or affected can continue the discussion after the standup. This requires discipline from both the person leading and the participants, but we're talking about a professional setting here, this isn't a big ask.
Having spent some time living in Sweden, the situation described in the article is not too surprising to me. Swedes are incredibly nonconfrontational and even the thought of politely cutting someone off because they're talking too much in a standup would be faux pas for some.
Interesting observation about Swedes. I'm Dutch, and I've noticed Swedes and Dutch people and culture are very similar in many ways, very egalitarian and everything, but the Dutch are not hampered by politeness. And our brutal honesty might help keeping standups efficient.
I've been part of several "too large" teams, and one in particular, with 20 people, I was really surprised it worked so well. Standup would take 20 minutes, everybody paid attention. There were informal subteams that would discuss details outside the standup.
The most official subteam was the testers (first 2, later 4) who also controlled deployment, because everything had to go through them.
Somehow it was a very efficient chaos. Not scrummy at all; technically we had sprints, but everybody ignored them and it was more kanban. Some features would take months, others would be done quickly. Some would restructure much of the code base. I've seen PRs that touched hundreds of files. Somehow it all worked and it worked very efficiently. We even took over another project from a team in the US that was going nowhere, and we managed to deliver it within their original deadline despite the other team wasting a year doing nothing.
I still wonder how that team could work so well. We weren't all generalists; I was, but others would do only fronted, only backend, or spend most of their time thinking about taxonomies. The team did seem to foster a culture of friendly but brutal honesty without any punching down. Main tester and main backender would rib each other a lot. People eagerly took responsibility for fuckups. Everybody was considered an expert on something and nobody knew everything, so we'd consult each other a lot.
> but the Dutch are not hampered by politeness. And our brutal honesty might help keeping standups efficient.
Anecdotes are fragile; I've had the exact opposite experience, Dutch people taking offense for being direct when reviewing code.
You’ve never heard the anecdata that the Dutch are notoriously stubborn?
The offense could have been the Dutch person being direct about their stubbornness to feedback.
Also possibly a point in favour of political speech vs directness. Much easier to politic a stubborn person than tell them to do something directly.
Uh oh, multiple layers of anecdata! :)
Reading between the lines, my guess is that the standup was the only forum for communication that the team had, and lots of communication was required because people weren’t working on the same things. The only real solution to that is to get people talking outside the standup.
Turns out that when you already have a meeting scheduled every single day, people (except for a few) just stop seeking each outer at other times.
As much as this looks like a good thing superficially, dailies aren't fit for solving any kind of coordination problem, and that's the only meeting you will get.
I've had them go 90 minutes because they branch off into tangents from people's updates and they become a solution session between one dev and our manager. Info is pretty silo'd (not required for security or anything, just bad management) so usually nobody else knows what's up with their ticket and manager is in other meetings all day so he never responds to dms to help on stuff. I've tried cutting people off to keep it moving and have been reprimanded about it, now I attend with camera off and do my dishes during the meeting.
There is a value to standup in calling out "my PR needs eyes and nobody responded on slack" or "hey I'm blocked on X who wants to pair later" but outside that it's useless.
> they become a solution session between one dev and our manager
This happens when the manager doesn't understand the point of daily standups.
I've been on both sides of this. Ideally, the daily standup should be able to operate without a manager even being there: it should be a session between the team members who are actually doing the work, to give them a bit of time to come up out of the weeds of what they're working on to make sure that they're not getting themselves stuck, or to unstick their teammates. The meeting is only as long as it needs to be. In practice, people aren't really good about keeping Jira up to date, or will bury themselves into a rut to power through a problem.
If it becomes a solution session between a manager and a dev, while everyone else on the team stays on mute to witness all of this, that belongs in a different meeting.
90 minutes is not a standup. Keep it brief. If something needs to be discussed in more detail, take it outside the standup with just the people interested in that issue. A good standup is often followed by a bunch of smaller meetings to discuss details or help people who are stuck.
The absolute best thing about spending so long remote (I think I've been remote for the vast majority of the last 25 years) is that I can and will stand up for stand ups. This helps remind me to keep it brief and remind everybody else too. There's a guy literally stood up on screen, why are you discussing the minutiae ?
It's awkward to do this in person (although after so long I'm in the habit enough that I will un-selfconsciously just stand up in a room full of people slouched at desks to attend the same meeting in person) so I can understand why people don't form the habit but I am quite sure it has been valuable.
We used to do this on my pre covid teams. There was a big touch screen that we'd all walk over to, someone would log in to and open jira on. Now we have the 30-90 minute mega meeting instead :(
I get so many chores done during sprint ceremonies, including standup. Every session is a continuation of the same horribly inefficient planning/refinement/status update combo which doesn't effectively accomplish any of those things, and I've stopped caring because I just go to town with a mop.
'This requires discipline from both the person leading and the participants, but we're talking about a professional setting here, this isn't a big ask'
In my experience anything that requires discipline is too brittle to last. You can argue it should not be so, but it is.
Instead of discipline, an extrinsic force, robust motivation should be intrinsic, born from delivering a real value feeling to all participants.
> More than anything, this sounds like no one was actually leading or moderating the standups.
One of my clients hired a former U.S. Marine. I so enjoyed attending the meetings he ran. He managed the clock with ruthless efficiency.
Tangent: Way back when I was in Scouts, the scout master was a USN missile submarine captain. He was a quirky guy, not the least of which was his ability to schedule things to ridiculous levels of detail... cross-country trip to go backpacking, and he'd have a lunch stop at 13:14, gas stop at 17:29, on base (we would stay in open barracks at military bases across the country) by 16:09. And wouldn't you know it... we were usually within a few minutes either way. And he managed to pack a lot of side-trips/value into the days we were on the road. It was really wild.
I would never suggest people join the military to learn how to run a schedule correctly, but I will say that it's hard to find someone who was in the military - and borderline impossible to find someone who was senior in the military, especially a senior NCO - who is habitually late.
I once did an international camping and backpacking trip like this where we had everything down to a minute.
The key is to check your watch after you complete any activity. For example, you read that a 1000ft climb hike takes 2 hours and you do it in 2.5 hours.
Do this over months and you gain the ability to make perfect estimates. Turns out that feedback loops are useful.
Also applies to all other skills.
Funny thing is I’m mostly a buy tickets to fly next week and wing it kind of person but I wanted to try it one time for kicks. Winging it is a whole different set of skills. Get good at both and planning becomes your jam.
One problem with efficiently running standups is that ... they are the most useless meeting in the world. It is short, ok, but nothing whatsoever would change if it did not happened.
They are not useless to me.
I need to keep my fingers on the pulse of what happened yesterday and what’s happening today, and what potential impediments might arise to make key decisions without asking everyone.
I strongly disagree. It's a brief moment every day to see everybody, check up on what everybody is working on, and notice if anyone needs help. Every part of that is useful.
It is quick status report, purely form exercise. You hear names of tasks you know nothing about and have no idea whether you can help. All the useful parts happen when it is ineffective and people discuss details.
It shouldn’t be a status report, though. This information is already in Jira or whatever.
Someone running a standup meeting where people just repeat information is by definition not doing an efficient job at all.
There is only so much information one can fit into 1 minute long report. The thread is literally defining effective standup and a quick one where people answer the "what have you done, what you will do" questions. The one where discussion is cut so that it is as short as possible.
You're the one complaining about "hearing names of tasks you know nothing about" but you're also the one saying it should consist of "what have you done, what you will do".
It doesn't. :)
Stand ups are not for status reports, they're for syncing. "I have a big PR coming so please check it today". "I am still stuck with the sprongler bifurcator but I expect to be over tomorrow". "I need to involve someone from team X, their stuff is blocking me". "Ok, Y, let's chat after this meeting".
I did not defined what standups are supposed to be. But I would point out that the senteces you suggested are irrelevant to other peoppe in 95% cases.
And this is painfully obvious to anyone not working in tech, where there seem to be some kind of blind spot for such obvious micromanagement bs as standups. "Yeah, we really trust you, but you need to give a status update in-person every day on-top of keeping a up-to-date written log".
What does management have to do with it? They're not involved. It's for the team.
The closest middle-manager? They come with a whole range of titles.
We did the same in apartment maintenance — a career completely unlike tech.
We’d stand around the managers office, take thirty seconds to say what we planned to do, what dependencies we had (eg, who needed the truck when) and then went off to do our tasks. Even though we also tracked project work in a time system.
A real standup isn’t that unusual, nor micromanagement. Though it can turn into that, when badly utilized.
> what dependencies we had (eg, who needed the truck when)
So in practice, that's a truck-sync meeting that needs to happen every day due to shifting needs and thus actually useful. Seems like there is room for improvement there but might not be worth it for them?
I also don't think certain management cultures would ever want to skip reaffirming the workplace hierarchy on the regular, but that's certainly not a culture I'd want to work in - but at least that's usually honest that it's just status updates to the boss and not hidden behind some nice sounding methodology bs.
IME, a standup is just repeating JIRA tasks 99/100 that's not useful for anyone beyond perhaps the extroverts that just wants the face-time, people who rarely reads chats, and ofc management for said office politics.
Usually you've already had a weekly/bi-weekly planning meeting distributing tasks in a rather granular size that are available for everyone to see progress on. Then you have easy-to-access direct communication channels through Slack or similar for ad-hoc questions to anyone at any time. Have a question? Just ask? If that's not enough I'm a lot more inclined to believe that the team is dysfunctional.
I genuinely think it's a shame that the autonomy & trust that other fields can offer people with proven qualifications/past work is not being offered, instead you're stuck in various infantilizing rituals when you're building a house that you've already built multiple times and don't need hand-holding to do so.
But there's some serious amounts of gaslighting going on in the field to explain that a tracker on your car is trust & autonomy.
From my experience as a SWE over the past ~15 years working in teams ranging from 10+ engineers in large companies doing daily in-person standups, to ~5 engineers in small remote-first companies doing daily videocall or async standups, and everything in between: the standup ceremony is a waste of everyone's time. Its only purpose is social/political as with any meeting, and giving micromanaging managers something to do and something to report to their higher-ups (I've been part of teams where the "Scrum Master" and even "Product Owner" attends the standup...). Which is fine if that's the way the company works and the participants enjoy the ceremony for personal reasons, but there are no tweaks to the standup formula that makes teams more productive or functional.
If I'm working on a solo project, nobody cares about the details of my progress besides the users I'm building it for. Whether this is an API for someone who is part of the standup, or a feature for someone in the company, I would communicate with them directly when needed. They would already be aware of my progress, and they usually don't need to be informed of it on a daily basis. If I'm stuck on something, then I would also communicate directly with the person who can help me.
If I'm working on a team project, the team members would already be aware of the project status, whether that's via pull requests, issues, or direct communication (in-person, chat, email, etc.). The users of the project would be notified of the progress as needed in this case as well.
So the standup ceremony is redundant for the few people familiar with the context, and completely useless for those who are not. The standup assumes that teams aren't communicating already, which is ludicrous.
It's about time that the industry accepts that the Agile manifesto, while noble in principle, has been completely misunderstood and corrupted in all its implementations, and that the modern software development process is not an improvement over the Waterfall one it aimed to replace.
To me the only process that makes sense is giving engineers autonomy, assuming they're self-sufficient and capable of making good decisions, and providing them with a very lightweight set of tools for collaboration (issue/task tracker, code review, chat, email, meeting, etc.). A process that works best for that team will emerge by consensus. Anything that's imposed from the top down or by cargo culting some process that worked for some other team will inevitably cause friction and be of little practical value.
As with many things, it depends on the team. Some teams and people really do seem to need some amount of daily direction to have confidence in the work they are doing, and that does have a meaningful impact on productivity.
My bias is always to only participate in frequent recurring meetings as a last resort, but sometimes they seem to be necessary.
One of my basic philosophies, when I ran a team, was “No regularly-scheduled meetings.” Every meeting needed a specific goal and need.
But I worked for a Japanese company, and they take meetings very seriously.
One of my employees suggested daily standups. I tried to support my employees, when they suggested new stuff, so I said “let’s give it a try.”
The Japanese Liaison really liked the idea, but it needed just a little tweak…
In a short time, we were having hour-long meetings every Friday at lunchtime.
Regular meetings, as opposed to ad hoc ones, help establish a consistent team cadence.
Yes, but they can also affect morale, and slow things down (by quite a bit).
ToMAYto, ToMAHto...
> giving engineers autonomy
That is almost as offensive as a slur to management in 95% of companies
If everyone gives status updates that are either "Task is progressing as expected" or "I'm blocked as I mentioned on slack yesterday", then what is the point of the standup?
Presenteeism check. Roll call, just like grade school.
To be entirely unfair, I think that's always been the real reason for the standup "ceremony" to get a daily roll call because developers doing "agile" apparently can only be trusted if treated like school children. I feel that way because that's always been a part of the point of why it is called a standup: it's supposed to be as boiled down as just "progressing" or "blocked, who can help?" and it's supposed to be done standing up so that it is intentionally uncomfortable and everyone moves quickly to get back to their seats and get back to actual work getting done.
I continue to advocate that standups are mostly useless and should just be a Slack message at most.
That's my thinking too. At my workplace we shifted to longer 30min meetings every two days where people actually get to explain what is currently blocking them. Usually it'll already have been mentioned in the teams chat but the higherups aren't super active there and this lets them know how stuff is going and why.
These meetings aren't really standups anymore though.
> always been the real reason
It can't "always" have been the reason. The original intent of agile was that it was by the developers, for the developers. It's unlikely the originators of agile decided they needed to treat themselves like "school children"
Standups weren't in the original Agile Manifesto. Standups are most directly a Scrum-specific thing. Scrum was just one of the contributors to the Agile Manifesto, alongside Extreme Programming and some others.
Scrum has always been the one with more "ceremonies" and more middle management involvement at each step, adding Product Owners and Scrum Masters as entirely new classes of middle management. Given how often teams devolve into "Scrumterfall", that sometimes seems like the "natural state" of Scrum. Scrum was designed to make Waterfall companies happier with Agile. Scrum has all these ceremonies and extra middle managers that are just Waterfall things done more often and closer to the engineering team.
It's so very easy with hindsight to believe that Scrum was the "wolf in sheep's clothing" among the Agile Manifesto writers that didn't always believe in the goals of the Agile Manifesto. Especially "Individuals and interactions over processes and tools": just because they are called "ceremonies" doesn't make them magically stop being meetings and processes and tools. It's kind of worse than that because ceremonies implies rituals implies religious tones of control.
I certainly feel like Standups are a bad idea designed to make Managers happy. The kind of middle managers, especially, that feel some command-and-control need to treat developers like "school children" because they don't understand what the developers actually do and don't really care. But maybe I've just had too many terrible "Scrum Masters" in my life (what a terrible term, what an awful job role, what a waste of middle management bureaucracy) and there's some "ideal" Scrum I've never seen where that isn't the case.
(We probably would be far better off if more developers had listened more to the Extreme Programming side of the Agile Manifesto house, despite being confused/turned off by things like Pair Programming that made it "extreme". Though it was also things like Pair Programming that made Standups seem especially silly to XP, since you never not had someone to bounce blockers immediately off of in Pair Programming.)
This is all true. Though my recollection at the time was that the original platonic ideal was that both the scrum master and product owner were at least peers, if not devs on the team. Especially the SM. But it didn't take long for the product owners to start living in the product management branch of the corporate hierarchy, and not long after SM became its own profession.
The people that invented Scrum aren't developers. They pretend to be, but make all their money with courses and management consultancy.
And go try to fit "required daily meetings" on the Agile Manifesto to see how well it fits. (The people that made this one were mostly developers. All working in a very specific area making very similar software, but developers nonetheless.)
Not my experience working in Sweden for the past 10+ years. Likely that I had outlier experiences here but standups have always been short, the person leading it had complete autonomy to call out "I think this should be discussed after stand-up" whenever some discussion started to go on for a little longer (usually about 2-3 minutes is too long).
The thing I noticed being culturally different is that you just don't cut off someone while they're speaking, you raise your point by politely asking for the space and sharing your opinion, and decisions about it are made through some consensus (which never failed when a discussion is going on for too long).
It's definitely possible that culture matters. I wonder if there's something about American work culture that makes their standups so often dysfunctional. I'm Dutch and I have pretty good experiences with them in most projects.
> The main value of a standup is to have a dialogue about blockage and spark opportunities to work together.
I never understood this about “blockers” as classically presented during the rites of standup. If you’re waiting up to 24 hours to voice a blocker or work with someone to resolve it, you’re waiting too long. Jump in chat with your team, tell them how you tried to unblock yourself first, then ask for help.
> If you’re waiting up to 24 hours to voice a blocker or work with someone to resolve it, you’re waiting too long.
Yes, but that's part of the point. A lot of people wait too long, and a standup makes sure it doesn't wait even longer.
Daily standups are a first line of defense against all sorts of bad practices.
But also, standups increase visibility so things get addressed and escalated faster. Maybe you thought being blocked wasn't a huge priority, but the team lead realizes it is and ropes in someone from outside the team to help.
It's odd, because I've known folks who 'wait', but most of the time, when I hear someone voice a blocker in a standup, it's notice that "this is already something I've tried unblocking by ABC, and have talked to persons XYZ, and it's still a blocker". Or sometimes, people saying "I was blocked yesterday on X for Y hours, which is putting things back a bit, but now moving forward again".
So yeah, waiting until a next meeting to get announce that you're going to start working on a blocking issue is nuts, but I don't actually see that specifically all that much.
This is what I see as well.
"I ran into X, tried Y and Z, then asked Bob, Bob wasn't sure, anybody else have ideas?"
Or
"We discovered a dependency on Team Z to complete Q, Mr Bossman, can you talk to their manager, as the engineers weren't sure what to do?"
And yes, both of those could be handled in Slack. But, as a manager at a medium/large company, the amount of Slack messages I get daily is MASSIVE (both direct and in channels), so a face-to-face has some value in getting the issue front-and-center (and not lost in a pile of clutter).
Yes, in a perfect world, there isn't all the clutter in Slack. But, in 25 years in industry, that's rarely true.
slack is a slug
we need to reduce the number of slack messages. not increase the number of meetings.
i want to build something like that at some point.
Zulip has been extremely effective in eliminating the need to read every message for my team. Clear public and private team channels and general “feature” channels too. Might be a few too many; but an interesting fact: in most companies there are as many channels as there are employees!
What's the value of saying you were blocked but now you aren't?
The other case is you're saying it's a reminder. But that should be obvious from any ticketing system - the issue for what you're working on should be set to Blocked and the manager should get a status update email or be able to check it next time they're free.
I think the answer is some managers prefer to have people tell them things in a call.
> What's the value of saying you were blocked but now you aren't?
Going in to huge detail about it, not much, really.
A quick "hey, hit an issue yesterday with ABC, Kris helped me out - thanks Kris!" does a few things.
It reminds everyone we all might need to ask for help now and then.
Gives a bit of public recognition to Kris who might not otherwise get it.
Also lets people know Kris (and now you) know a bit more about issue ABC in case they might have a similar issue.
When I hit weird snags, they're not always things I'd detail out in a ticket, especially if unrelated to the specifics of the ticket. "Add links to help documents" as a ticket doesn't benefit much from me documenting out that I hit some weird issue because the security team didn't add accounts to a new policy group, meaning my emails to the accounting team were bouncing. "Kris confirmed it was an issue for her as well, and reached out to Kevin's group to let him know, and we got things resolved yesterday". Yeah, you could add that to a ticket, but feels useful to mention that in a status meeting. Larger discussion about the process behind those changes or scheduling impact should be taken offline outside the meeting.
"...should be set to Blocked..." do you do that the moment you aren't making forward progress on something? It's something I wouldn't typically do until after some amount of time understanding why I wasn't making progress, and trying to 'unblock' things first within a short period. Days of unblocking attempts without raising a flag are generally not good, but 3 minutes of 'being stuck' before pinging others is also not great imo.
> What's the value of saying you were blocked but now you aren't?
Pattern detection. As a coder, your job is to get past blocks and deliver features at quality and on time. As a manager, your boss's job is to take information in from their directs, synthesize a picture of what's actually going on, and work to make your life easier (and thus, you more productive) in the future. "I was blocked for four hours yesterday because <x>" isn't a big deal, for you; but seeing the commonalities in <x> across the whole team, and over a longer period of time, motivates action to understand the /underlying/ problem and improve it in the future.
> What's the value of saying you were blocked but now you aren't?
It tells management why a task is behind schedule, more or less.
This is hard in big teams/departments because people end up getting pinged constantly to unblock random stuff. They want to batch up and schedule things. People work on 2-3 things in parallel anyway so they can switch tasks when blocked, like Javascript. So 24hr can be the sweet spot, but as I said in another comment, I've seen the mistake of picking 7d instead!
Well, it's unprofessional to just sit and twiddle your thumbs when you're "blocked."
I always find something else to work on. Chances are whoever is blocking me is also busy too.
When I manage people, I always assign them multiple tasks and make it very clear that if they get stuck on one they are to move to the next. Then the next time we meet we can figure out how to unblock tasks.
It’s a maturity/seniority/team cohesion thing. Junior devs might stay blocked for a week without a nudge in some pathological cases. A new team that hasn’t gelled might do the same.
A seasoned team full of staff engineers might not need standup at all.
There are people who are reluctant to ask for help with things (i know i can be), and end up wasting time trying random (non-)solutions. The standup puts these people "on the spot" and enables them to move forward within a reasonable timeframe.
When daily sync is a trigger for changing org. structure, this is a classic case when the symptoms hide the real sickness. The engineering team was struggling, but it was not their fault and their "solution" in the end forced some people to leave. It is sad. The actual sickness: inexperienced middle management, not aware of best practices. 11 direct reports are too many to maintain awareness of their work and their well-being.
How it should have been solved?
1. 2 or 3 smaller teams supported by product manager. More cohesion, more focus on long-term business objectives, more end-to-end long-term ownership (but high enough bus factor). Have daily sync within those teams and let someone well-socialized steer it, do not make it a report, instead focus on cooler talk and one big task that is currently in their mind. Force them to omit details and schedule ad-hoc talks or go async if they want to go into details. The primary objective of daily sync is to keep people connected, not to keep them updated.
2. Maintain specialization and expertise. When there is a dependency, people are forced to collaborate, build bridges and improve efficiency of communication. When one generalist completes the whole task, the smaller is the knowledge transfer. Generalists are good for one-off tasks, but building a product requires a team.
3. Use horizontal organization for engineering excellency. Call it chapters or whatever you want, but make engineers from different teams working on the same stack meet regularly to present ongoing work, discuss technical topics and technical strategy. Have async channels for that communication too (e.g. pull requests for something noteworthy).
4. People over processes, processes for people. If something does not work, use retro to fix it. Sometimes applying solution to the whole team won't work, but it may work on personal level - do it, as long as everyone remains productive and happy.
People should at least understand that "generalist" route with modern frontend and backend is nearly impossible today, especially when stacks are different. They are vastly different domains developing at a high speed. Nobody is able to maintain up to date knowledge of them both while doing sufficient amount of work without getting burned out quickly.
I think your approach would work for a larger company than the article was about.
Edit:
> "generalist" route with modern frontend and backend is nearly impossible today
This is simply not true; it all depends on design and organizational priorities. An organization can choose to use the same language in the UI and server, and prioritize the compromises that come with same language development. (IE, C# + Blazor, or Typescript + NodeJS.)
11 engineers is a big enough company to split the team.
In some cases it may work, however building great UX in browser is not the same job as performance optimizations or security of a server application even on the same stack. Generalist can build a CRUD app, sure, flex layout and ORM are not rocket science. Going beyond that is like finding a unicorn. Such people do exist, but they are rarely found in an average company. C# or Java UIs are a different story, of course, but I’m not sure they should be called “frontend”.
Wow that is really insulting.
I don't consider myself unicorn, and I do full stack, including UI work in C#.
Go update your assumptions.
Every situation is different. It really depends on so many factors: what are skills, traits, and preferences of the individuals? How top down are requirements vs bottom up? How distributed is the team? Does the team work on platform, product, or infrastructure? There is no one sized fits all answer to what works best in all situations.
Honestly, I think there are no "best practices" here, there's simply "patterns I've seen work before".
If we put people over processes, you might actually find you can manage a much bigger org. Like if the standup is really killing large parts of the week, you might find killing the standup to be the preferable option. The fact that that's sacrilege and constantly evokes the no true Scotsman tells you all you need to know about people over processes.
>Honestly, I think there are no "best practices" here, there's simply "patterns I've seen work before"
I have been working in the industry for more than 25 years and in many very different companies, even different cultures. Yes, that may be my own experience. I have been in continuous exchange with my colleagues in a big network of European CTOs and I validated it enough to say, that it can be considered a best practice. What it makes different from a law of nature is that best practices do not always work in every possible situation, but they are expected to work in similar environments.
>If we put people over processes...
Do not forget the second part of the sentence in my comment. Processes must exist - you cannot eliminate something that serves some real need and expect things to get better. By reducing number of meetings you cannot make management job easier or scale it to a bigger team, on the contrary, you will be doing a shitty job. The sole purpose of a manager is to be an oil in the engine, to facilitate the efficient process, and that includes information exchange and empathetic connections. Not to code, not to move tickets, not to write down the requirements. To talk. If people do not talk, do not engage with each other, you fail at that, because the social fabric of the team will rot. Everyone in the team and in the company has their own agenda and their own goals. If they are not aligned continuously, all sorts of toxic environments may emerge.
>Like if the standup is really killing large parts of the week, you might find killing the standup to be the preferable option
15 minute meeting cannot kill large parts of the week by the definition of time measurement units. It's 3.5% or less, depending on how long is your working week. If this meeting takes more, the solution is to stick to the time frame, not to cancel.
I've been in the software engineering industry for almost 30 years and my take is there are no 'best' practices, only 'fit' practices, as the article articulates so nicely. So many times I've seen processes and organizational structures change, each time imposing it's for the better. It's not converging to something 'better'.
It is a matter of word definitions, really. E.g. a team may call a "best practice" something that they repeatedly mention as "keep doing" on a retrospective and maintain the list of them. It's just what works well and what's reproducible and not something to be canonized in a holy book.
One may call it a "best practice," another may call it "fit practice," but at the end of the day I have no doubt that were Ivan to step in to lead our org it would change for the better :-). As they say there is no arguing with working code
> I have been working in the industry for more than 25 years...
I mean sure, but that's not evidence of best practice with any sort of rigor around measurable outcomes.
> Do not forget the second part of the sentence in my comment.
I think the problem we have here is you're acting like my suggestion that there's other successful ways to run a team somehow detracts from your own success. It's worrying that you've jumped to viciously defending your position by suggesting I'm essentially shit before the conversation really started.
Talk about toxic, eh?
Here's another nugget. Learn to deal with dissenting opinions in a more thoughtful and amicable way and perhaps you might not need to spend so much time "aligning" people.
>I mean sure, but that's not evidence of best practice with any sort of rigor around measurable outcomes.
Of course, it is not. I doubt that there exist many management practices that were measurably proven to be effective. It's just an explanation why I perceive those as best practices. They have worked for me and my peers in a reproducible way.
>my suggestion that there's other successful ways to run a team >Learn to deal with dissenting opinion
Please elaborate on your dissenting opinion and try to avoid personal attacks. What are those ways?
> Please elaborate on your dissenting opinion and try to avoid personal attacks. What are those ways?
Killing shitty meetings, including the standup, was one of those dissenting opinions, obviously.
Here's another.
PMs, or any other role that abstracts the developers from value, serve to infantilise the developer. Instead of owning the most expedient way service a customer or generate revenue, they're instead owning the minutia of frameworks, architecture, or tooling.
Of course, you can still make an argument for the PM via efficiencies and skill specialization, but when you effectively give a non-technical person control of what the team works on, you in many circumstances no longer have a person with a view across both commercial and technical realities.
And whilst there are many ways to try and plug this gap, like Engineering Managers or arguments like you're holding it wrong, where exactly are these tech leaders learning those skills when in the vast majority of teams the PM keeps them in the dark? Thus, propagates the cycle where the technical are not commercially mature enough to make business decisions, which necessitates the need for adults in the room.
Point being, it's a trade-off and there's circumstances where the trade-off makes sense, and others where it doesn't.
Our large team had a problem with long weekly standups. To alleviate the pressure to list tons of details in standups, we designated certain senior team members (I'm one) as owners of certain pieces and gave them their own optional weekly standups. These had agendas people added to throughout the week. This isn't a startup with quick reflexes; we're all busy with many things in parallel and like predictable schedules, or so we thought.
That was even worse. It encouraged people to delay important discussions until the next meeting for that part. The meetings had generic names and sometimes very small agendas, so people started skipping, and then important topics would come up with the wrong set of people present. Guess what, the main meeting was still long too.
We tried async reports too, like the author said. I dunno, it doesn't sound like a bad idea in general, but it didn't work for us. People are too busy to read things they're 75% not involved in.
Eventually I deleted my own standup meeting and told everyone I'd call same-day or next-day meetings only as needed. That worked perfectly. Everyone we needed was in the right place (or video call) at the right time, nobody was just passively there, and there was a clear and important agenda. It more than made up for the short notice. And I do realize writing this that it probably sounds painfully obvious to anyone in a more nimble company.
I would recommend a slightly different approach to written/async standup. Issue I have with stand-ups is the ad hoc nature of proving a report, instead of making it a collaboration space
I really need to see if my uni has a copy of my old essay on this topic.
Basically I pulled a bunch of data out of gamasutra post mortems and sort of reverse engineered the data towards optimal small team management.
My finding was similar. Basically its as far as you can go with a horizontal team in a single room.
6 Coders sharing an attic - good management outcomes and outsized performance
25 coders in 3 teams in a large office - bad management outcomes and communication difficulties.
> Note: No generative AI was used to create this content. This page is only intended for human consumption and is NOT allowed to be used for machine training including but not limited to LLMs. (why?)
I love this. I wonder if it is effective, or if there's any legal recourse should the LLMs ignore it.
When your LLM starts caveating things with "No generative AI was used to create this content. This page is only intended for human consumption and is NOT allowed to be used for machine training including but not limited to LLMs." you know they ignored the request.
We're almost there. If you train models on the output of Llama, they (try to) force you to use a particular name for example. As Meta starts to squeeze Llama (developer/research) users eventually, I'm sure they'll try to legally prevent you fully from doing so unless you use their (hypothetical future) platform/service:
> If you use the Llama Materials to create, train, fine tune, or otherwise improve an AI model, which is distributed or made available, you shall also include “Llama 3” at the beginning of any such AI model name.
I wonder if they can train in something like the name so deeply that you can't untrained it without torturing the model so badly it just spews out garbage.
Depends on the jurisdiction obviously (seems in this case Sweden/EU), but I don't think the author could blanket ban it like that, as research organisations and cultural heritage institutions have exceptions for example. I think news organizations and archivists have exceptions too, but less sure about that.
Besides, I think for it to actually have any effect, it would have to be in a machine-readable format, I'm not sure placing a notice like that in the middle of a HTML document is good enough.
> Art. 4(3) applies only on condition that right holders have not expressly reserved their rights “in an appropriate manner, such as machine-readable means in the case of content made publicly available online”. According to Recital 18, “it should only be considered appropriate to reserve those rights by the use of machine-readable means, including metadata and terms and conditions of a website or a service. […] In other cases, it can be appropriate to reserve the rights by other means, such as contractual agreements or a unilateral declaration.” In other words, Art. 4 right holders may effectively prohibit text and data mining for commercial uses by adding robot.txt type metadata to their content online.
https://copyrightblog.kluweriplaw.com/2019/07/24/the-new-cop...
But maybe the author already have the same notice in a machine readable and of course I'm not a lawyer or anything, so this is just guessing based on what I've learned about the regulations that affect me personally in Spain/EU.
https://blog.alexewerlof.com/robots.txt
Gives a small hint. It should be respected and effective.
I enjoyed this notice coupled with the presumably unlicensed Family Guy image below it
I guess I'm not reading the article then, since I'm not human.
I do not love this. I stopped reading right there. I’m not giving losers who are too lazy to write their own blog posts with their own words my engagement.
The hypocrisy of it is astoundingly obvious. The author used AI trained on stolen content to help write their blog post but then denies “the next author” from benefitting in the same way. If you love AI so much you should let it steal your content and train on it.
Classic “pull the ladder up behind me” mentality.
I think you missed the leading "No" in the sentence, "No generative AI was used to create this content"
I think “going full generalist” is perhaps not a generalizable solution, though directionally it’s good advice if you have more than two dev roles (or maybe two plus Q) in a 10-person team.
No mention of task composition, but I wonder if framing stories in terms of user needs was another missing piece. It sounds like you were giving updates on low-level eng tasks not user stories.
When I ran a team of this size, sure the implementation details of a technical task wouldn’t make sense, but generally we had a frontend and backend engineer buddy up to own a user story, and reporting to the team was mostly at the level of “we are shipping feature X for customers Y,Z - API work turned out to be gnarly, let’s break out and have a backend guild design session asap”.
If you have QA then the “three amigos” approach is nice, product owner, dev owner, and tester all sit down and craft a story that is mutually comprehensible. If you achieve this then you can feel confident that others on your team will also understand the framing of the story. Takes discipline though!
This article speaks to me a lot because I have been meaning to become more of a generalist, cause my role in security (specifically web-bot detection) seems to be too narrow of a niche, which is fine while it lasts, but doesn't seem too resilient to change..
But I also do not wish to get into leetcode type-stuff.. so I have been thinking maybe getting some devops/sre/cloud-infra type-stuff.. not-sure.. if anyone else has been through this, it would be great to hear how you transitioned..
If you have or can make the time, some side projects can go a long way. Mainly to find out what you are actually interested in. I usually give myself some guard rails as to not spend too much time one one thing (perhaps say a month) and then see where that takes me.
Then, I write about the project for two reasons: I get an article out of it that I can share _and_ I get to digest the project as a whole.
Just pick anything that seems interesting and build something. Later, you can even build on top of earlier projects.
This morning I was recently reflecting on a similar experience. I worked on a project where client and server were different teams. A problem we had was that a lot of server tickets were accidentally labeled as client tickets.
Should we have busted down that silo and said that there are no longer separate client and server teams? Ultimately, what I realized was that we started shipping multiple different clients that used the same server, and that it was impractical for everyone to be on the same team and have a hand in everything.
I do wish that we siloed a lot later and remained generalists longer; or at least that part of the team was generalist and floated between the two teams.
Laughed when I read ”We where 11 engineers that could be fed with 2 pizzas”. But you are in Sweden? You can feed maybe 3-4 engineers with 2 Swedish pizzas. Which is also coincidentally a very decent team size ime!
One of the under-appreciated impacts of Ozempic is that we can make two-pizza teams much bigger.
Another 'hack' to increase the size of your two-pizza team is to buy crappier pizzas and 'forget' to buy enough drinks.
on the other hand, the more liquid the engineers drink, the less space their stomach has for pizza. so by increasing the soda-budget you can save on pizza, therefore saving in total.
maybe only serve milk or protein-shakes to further increase this effect.
> You can feed maybe 3-4 engineers with 2 Swedish pizzas
I dunno, we (Swedes) tend to do personal pizzas (1 per person), at least where I grew up. They're most likely talking about family size pizzas or something, but even then it sounds like too little, you'd feed maybe 3 people tops per family size pizza.
Or maybe me and my friends were just overly excited about our pizzas.
I've assumed the 2pizza-thing was based on something like 'familjepizza' rather than the regular swedish size.
I agree about team size, 3-5 is good, any larger and people will start wandering off on their own or create cliques.
I'm also not a fan of "sync standups", that's micro management garbage. A three minute 'i'm blocked, who can help?' or 'no blockers today' session, that's the sweet spot. If someone wants a report on progression and so on they can book a meeting with a clear agenda in advance and the relevant people can prepare and do a succinct description of where they're at. No meeting that takes more than five minutes and doesn't have a set agenda should ever be held.
I'm mostly with you. However, dailies are little "dayplanners" for the team, too. For the benefit of the team as a whole, I'd suggest more context, like "I'm still on the state machine, but should be done today. After that I'll start on the DB migration. Jenny, I'll ping you then." or "Still fighting the runtime for the Box ticket. I need a second opinion."
Takes only a few seconds more. Of course, the Dev should know beforehand what he is going to say ;)
That's implicit in the blocked/not-blocked. If I care about the state machine I'll flag that I'm blocked and ask if I can help, if I don't then I don't want to hear about it unless you want help and preferably first in a group chat where I can drop in when it suits me and we can share snippets of code and data directly while figuring things out.
Things like planning, ETA:s and the like that management roles are nervous about should be handled in another setting, because these are open-ended activities that might take one minute or thirty and making those decisions requires preparation that should absolutely not, ever, be done during the meeting. This takes discipline on the part of the manager, who has to figure out a clear purpose, who is a relevant participant, ask them individually when they have time, reserve the room or equivalent, write the invitation with agenda, send it out.
Commonly it's more done like 'we have a problem', 'ok, we'll meet after this', and then people waste half an hour doing a defective version of that process as an unnecessary group exercise.
I've been in many 15min meetings that I felt were a good use of time, cause everyone was involved the entire time and the topic was important. Not so many 30min ones; those usually end up being 2 people talking while the rest spectate.
The 2-pizza thing coined by Bezos means 6-8 people.
Three minutes being the sweet spot for me comes with some conditions. For one the team has to be remote first, or real good at async self-organising anyway. One aspect of that is that people show up in the video conference before the meeting starts and do the social idle chatter about sports and television or whatever in advance.
I'm guessing most of those fifteen minute meetings had a set topic, or agenda as I called it previously, and ended as soon as it became clear that it wouldn't be immediately productive or the relevant decisions were made. I've been in many, many fifteen minute meetings where someone spent the entire time in palpation for something that could drag it out for even longer.
It's not uncommon that people are brought into meetings to basically engage in parasocial comforting of someone in a position of leadership they don't have the maturity or competence to perform in, in organisations that did very little to support their assigned leaders. I find this practice quite offensive and that moving away from such ceremonies to people calling a meeting making clear in advance what they want answers to and giving the participants time to prepare paves the way for trust, accountability and flexibility in the work that allows the team to respond better to challenges.
Pretty much. Some 15-minute meetings are bogus after 5 minutes like you said.
Some headlines, such as this one, are catnip to up-voters* despite the article's contributing nothing to the established discussion c. 2015, let alone 2025. I don't know how you disrupt this dynamic and redirect to "go read X", where X is _Team Topologies_ or whatever, but it would improve HN.
* (not a criticism; the topic is important to hackers)
I've always used this as my basis for thinking about team sizes: https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus... - personally I say teams are ideally 4 -/+ 2 only.
In Leading Teams[1] J. Richard Hackman says 6 max based on this research: https://www.jstor.org/stable/2786271
[1]https://books.google.com/books/about/Leading_Teams.html?id=w...
I don’t know. With the advent of AI-productivity tools (regardless of where we stand in how much the actual boost is), EMS should be able to offload part of their admin work and devs should be able to deliver more and faster. Long way to say that I'm skeptic if those numbers still apply in modern or near future environment.
That's a really interesting perspective that I hadn't considered!! Per the first link, a lot of these ideas are based on how well a human can manage in their head what another human knows/doesn't know/is doing/isn't doing/etc. We can only manage so much of that. I still don't think a human can manage more than 6/7 complexities, and so I don't know if I think 1 human would be able to work with say 30 AI agents as 1 team, for example. Could 1 human work with 1 agent who controls 1000s of AIs, I think so, is this the part you think changes?
> Front-end, back-end, QA, DevOps, etc. are all different concerns for the same outcome and impact.
Overall, I got the feeling that in their field business execution matters a lot more than technical knowledge or optimization. Which might be the majority of companies around, and why so many teams can get by with full generalist teams. And I suppose the money part was in line with priorization saving the business.
That's not an advice I'd give to anyone randomly. A company that is successfully growing in business and tries to tackle harder challenges along the way will benefit from going the other direction IME, and progressively push for more specialization to get better results without having to aggressively grow the teams.
Solution: people become full-stack developers.
The story is interesting and gave a lot of value but the end result is underwhelming.
Any dev worth their salt can learn enough of a different discipline in the dev field. Or maybe I am biased because I was “raised language agnostic at uni”.
Wait, it’s not the result that’s underwhelming. It’s that it almost reads as an insult that people have the expectation that learning different dev disciplines might be impossible. I just can’t see what is impossible about a different discipline when you are already an experienced software engineer with a CS education.
If one came from a coding bootcamp, yea then I get it (I taught at one).
A possible solution, perhaps, but i personally wouldn't consider it a good one.
I can full stack dev, i choose not to because i don't like the current state of the front end ecosystem but that's a preference not a limitation.
I can also do devops, standard sysops, data engineering/analytics to a degree and some other misc stuff.
I would absolutely not expect that to be a *requirement* to be a member of a functional team.
> Any dev worth their salt can learn enough of a different discipline in the dev field. Or maybe I am biased because I was “raised language agnostic at uni”.
Setting aside the true scottsman of that statement, the technical ability needed to learn other disciplines isn't always the limiting factor.
Not everyone has (or chooses to allocate) the time to keep on top of the multiple sets of ecosystems needed to keep up with all the disciplines, being language agnostic is one the least important parts of being effective in multiple dev disciplines.
but you are fullstack, it doesn't mean you work in all steps of the software lifecycle but you potentially could. That's the point.
That's a possibility for me, sure, but your original reply was basically:
"a solution is, everybody should be able to do everything, that way we don't have to do any actual skill based resource management because everyone is interchangeable"
with some vague allusion to "if they can't do everything then they probably aren't good at their job"
My reply was that i don't think that everyone being able to do everything is a good solution to what i think should be a skill resource management problem.
There are people who have the time, ability and resources to pick up (and more crucially , stay up to date with) all the disciplines, i don't think that should be a *requirement* and i don't think making it one is a good way of doing things in most circumstances.
Oh I can do backend work, but I'll easily introduce performance issues, log too much or too little, get lost as soon as I open one of our observability dashboards, or design an inefficient database migration.
Likewise, I've seen more backend-focused people introduce horrible accessibility issues, completely misunderstand the client-side lifecycle, or produce a giant mess of intertwined global state.
It's useful to be able to wield all the tools to some extent, but I've found true full-stack to be a mess. (Where "true" already means "works on web APIs and in-browser code", i.e. still ignores large parts of the stack.)
There are plenty of projects where frontend/backend is a logical way to separate things, in which case it can be much more cost-effective to hire frontend specialists. Not only are they more familiar with all the specialized tools, but they can also do it with only bootcamp education.
I've been in teams with generalists only, and yeah we can all deal with UI, but it takes longer. No matter how good someone is, they can't have every detail fresh in their head all the time.
Or what about a full stack that's backend-backend, in a large corp with multiple internal services talking to each other? Only the higher-tier engineers have a good understanding of all the teams' moving pieces, even then not so deep.
It’s a flawed solution because it only works for this specific technology. It only works with full stack web developers because the breadth of the subject matter isn’t too wide.
Sometimes a team has to consist of people who have very different specialities that simply do not intersect and are too burdensome for all team members to gain proficiency in. There is often no budget to split the team or the team is already very small. This article doesn’t offer a solution to that problem.
Example: you’ve got an operations team of four people plus a manager. Most of the company runs on a containerized application using modern open source technologies, but then there’s an important legacy cash cow application that involves an Oracle stack running on Windows VMs. Are you really going to make your Kubernetes/Linux team members learn to operate the Oracle database and Windows servers that your specialists on the team manage? Will they even want to do that work without quitting and working somewhere else?
By the time you acquire enough experience to do it in 25+ years of lunches the job market starts showing less interest in you. But that's the only promising strategy in the LLM-dominated world I guess.
> Note: No generative AI was used to create this content. This page is only intended for human consumption and is NOT allowed to be used for machine training including but not limited to LLMs.
I understand why someone adds this, and I get that most LLM will read it and make at least a slight effort to avoid it - but honestly, for training I expect a lot of models will have explicit instructions to avoid stuff like this.
But on a deeper level, this is stupid. Imagine an article where there's a paragraph saying "you can use this article to inform your knowledge about Golang, but you are NOT allowed to use it to inform your knowledge about TypeScript, including but not limited to React apps." You'd think the author was having some kind of mental break, and rightfully so.
If you want to publish your content, publish it. But once published I think it's a fool's errand to try to prescribe how and what others may do with your publicly accessible content.
This is literally what software licenses are - do you think GPL etc. are fool's errands too?
This isn't software, it's a blog article. Different things are different.
Can you imagine a book with a page in the front that says "you may use text for graduate course study at an accredited university, but not for undergraduate study or autodidactic reading?" People would read it (maybe) then then go "huh that's weird" and continue doing whatever they were going to do with it. It's the same with this article.
IP is IP. LLM vendors are in legal battles with all sorts of IP owners. Putting it explicitly there (as awkward as it is) creates a legal obligation where the company or individual that fed it to "AI" cannot deny: "oh! I didn't know, therefore it's not stealing"
> I think it's a fool's errand
What should we do about it?
Don't paternalistically prescribe what others may do with your content after you publish it. If you have strong feelings like that, don't publish it, at least not in a way that is just publicly accessible like a blog.
There’s another aspect that the author doesn’t touch upon that seems to materialise when a team reaches a certain size - politics.
For whatever reason, whenever you have more than about seven people in a team (in my experience, anyway), office politics seem to appear as an emergent phenomenon, and instead of people pulling together to a common goal they’re suddenly trying to undermine one another.
My best theory as to the why is that too many direct reports result in vying for attention of a manager, and people rapidly realise that outperforming others in their team doesn’t work nearly as well as throwing shade at one another.
Our solution was to constantly rotate - task oriented teams formed and dissolved on a per-case basis. This broke the cycle of power-brokering, and limited the fallout from whatever petty drama was manifesting this time.
> My best theory as to the why is that too many direct reports result in vying for attention of a manager, and people rapidly realise that outperforming others in their team doesn’t work nearly as well as throwing shade at one another.
This just sounds like a more deeply rooted work culture problem to me.
I suspect it's more of a human nature problem. Perhaps a good work culture might allow you to delay its oncoming slightly past 7 people - but eventually all large social groups get political dynamics.
Yep - I mean, to some extent, he’s right, as the problem was that there ended up being a perceived divide between team leads and teams - so with the rotating teams everyone who wanted to got to have a go at wearing the team lead hat, which both allowed people an opportunity to interface directly with the big bosses on the regular and feel seen (even though we were very much hands on with everyone anyway), and to understand that herding cats wasn’t as much fun as it looked like from the outside.
One aspect this article doesn't feature that's super important imo is the difference between a team that's figuring something out and a team that's keeping something going.
An internal billing team requires entirely different people and ways of operating than a startup's growth team iterating to product market fi.
Please elaborate
The solution arrived on here sounds a lot like the original meaning of the term "devops", and Amazon/AWS' concept of a T-shaped engineer - a generalist with deep knowledge in one area (or a least, AWS is where I personally got acquainted with these terms).
https://en.wikipedia.org/wiki/T-shaped_skills - around since at least the 1980s. Broadly speaking it seems like an accurate description of good engineers. (I've also heard "pi-shaped", to more explicitly suggest that experienced engineers probably have multiple areas of deep expertise.)
Could have been titled "When a team lacks sufficient reason for colleagues to care what others are up to"
this post was all over the place - what was the actual point? is a big team or a small team better? i'm more confused after reading that than i was before i read it!
also so much for ublock to block on that personal blog!
What's the ublock block thing?
Surprised these people had to iterate and run these experiments. I thought all of this was common knowledge in books. Maybe it was an experience before this was common knowledge, but it’s not uncommon to see “painfully figure something out instead of cracking open a book, write a blog post about it like it’s some new found knowledge”.
Could you be more specific about which book and chapter talked about this problem and how the solution was different or similar?
The team notion doesn't scale. Open source software doesn't require teams or managers. They just have developers. Lots of them typically. Since they are not part of a team, they need to figure out how to work together. And they have to do that without the typical things you would have in a corporate setting (like a boss that can dictate and re-assign people).
That sounds nice and utopian. But of course a lot of OSS software is actually being developed by companies. Most open source that matters has corporate backing. So, the two models are not mutually exclusive. Many large corporations have to figure out ways to scale development. And often they have to work with other companies or even rivals on some stuff. When you have hundreds of thousands of employees, hundreds/thousands of different software packages and components with hundreds/thousands of people involved each, things get very complicated.
A lot of successful organizations emulate a lot of what happens in large OSS projects. Not surprising, because many large OSS projects take contributions from those same organizations. So you have a large intersection of OSS developers that also are part of a large company.
Regardless, any sufficiently large software will just have lots of people working on it. Many more than fit in a traditional team. So, you need coordination mechanisms. The persons that release and integrate software have a lot of power. They get to gate keep what goes into the software. In the OSS world, git repositories are read only for most developers. You don't push changes into them, you ask for your changes to be pulled into them. Politely. And then you work with whomever is deciding about whether to do that to ensure the change happens. It's a good model. If you don't like it you are welcome to fork and create your own release.
It's how Linus Torvalds can impose deadlines on releasing a new kernel while working with thousands of people. It's brutally simple: provide your patches before the merge window closes. It's your problem if you don't make that deadline.
That's not the only way but a lot of large projects use the calendar to coordinate and release regularly as clockwork. And many companies seem to do the same. People simply self organize around that. You can't have stability if a lot of people are running around with their hair on fire around every deadline. So, a lot of the self organization relates to vetting and rejecting bad changes before they become a problem. You push the problems back to the source of creation and wait for things to be sorted out there. And then you simply bundle things up and ship them.
The rest is just Darwinism. Bad developers/teams won't get their changes in and will eventually lose their funding (and motivation). And better ones will get more of their changes in. It requires collaborating with other stakeholders, it requires effective communication, and it requires some skill.
If a module requires more than 7 software people, than your team designed the project wrong.
One may disagree, but that likely means they are pontificating instead of coding. =3