Building the Right IT Operating Model to Help Your Business Scale

The symptom is queueing, not cost

A broken operating model announces itself in waiting time. Measure any technology request (a new integration, a report change, access for a new starter) and split the elapsed time into work and wait. In a scaling business the wait usually dominates, often by a wide margin, and the wait is almost never caused by a shortage of technical hands.

The reason is structural. Requests queue behind a few people who hold both context and authority, and those people are also doing the delivery. Hiring more capacity into that shape does not shorten the queue; it lengthens it, because more work needs the same scarce approval.

An operating model is four decisions, and most documents cover only one

Written operating models tend to describe structure: teams, reporting lines, a service catalogue. Structure is the least load-bearing part. The four decisions that actually determine how a technology function behaves are how demand arrives, who may decide what, who owns each platform and dataset, and at what cadence change is prioritised and released.

Decision rights are usually left implicit, and therefore default to the founder or the most senior technologist. Making them explicit is uncomfortable: it means writing down that a head of function may commit spend to a stated level, accept a risk of a stated severity, and say no to a peer.

Standardise the backbone, vary the edge

Standardisation is worth paying for where the cost of variation grows faster than the number of variants. Integration patterns, identity, master data and reporting definitions behave this way: each new exception has to be reconciled against every existing one, so the tenth variant costs far more than the second. Customer-facing experience and genuinely differentiating commercial logic behave the other way, and variation there is often the point.

A usable test at the point of decision: would a second business unit, a new territory or an acquisition make this choice expensive to reverse? If yes, it belongs in the backbone and needs a standard. If no, let the team choose and move on.

The counter-argument: centralisation is often sold as an operating model

The standard prescription for a business outgrowing its systems is to centralise IT. Consolidate the tools, consolidate the budget, put one function in charge. It usually does reduce unit cost, and it usually does improve control. It is also, on its own, a procurement optimisation rather than an operating model.

The trade it makes is cost against lead time. Central functions add a queue and a set of standards to comply with, and for a scaling SME lead time is normally the scarcer resource: the cost of a commercial team waiting six weeks never appears on a budget line, which is why it accumulates unchallenged.

The version that holds up better is federated ownership with a short, non-negotiable list of standards: identity, data definitions, integration pattern, security baseline. Everything else is delegated with a named owner. That takes more nerve, because the centre must enforce a few things absolutely rather than many weakly.

Ownership has to be nameable, and there are two kinds

Every platform, dataset, integration and supplier needs one accountable name, not a team, not a committee. The point is not administrative tidiness. It is that an unowned thing cannot be prioritised, cannot be retired, and cannot have a risk accepted against it, so it accumulates silently until it fails.

The distinction that gets missed is between system ownership and process ownership. If the item master is owned by IT, then IT is accountable for data quality it does not create and cannot refuse. Nobody with authority is in a position to reject a badly specified new part, so the data degrades, reporting degrades with it, and the eventual remediation project is charged to technology. Put data ownership with the process that creates the data.

Fund capability, not just projects

Project funding quietly creates operating-model debt. A programme delivers an integration, a reporting layer, a set of automations, and then the funding stops. Nothing was budgeted to own them, so they default to whoever last touched the code. Two years later the estate is full of load-bearing components with no owner and no test coverage.

The fix is procedural rather than technical: no go-live without an agreed run-rate owner and an operating cost, stated before the business case is approved rather than discovered afterwards. It makes some projects look more expensive, which is the correct outcome.

Cadence is the model made real, and it has to be faster than the business

An operating model that exists only in a document describes intentions. What makes it real is rhythm: a quarterly forum where the roadmap is genuinely re-cut, a monthly one where architectural decisions are recorded with their rationale, and a delivery cycle short enough that a decision reaches production while its reasoning is still valid.

The non-obvious constraint is relative speed. If technology plans annually while the commercial teams plan monthly, technology is permanently a lagging function and will be routed around. The cadence has to run at least as fast as the planning cycle of the business it serves.

Where the internal leadership bandwidth for that rhythm does not yet exist, it can be borrowed before it is hired, which is the practical case for fractional CIO support during the period when the model is being rebuilt rather than merely described.

Sequence matters when you cannot build it all

Almost nobody can rebuild the whole model at once, so order becomes the decision. Identity and access first, because it is the dependency for everything else and the cheapest control to retrofit badly. Then master data definitions, because integration and reporting both consume them. Then the integration pattern. Reporting and analytics last, because they are only as good as what sits underneath.

Running that order in reverse is the common and expensive mistake. A reporting programme built on undefined master data produces numbers that are argued with, and the argument is resolved by rebuilding the reporting layer a second time.