4 ms·

The post makes a good case for why it's a bad idea to split a business problem into slices. Even though you have multiple small teams, they still need to closel

by scribu 6y ago

The post makes a good case for why it's a bad idea to split a business problem into slices. 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?

thablackbull 6y ago
> Even though you have multiple small teams, they still need to closely coordinate with each other. That's what a competent manager/management is for though.
- smitty1e 6y ago
  #DingDingDing 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.
- qznc 6y ago
  Not if management implies non-technical. Maybe an architect role would describe it better.
kislayverma 6y ago
I'm still writing it :)
huffmsa 6y ago
It's a bad idea when the slices aren't independently achievable. 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.
rapht 6y ago
> The post makes a good case for why it's a bad idea to split a business problem into slices. 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.
- pico303 6y ago
  These are great points. I disagree with a lot of this article, because it oversimplifies the problem without considering things like this. 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?

by scribu 6y ago

thablackbull 6y ago

> Even though you have multiple small teams, they still need to closely coordinate with each other. That's what a competent manager/management is for though.

smitty1e 6y ago
#DingDingDing 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.
qznc 6y ago
Not if management implies non-technical. Maybe an architect role would describe it better.

kislayverma 6y ago

I'm still writing it :)

huffmsa 6y ago

It's a bad idea when the slices aren't independently achievable. 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.

rapht 6y ago

> The post makes a good case for why it's a bad idea to split a business problem into slices. 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.

pico303 6y ago
These are great points. I disagree with a lot of this article, because it oversimplifies the problem without considering things like this. 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?