Yannick H.,
Too Long; Didn't Read
Many IT problems such as shadow IT, unclear responsibilities, and rising costs are not strategy failures, but organizational failures. An IT operating model clarifies who does what, what remains in-house, what is outsourced, and how decisions flow. Before you write your next IT strategy, first clarify how your IT function is set up.
A few months ago, we were sitting in a meeting room somewhere in German-speaking Switzerland. Manufacturing company, just over 200 employees, two locations. The Head of IT had invited us because "the IT strategy needs to be revised." The CEO was there too, the CFO, and a production team lead.
The first twenty minutes went as expected. Too many tools, the ERP is getting outdated, cloud yes or no, the budget is never enough. Then the team lead said something that changed the entire room: "Honestly, I don’t even know who I should contact when I have an IT problem. Sometimes I write to the Head of IT, sometimes directly to the service provider, sometimes someone from my team solves it themselves."
Silence. Then the CFO nodded. "Same here. And I also don’t know whether what our provider delivers is actually good."
That was the moment it became clear: the problem here was not a technology problem. It was an organizational problem. The question was not which tools IT needs. The question was how the IT function is set up in the first place so it can deliver.
Welcome to the topic of the IT Operating Model.
What it means and why it is missing almost everywhere
An IT Operating Model answers one single question: How is your IT function organized to deliver performance? Not what it should do (that is strategy), and not which technologies it uses (that is architecture). But how. Which roles exist. What is internal, what is external. Who decides what. How IT services flow to the business units.
When we discuss this with clients, it is almost always about very concrete questions:
Do we need our own Head of IT, or is an external CIO-as-a-Service enough?
Should application teams be centralized in IT or sit within the business units?
What should our managed service provider take over, and where is the boundary?
Who is allowed to make IT decisions without having to escalate?
Answered incorrectly, these questions cost money, time, and nerves. And in most companies, they are not even asked explicitly. They are answered implicitly, through habit and chance.
Back to our manufacturing company. Three IT people in-house, everything else with the service provider. On paper, that sounded reasonable. But reality looked like this: the three spent 80% of their time on day-to-day operations. Tickets, printers, password resets. Nothing was left for strategic topics. Management did not know the state of IT security. Nobody could touch the aging ERP system because there was no capacity. And in parallel, departments were building their own tools that IT knew nothing about.
Not a competence problem. A structural problem.
What we worked out together there was basically clarification on two levels. The first level: What stays internal, what goes external? The answer sounds simple, but it is not. We keep seeing two extremes. Companies that want to do everything themselves and build an IT team that can structurally never be set up well enough. And companies that outsource almost everything and lose the internal know-how needed to even assess whether what is delivered is right.
The healthy path lies in between. Strategic capabilities—meaning IT services that create competitive advantage or represent real risk—should be governed internally, even if they are partly delivered externally. Commodity services such as standard infrastructure, help desk, and patch management can be outsourced without concern. (We wrote a separate article on this: Does IT outsourcing really save money, or not?)
The second level: Centralized or distributed? Most companies think in binary terms. Either everything sits with the IT department, or each business unit does its own thing. Both have weaknesses that intensify over time.
Full centralization makes IT slow. The business waits on tickets, IT struggles with prioritization, frustration rises. And then shadow IT emerges. Not because people are rebellious, but because they want to get their work done. (Shadow IT is usually the symptom, not the problem.)
Full decentralization leads to duplicated costs, different stacks, and an integration hell that no one can keep track of anymore.
What actually works is a federated model. Centrally governed where centralization is essential: security, compliance, core infrastructure, standards. Left decentralized where speed is needed: applications close to the business, teams that work directly with specialist departments.
The missing piece: Who actually decides what?
For our manufacturing company, the biggest insight was not the internal/external or centralized/decentralized split. It was the question of decision structures. Because that was where the real knot lay.
In smaller companies, management often decides on IT because that is where the budget sits. This leads to IT decisions either taking too long because management has other priorities, or being made based on gut feeling. In larger companies, there are too many committees. An IT steering committee, a steering board, the CIO, the CDO. Somewhere in this concert, the decision gets lost.
What helped: a simple RACI model for the five decision categories that really matter. Strategic IT investments. Security-relevant decisions. Sourcing and vendor selection. Architecture decisions. Project prioritization across business units. No bureaucracy monster. Just clarity on who has the final say on which topic.
After two workshops, we had a new target model. The three internal IT people were positioned as IT Business Partners, as the interface between specialist departments and the service provider. No more Tier 1 support, but requirements management and vendor governance. Strategic management—meaning IT governance, roadmap, security oversight—remained internal, but was supported by an external vCIO who contributed two days per week. Operations went entirely to the managed service provider, with a clear SLA.
That sounds like a major transformation. In reality, it was not. Above all, it was a clarification step. Who actually does what? And why?
And that is exactly connected to what many companies call "digital transformation." We described this in a separate article. The cause is rarely a lack of willingness. It is that the IT organization is not set up to carry transformation. Too trapped in operations, no capacity for strategic work, no clear decision structures for cross-functional projects. An IT Operating Model is the prerequisite for making IT strategy executable in the first place.
In summary: Most IT problems we encounter are not technology problems. They are organizational problems. Shadow IT, unclear responsibilities, creeping costs, failed transformations. All of this can be traced back to one common root cause: it was never explicitly clarified how the IT function should be set up. Before you write the next strategy, make the next tool decision, or evaluate the next provider, ask this one question first: Does our operating model still fit what we expect from IT? The answer is usually more insightful than any technology evaluation.
This is exactly what we do: working together with IT leaders and executive management to define how the IT function should be set up. Without a large consulting apparatus. Pragmatic, direct, tailored to your context. You can find more about our approach here.
