> 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.
> 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.
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.
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 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!
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
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.
> 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.
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..
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)
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!
> 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.
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).
> 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.
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.
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.
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).
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!
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”.
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.
When a team is too big
(blog.alexewerlof.com)115 points by gpi 19 May 2025 | 134 comments
Comments
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.
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.
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.
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.
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!
https://www.bobek.cz/the-power-of-written-standup/
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.
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.
I love this. I wonder if it is effective, or if there's any legal recourse should the LLMs ignore it.
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..
* (not a criticism; the topic is important to hackers)
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...
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.
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).
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.
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.
An internal billing team requires entirely different people and ways of operating than a startup's growth team iterating to product market fi.
also so much for ublock to block on that personal blog!
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.
One may disagree, but that likely means they are pontificating instead of coding. =3