Leadership wants a scaling framework rolled out across eleven teams next quarter. How would you decide whether scaling is the right fix?

## Diagnose before you prescribe A mandate to "roll out a scaling framework" is a proposed solution presented as a requirement. The principal-level job is to find out what problem it is a solution to, and whether it is the right one, without turning that into obstruction. Three diagnostic questions do most of the work. **1. Does one team work yet?** Every scaling framework assumes teams that can take an item and finish it inside their own iteration, to a shared standard, without heroics. If teams routinely carry unfinished work forward, if "finished" means different things in different teams, or if quality is discovered late, the group does not have a coordination problem — it has a delivery problem, and coordinating it only synchronises the failure. This is the most common and most expensive mistake in the whole subject. **2. Where does the elapsed time actually go?** Take a sample of delivered items and split elapsed time into *working* and *waiting*, then attribute the waiting. Cross-team waiting is what a scaling framework can address. Review queues, environment contention, unclear requirements and approval chains are not, and no amount of joint planning will move them. If cross-team waiting is a minority of the delay, a framework adds cost and fixes nothing. **3. Can the dependency be removed instead of scheduled?** Coordination is a permanent tax; an ownership change is a one-off cost. If most items cross three or more teams because the split follows the architecture, redrawing ownership is usually cheaper, and it makes any framework adopted afterwards much lighter. ## The four adoption pitfalls | Pitfall | What you actually see | The countermeasure | |---|---|---| | Scaling before one team works | The joint plan is fiction by the second week; every team reports "on track" until assembly | Fix team-level delivery first; scale a capability you actually have | | Ceremony inflation | Engineers lose a day a week to coordination events nobody can name an outcome for | Delete any recurring event that has not changed a decision in two months | | The framework as an org chart | New titles, same reporting lines, same flow of work; progress reported as percentage adopted | Change what people do first, then rename; measure flow, not adoption | | Agile in name only | Scope and date both fixed a year out, then delivered in iterations and called adaptive | Make the trade explicit: a fixed date means variable scope, said out loud to sponsors | The common thread is that all four substitute an observable proxy — a ceremony held, a role filled, a plan produced — for the outcome the machinery was supposed to buy. That substitution is comfortable, because proxies are easy to report and outcomes are not. ## How I would run the decision 1. **Agree the outcome in leadership's own terms** before discussing frameworks at all — usually predictability of a committed date, elapsed time per item, and defects found after assembly. Write down today's numbers. 2. **Measure for one planning cycle.** Dependency count per item, teams touched per item, working versus waiting time. That is a few weeks, not a quarter. 3. **Take the free wins first.** Remove dependencies that an ownership change can remove, and fix the loudest team-level delivery gaps. 4. **Pilot the lightest framework that addresses what you measured**, on a subset of teams, judged by the outcome numbers — not on all eleven teams at once. 5. **Set a removal date, not only a review date.** Every event and role introduced gets an owner and a date at which it disappears unless somebody argues to keep it. 6. **Report outcomes, never adoption.** The moment "percentage of teams trained" becomes the headline, the transformation has become its own goal. ## A worked example Eleven teams build a coach-tour scheduling platform on a 3-week iteration, and a partner integration deadline eight months out has become the reason to "scale properly". Measuring first shows: median 17 days elapsed per item, 11 of them waiting; 6 of the 11 teams routinely carry work across the iteration boundary; and 71% of all cross-team waiting sits between just three teams. That diagnosis rewrites the plan. Waiting concentrated between three teams is an ownership problem, not a programme-wide one, so merge or re-scope those three. Six teams that cannot finish inside an iteration are a delivery problem, and scaling them would multiply it. What remains that a framework would genuinely help with is thin: one assembly of the whole product each iteration, and a shared view of the deadline. So the recommendation is not "no framework", which reads as obstruction, but "the lightest one, on the four teams the deadline actually runs through, after we fix the six". And crucially: **not during the deadline**. Running a structural change and a hard external commitment at the same time guarantees the change is blamed when the commitment slips. ## What separates a principal answer - Refusing the false choice between compliance and obstruction: you counter a mandate with a measurement plan, not with an opinion. - Naming the cost of coordination in hours, and being willing to delete machinery you introduced yourself. - Sequencing structural change against external commitments rather than ignoring them. - Treating team topology as an available lever rather than a fixed constraint.