Part one of three on the shape of the enterprise technology organization.
The constraint on how fast a large company can change itself has been technology capacity for thirty years. That is ending, and what replaces it is an organization that looks considerably less like a technology department and considerably more like the business it serves.
The Enterprise This Is Heading Toward
Thirty or forty small teams, each owning a piece of how the company actually runs.
Admission. Claims denial. Pricing. Store fulfillment. Each team four to eight people, led by someone who knows that part of the business, sitting inside the business rather than alongside it. Each able to define what should happen, build it, test it, connect it and see whether it worked — without leaving the team.
Underneath them, three utilities: infrastructure, security and identity, and the data platform. Consumed on demand, the way a company consumes electricity. Not queued for.
Above them, the ordinary management structure of any large organization — engineering leaders owning groups of domains, running down the business lines rather than across the technical functions. The hierarchy does not disappear. The leadership bench does not shrink. It stops being organized by what people do and starts being organized by what they are responsible for.
And then the consequence that matters outside the technology organization.
Changing how admission works becomes a decision rather than a program. It is made by the person accountable for admission, executed by the team that reports to them, in weeks.
The key point:
The limit on how fast the enterprise can change stops being technology capacity and goes back to being judgment.
Why This Is Possible Now, and Was Not Before
Every enterprise technology organization exists to close a gap — between what the business wants and what the systems actually do.
That gap was real, and it was wide. Spanning it required analysts, developers, testers, integration specialists and the managers to coordinate them. The organization was the bridge.
Two decades of reorganization were attempts to build a better bridge. Centralize for efficiency. Decentralize for responsiveness. Shared services. Centers of excellence. Agile at scale. Value streams with a platform organization behind them.
Each one improved coordination. None shortened the distance, because none could.
Then the distance closed, and not because anyone redesigned an operating model.
The vendor took the systems. Nobody staffs a database tier for Workday or writes a scheduling engine for an EHR. The hard subsystem now sits inside software you license, along with the specialists who used to tend it.
AI took the translation. Writing the requirement down, interpreting it, building to the interpretation, checking the interpretation was right — most of that chain is translation between people who cannot see each other’s work. Translation is what this technology does.
What remains at the two ends is knowing the business well enough to say what should happen, and judging whether what came out is good enough to use.
Both are business judgment. Neither is a bridge.
The key point:
How the bridge was organized was always a constraint. It was never the unlock. The unlock is that the gap closed.
Why the Current Shape Cannot Get There
A health system set out to automate admission. Twelve months, six business groups, ten technology groups — product ownership, development, testing, integration, data, network, cloud, middleware, robotic process automation, project management.
The result was partial automation and a queue of exceptions.
The exceptions were not technically hard. They were undecided. The payer response does not match what the patient said, the coverage is unusual, the situation had never been defined — so it could not be automated.
Every one of those ten technology groups could build. Not one could decide.
That is the failure mode of the current shape, and more people will not fix it. Neither will faster tooling. The project automated what had already been decided and queued everything that had not, because deciding required standing with the business that no technology group had.
The key point:
The exception queue is the organization chart, re-expressed as work.
The Lineage, and What Changes
Team Topologies described teams aligned to value, with platform and enabling teams beneath to carry the load those teams could not.
That was right, and it was written for organizations that build and run their own software. The platform team existed because the cognitive load was genuinely too high for one team to hold.
The vendor now carries that load. So does the machine.
What follows is a simpler structure than the one it replaces. Two kinds of team, not four. Domains that own a piece of the business end to end, and utilities that are consumed rather than requested.
The suppliers reached this conclusion before their customers did. Five of them launched units this year staffed by engineers who sit inside the client organization and work directly with the business — Accenture with Google Cloud in September, Microsoft and Amazon before that, OpenAI and Anthropic with their own. They are not selling more platform. They are selling proximity to the decision.
The Hard Question This Raises
If every domain owns its own work, who owns what crosses between them?
The patient’s experience of being admitted and then billed spans four domains. Each has its own leader, its own priorities and its own backlog. Autonomy inside a domain does not answer what happens at the edges of it, and the old shape at least had a program manager who could force a sequence.
The towers never solved this either. They made everything slow enough that the seam was not visible as a separate problem.
This model makes it visible, which is progress and is not a solution. Part three takes it seriously.
Final Thoughts
The organization most enterprises run today was built to supply resources to demand. An idea becomes a request, a request becomes an allocation, and the outcome is whatever survives sixteen groups touching it part-time.
Nobody built that badly. It was the correct design for a problem that no longer exists.
For anyone approving a technology operating model, there is one test worth applying, and it needs no technical knowledge. The last time an automation effort ended in an exception queue — were those cases hard, or had nobody decided what to do with them?
If it is the second, more technology will not help. The shape is the answer.
Part two covers how to cut an enterprise into domains, with healthcare and insurance worked through. Part three covers what breaks: the seams, the transition, and the people.
Tech Canvas 