When a team is too big
30 comments
·May 19, 2025Etheryte
martindbp
Then the conclusion is that stand-ups don't work in Sweden, as we're very unlikely to change our entire culture to fit the American work style. When left to our own devices, the tendency is to overshare in order to show that you're doing (important) work, and once several people do it, you need to do it as well to show you're not slacking. And so it balloons. For some (i.e. me) I also have trouble focusing on what others say before me because I need to think about what I did the day before and focus on what to say. This is even more likely once the length of stand-ups balloon (as they do wherever I've worked). I described this to someone and they suggested the problem is not with stand-ups, but that instead I have psychological problems. But I suspect many are like me.
cweld510
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.
piva00
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).
makeitdouble
> 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.
teeray
> 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.
mgkimsal
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.
bobek
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
mettamage
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).
NilMostChill
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 multiple dev disciplines.
agge
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!
diggan
> 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.
cess11
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.
Propelloni
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 ;)
null
protocolture
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.
pards
> 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.
diggan
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.
blitzar
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.
diggan
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.
dangus
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 clicks.
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.
abhaynayar
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..
lknuth
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.
FinnLobsien
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.
madaxe_again
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.
jlowgren
> 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.
cplan
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).
JoshTriplett
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.)
> 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.