The military analog is the fire team (3-4 ppl) or the squad (5-14 ppl), depending on how hungry they are and what the current theater demands.

Squads can be assigned multiple discreetly accomplishable objectives. Each squad is assigned to secure a different building on a street, for example.

No one squad is necessarily codependent on the success of the other squads to meet it's own objective, but when you pull back a level, overall organizational success (securing the neighborhood, winning the fight in the city, winning the war) is dependent on the success of all of the squads.

The article argues, and I agree, that as a company grows, it's easy to shift from discrete squads to assembly line squads. Eg data ingestion => data transformation => data delivery. Platoon / company level objectives, not squad level ones.

I have the analogies, but not necessarily and better solutions.

Why it's a bad idea is indeed demonstrated. But why it happens in practice is not just to obey the "small team" mantra. It's also because as organizations and products mature, the law of diminishing returns kicks in: once easy gains have been made, achieving more gains requires tackling more complex problems - either because they are actually more complex in themselves, or because of the environment has become more complex.

> Even though you have multiple small teams, they still need to closely coordinate with each other.

> But I can't find the next post in the series which proposes a better alternative. Anyone else had better luck?

That complexity actually means that whatever the way you organize, you're going to have more people involved. That's when you need good managers - what I call a good manager is not only competent to manage their own team, they're also good at making their team play in a more global picture without necessarily having a boss telling them to do so.

Another related problem it forgoes discussing is the idea of planning. Once these problems get harder, the need for people to sit down and design a solution grows, sometimes exponentially. Yes, you need good communication, but you also need something to communicate and agree on. How many small teams in big orgs have even a simple design doc to work from?

That's what a competent manager/management is for though.

And perhaps the Product Owner vacuum is filled in the sequel mentioned above.

The other point I was awaiting was documentation. Thank you to the one who at least threw a ransom note into the wiki. My software archaeology project would be impossible otherwise.