Common pattern…

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).

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 number of people report to them.

We just can’t have meetings this big!The org optimizes around this new structure. People 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, they are, but 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.

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.

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–6 month missions for 3–6 people, and then maybe reconfigure. Avoid locking down ideal structure before you ucan really support ideal structure. Swarm on the real impediments.

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 the real nature of the problem.

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.