Scaling a technology function is, before anything else, a question about the IT operating model that scope now runs through.
In Brief
- Technical IT operating models scale by adding coordination layers, because handoffs between specialised functions multiply as scope grows.
- More program management, governance forums, and integration effort absorb the new investment before it reaches delivery teams.
- The cost is hidden inside meetings, queues, and dependency management that look like progress.
- Seeing the operating model itself is the executive act that changes the curve.
The technology function is being asked to do significantly more, and the headcount is not moving. New systems. New integrations. New digital services. New AI obligations. All of it landing inside the same operating model that was designed for a smaller surface area. The expectation from the executive committee is that the function will absorb the new scope and continue to deliver. The function leader, in turn, looks at the model and sees that something has to give.
What gives, in most organisations, is not what the executive committee thinks. The function does scale. It absorbs more scope, takes on more programs, runs more concurrent work. The unit cost per output, however, climbs sharply. By the time the next budget cycle arrives, the leader is explaining why the marginal program cost more than the last one, why integration timelines stretched, and why a function that grew its workload by a third needed a disproportionate increase in supporting infrastructure to do it.
Handoffs multiply when scope grows
A technical IT operating model is organised around specialised functions: architecture, security, infrastructure, applications, integration, data, change, vendor management, program management. Each function holds a defined slice of accountability. Work moves between them through handoffs. A design is finalised by one group, reviewed by another, implemented by a third, integrated by a fourth, secured by a fifth, accepted by a sixth. Inside a small program, the handoffs are manageable, because the number of pairs of functions that must coordinate is small. Inside a large program, the same model becomes expensive in a way that surprises people who have not modelled the maths.
Handoffs between specialised functions multiply as scope grows. Doubling the number of concurrent programs does not double the coordination effort; it more than doubles it, because every new piece of work intersects with the existing pieces through the same shared functions. Each function becomes a queue. The queue produces wait time, the wait time produces escalation, and the escalation produces a governance forum, a paper, reconciliation across functions, and the meetings that hold those things together. None of it is delivery. All of it is paid for.
Coordination overhead absorbs the new headcount
The leader who scales a technical operating model by adding people inside the existing functions discovers, usually within two cycles, that the added headcount does not behave like added capacity. The new people enter the same queues. They produce more artefacts that have to be coordinated through the same forums. They generate more requests across the same dependency boundaries. The function’s output rises, but its output per person falls.
McKinsey’s analysis of 5,400 large-scale IT projects with the Oxford BT Centre, covering programs over $15 million in cost, found average overruns of 45% on budget and 7% on time, with 56% less value delivered than the original business case predicted (Bloch et al., 2012). That gap is the coordination tax made visible at portfolio scale. It is what the operating model produces when scope outgrows the design built to deliver it.
Forsgren, Humble, and Kim (2018) examined the same question from the opposite end. What do high-performing organisations do differently? They found that the throughput advantage held by the top quartile is structural, not effort-based. The top performers do not deliver more by working harder. They deliver more by reducing the coordination cost between teams, so that each team can take a piece of work from concept to production with minimal dependency on other teams. The implication for the function leader is that scaling by adding people inside a coordination-heavy model is the most expensive way to grow capacity. Most of the new investment is absorbed by the model before it reaches the work.
Each handoff looks rational alone
The reason the constraint is hard to see is that every individual handoff is rational, defensible, and often required. Architecture review exists because uncoordinated technical decisions create expensive remediation later. Security review exists because regulators expect it. Integration governance exists because shared platforms cannot accept arbitrary changes. Each forum, examined alone, has a clear rationale. The cost only becomes visible when the forums are summed across a portfolio, the queues are summed across functions, and the time a piece of work spends waiting is compared with the time it spends being worked on. That ratio tends to surface a number leaders do not expect; a number where waiting dominates working by a margin that is uncomfortable to publish.
Skelton and Pais (2019) describe the underlying dynamic as the cognitive load and interaction cost imposed by team boundaries. Their argument, drawn from Conway’s law and a decade of platform engineering practice, is straightforward. The structures organisations choose for their technology teams determine the design of the systems those teams produce, and therefore determine the coordination cost of every change. A model with many narrow functions produces systems with many narrow seams, and every change has to be coordinated across those seams. Structure determines coordination cost. Coordination cost determines how scope translates into output.
The dashboard hides the coordination ratio
A senior executive who looks at the function’s output by program count, headcount, and budget will see growth. The function is doing more work than it did last year. More projects are in flight, more vendors are engaged, more governance papers are being produced. By every measure that appears in the executive dashboard, the function is scaling. The measure that does not appear in the dashboard is the proportion of total effort that is coordination overhead rather than delivery, and it is moving in the wrong direction. An executive who asks the function leader for that ratio, and who treats the answer as the leading indicator instead of the headcount or the program count, sees what is actually being bought with each additional dollar.
Boston Consulting Group’s 2023 survey of senior executives reported that two out of three saw an urgent need to redesign their operating model for agility and resilience (BCG, 2023). That number is not a complaint about the people inside the function. It is a recognition that the model itself is now the binding constraint on what the function can do. The leaders who name it as a model question, rather than a resourcing question, are the ones whose next investment behaves like capacity.
Scaling the model is an executive decision
Scaling a technical operating model is a structural decision, and it sits with the accountable executive: the COO, the Secretary, the head of the function. It does not sit with the program management office, and it does not sit with the vendors who deliver inside the existing model. The decision is not which framework to adopt or which methodology to roll out. It is whether the next increment of growth will be absorbed by the same model that produced the current ratio of coordination to delivery, or whether the boundary of the next increment will be drawn around the work itself instead of around the functional specialties that handle parts of it.
The leaders who treat this as a model question, ahead of the next budget cycle, have a different set of options than the leaders who treat it as a resourcing question after the model has consumed another year of headcount growth. Naming the coordination tax for what it is, the price the organisation pays for handoffs between specialised functions, is the act that opens the second set of options. A function leader who can show the executive committee the curve of coordination cost against scope, and who can name the mechanism producing that curve, has done the work that lets the next decision be a structural one. That is the position available to any leader who chooses to ask the model question before the next program lands.
References
- BCG. (2023, September). How a platform operating model can drive agility and resilience. Boston Consulting Group.
- Bloch, M., Blumberg, S., & Laartz, J. (2012). Delivering large-scale IT projects on time, on budget, and on value. McKinsey & Company.
- Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The science of lean software and DevOps. IT Revolution Press.
- Skelton, M., & Pais, M. (2019). Team Topologies: Organizing business and technology teams for fast flow. IT Revolution Press.
