Org charts lie. They show reporting lines — who approves your vacation, who writes your performance review. But reporting lines tell you nothing about how work actually flows. The real organizational structure is lateral: who talks to whom to get a feature shipped, who blocks whom when something goes wrong, who has the context to make a decision. The formal org chart and the actual communication topology are almost never the same, and it's the communication topology that determines software architecture (Conway's Law).

Handoffs are where flow dies. Every time work passes from one team to another, you pay a tax:

• Delay — waiting in the receiving team's queue
• Context loss — the receiving team doesn't have the full picture of why the work matters
• Translation overhead — reformatting work items, writing specs, explaining requirements
• Feedback lag — the originating team doesn't learn about problems until much later

The more handoffs between "idea" and "production," the slower and more error-prone the flow. The ideal is a stream-aligned team that can deliver end-to-end without waiting on any other team for any step.

Dependencies are bottlenecks waiting to happen. Every cross-team dependency is a potential queue. If Team A needs Team B to provision a database before they can deploy, and Team B has a two-week backlog, Team A's flow stops for two weeks — regardless of how talented or hardworking Team A is. The solution isn't to make Team B faster (though that helps). The solution is to eliminate the dependency entirely — make database provisioning self-service via a platform team.

Utilization is the enemy of flow. At 100% utilization, queue times approach infinity (queueing theory). A team at 90% utilization has 9x the wait time of a team at 50% utilization. Keeping every engineer "fully utilized" guarantees slow flow because there's zero slack to absorb variability.