Thread by @johncutlefish

Common pattern

1/8 - An organization has many "product teams", but the teams lack autonomy, the work is riddled with cross-team dependencies, and the teams share team members (e.g. product, design, data science, and ops).

2/8 - Rewind, and you often find a well-meaning attempt to support small teams...and a manager who was having difficulty reigning in the mess, and wanted to have a smaller # of ppl report to them. "We just can't have meetings this big!"

3/8 - The org optimizes around this new structure. Ppl are hired to support and manage it. Team members are hired to join X team. You start to see team-level roadmaps/backlogs.

Now, small teams ARE good, the are, but...

4/8 - the org wasn't ready to support these teams, and in many cases the key driver was efficiency and cleaner meetings, not efficacy, customer value, and team autonomy.

5/8 - the big problem is that all this structure -- the fiction of independent teams -- actually makes it much harder to fix the underlying issues. It is intuitive, and solves short term pain, but it actually makes things worse.

6/8 - The "solution" isn't necessarily to have 30+ person stand-ups (though that might be the right thing to do). But you need to keep people more fluid, and visualize the dependencies. Solid 2-6m missions for 3-6p, and then maybe reconfigure. Swarm on the real impediments.

7/8 - the important point is don't create a fiction, and don't prematurely optimize (or more like reactively optimize). If you do, you'll be dealing with surface symptoms for a long time to come. Once the veneer is in place, it gets hard to really sense.

8/8 - finally, if that 80 person meetings seems impossible -- but it actually reflects reality, and you've tried to fix this with 12 managers with poor results -- consider liberating structures and other approaches to have the big event occasionally.