Choosing an IT operating model for the organisation you have

An organisation chart can make a small technology team look as though it has several separate functions. The same names may still appear in every box.

That matters when choosing an operating model. A design that assumes dedicated product teams, platform specialists and service managers will not work as intended if a handful of people must cover all those responsibilities while answering the support queue.

I would begin with the services the organisation needs and the decisions that keep getting stuck. The structure should follow that understanding. Borrowing the language of a larger organisation does not create its capacity.

Map services before reporting lines

List the services people depend on in terms they recognise. Staff access, customer transactions and management reporting are more useful starting points than a list of infrastructure components.

For each service, identify who understands the business outcome, who operates the technology and who can approve a change in service level or cost. Those roles can overlap, but the overlap should be deliberate.

Then trace the handovers. A central team might own identity controls while a business unit decides who needs a particular role. A supplier might operate an application while an internal owner decides whether its behaviour is acceptable. Clarify how a request moves between those parties.

Look particularly closely at responsibilities that have no comfortable home. Data correction, release communication and ongoing process changes can fall between project and support teams. Moving reporting lines will not resolve those gaps unless someone explicitly accepts the work.

Centralise where common decisions protect the whole

Common platforms and organisation-wide controls often need consistent ownership. I would be cautious about allowing each business unit to make independent decisions about identity, network connectivity or shared records without considering the wider consequence.

Central ownership does not mean every local request needs a senior committee. A central team can publish supported options, clear limits and a route for exceptions. That may let business teams move faster than an arrangement where they must negotiate each request from scratch.

The central team's service promise also needs to be explicit. If it controls the platform, it should explain how requests are prioritised, what help is available and how a business unit can challenge an unsatisfactory response.

Otherwise centralisation can become authority without accountability. Business teams experience a queue they cannot influence and begin looking for alternatives outside the agreed arrangements.

Embed ownership where understanding the work matters

A business area may need someone close enough to its operations to make frequent decisions about priorities and process design. That can justify embedded ownership without duplicating every technical skill.

In a fictional organisation, the customer operations team might own the backlog for its case-management process. A shared technology team maintains the platform and integration standards. The business owner chooses which workflow problem comes first; engineers decide how to implement the change safely within the agreed design.

The arrangement fails if the embedded owner can promise technical delivery without checking capacity. It also fails if the central team makes all process decisions because it controls configuration access.

Write down where each party has authority and where agreement is required. Business ownership in a technology project should continue after launch, rather than disappear when the project team closes.

Test the model against an ordinary absence

Before adopting a structure, ask what happens when a specialist takes leave, an incident arrives during a project release or two business units need the same person.

For a small team, a fully embedded model may create isolated specialists with no practical cover. A fully central model may leave nobody with enough time to understand individual business processes. A mixed arrangement can work, but only if shared capacity is allocated openly.

Specify the rules for interruption. Who can pull someone away from planned work? Which commitments move when that happens? How will the affected business owner hear about it?

Do not assume the person managing support can also provide uninterrupted project leadership. Check the actual pattern of demand. Making room for improvement requires a realistic account of that variability, not a neat percentage in a role description.

Supplier coverage can fill a gap, but include the internal work needed to direct and review it. Buying technical hours does not remove the need for service ownership.

Trial the boundaries before reorganising everyone

Choose one service or change stream and test the proposed arrangement. Agree the owner, decision rights, support boundary and escalation route. Run it long enough to encounter real work, then review what became easier and what became confusing.

Look at waiting and rework as well as delivery. Did requests reach the right person? Were decisions made at the intended level? Did incidents expose a gap between teams? Ask business users and the people operating the service, not only the managers who designed the model.

Make changes to the working agreements before assuming another restructure is needed. Some problems come from unclear priorities or missing information, neither of which requires moving people into new boxes.

If the trial supports a wider change, explain what will stop as well as what will start. Retiring an old approval route matters because people will otherwise keep using it.

A useful operating model lets people find the owner, obtain a decision and get help when a boundary is crossed. If those things remain difficult, the organisation chart is not yet doing enough for the organisation you actually have.