The Reorg That Did Not Fix the Platform Queue
TransCargo, a logistics firm with 2,500 employees, reorganized 18 months ago into eight stream-aligned teams and two platform teams. Feature lead time fell 30%, but cross-stream dependencies now consume 45% of team capacity; the platform team has a seven-month backlog; an architecture review board still approves every API change; and funding is annual by project. A new same-day delivery value stream crosses four streams and has no end-to-end owner. The COO proposes another reorganization into 'customer journey tribes.' The VSM lead is asked whether structure is the problem. Surveys show teams understand customer outcomes but spend much time in dependency meetings and waiting for architecture approval. The platform team is respected but understaffed for requests. Two streams share a pricing engine with no roadmap.
1. Is another reorganization the right first move? Diagnose using value stream and dependency evidence.
Read the worked answer
Another reorganization should not be the first move. The evidence points to interaction, approval, and funding constraints rather than team boundaries. Eight stream-aligned teams and two platform teams is a reasonable structure; the symptoms are 45% of capacity lost to cross-stream dependencies, a seven-month platform backlog, an architecture review board that approves every API change, and annual project funding. A new tribe structure would not by itself shorten the platform queue or delegate approval. Start with a dependency map: which streams depend on which services, how often, how long they wait, and what work is delayed. Map the same-day delivery value stream end to end, including the four streams, the pricing engine, and the platform. Then test whether a named end-to-end owner with funded capacity removes the worst waits. Consider structural change only after the constraints are visible and the cheap fixes have been tried. Reorg is a costly experiment with a long recovery time.
2. What changes to funding and governance would you recommend to evolve the value streams?
Read the worked answer
Fund value streams persistently rather than annual projects. Give each stream a capacity budget and a product outcome, and let it negotiate with platforms through service-level expectations. Fund the platform as a product with a roadmap, explicit internal customers, and capacity for both run and new services; a seven-month backlog is a funding and prioritization signal, not just a staffing problem. Replace universal architecture review with risk-tiered governance: automated policy checks and delegated approval for low-risk API changes, board review for high-risk or cross-cutting changes. Create an end-to-end owner for same-day delivery with authority over prioritization across the four streams, and give the pricing engine a named owner and roadmap. Keep guardrails for reliability and compliance. These changes evolve the value streams without adding another organizational layer, and they can be piloted with one stream and one platform service.
3. Which metrics would show whether the evolution is working?
Read the worked answer
Measure the constraints, not the org chart. Track cross-stream dependency wait time and the percentage of capacity consumed by dependencies; track platform request lead time, backlog age, and the percentage of requests fulfilled through self-service. Measure the percentage of API changes approved through delegated policy versus the board, and the lead time for those approvals. For same-day delivery, measure p85 end-to-end lead time from customer order promise to first successful delivery, plus on-time delivery and change failure rate as guardrails. Track funding cycle time and the percentage of stream capacity that is persistently funded. Survey teams on cognitive load and clarity of customer outcome. Baseline before the changes, review monthly, and look for movement in the top two queues. If dependency wait falls but change failure rate rises, the evolution is trading flow for risk and needs correction.