Building a “Good” IT Operating Model Has Nothing to Do with Tools

Conversations about IT operating models almost always begin in the wrong place. They open with org charts, tooling decisions, or maturity frameworks that suggest there is some final state of completion to reach. As if one day the organization unlocks “fully mature IT” and can finally check the box.

That mindset is completely and utterly misdirected. In fact, it would be like trying to fix a spiderweb with a hammer.  In environments such as complex manufacturing, technology and systems are layered over years of operational decisions. Everything is interconnected. There is no static end-state because the business itself keeps evolving.

This is not a point in time to achieve and declare victory like a teenager reaching their 18th birthday and is suddenly declared a mature adult.  Victory is for milestones, maturity is for growth.  This misconception causes confusion and misdirected efforts.

What often happens is that organizations chase the appearance of maturity. They invest in recognizable platforms or adopt big-name solutions. They point to tooling as proof of progress. The real measure of an IT operating model is not the logo on the software. Quite the contrary, it is the organization’s ability to consistently translate business intent into reliable execution. Can strategy move cleanly into systems? Can systems produce dependable outcomes on the floor?

That is the difference between looking mature and operating effectively, because an IT operating model is not a fixed design. It is a living, breathing, (complaining) system. As complexity increases, as products change, as supply chains shift, the operating model must adapt and grow. As business matures, so must IT.

Why Complexity Exposes Weak Operating Models

If an IT operating model is a living system, complexity is the stress test. Add a new product line, and suddenly planning, procurement, quality, finance, and reporting all feel the impact at once. A healthy model flexes and absorbs the pressure. A weak one fractures under it. It exposes weaknesses quickly and in ways that are operationally and financially visible. In manufacturing environments, production schedules do not tolerate ambiguity. Inventory data either reconciles or it creates disruption. System releases either align or they collide. When something breaks, the impact shows up immediately on the floor and in the numbers.

As organizations grow, their technology ecosystems expand alongside them in response to the growing needs of the business. New applications are added, integrations multiply, and data dependencies begin stretching across teams and facilities. From the outside, that expansion can look like progress. In reality, much of it happens reactively. A tool is implemented to solve a pressing issue. An integration is built to hit a deadline. Another system is layered in to fill a gap. Over time, the environment becomes more complex, yet the operating structure required to coordinate, govern, and sustain that complexity rarely evolves at the same pace.  Like a teenager outgrowing a t-shirt, the growth stresses the confines of the operation model that contains it, reducing their ability to serve a proper purpose.

The result is misalignment and messiness. Stu has his feelings hurt, and Diane’s deadlines get missed. Development teams can be technically strong yet operationally hamstrung. Releases move on different cadences. One system changes without full visibility into downstream impact. Fixes escalate into production issues. At that point, IT is strained because governance did not evolve around the environment it created.

The Risk of “Stu” from IT

As complexity grows, many organizations begin to rely heavily on a single steady hand. Every company I have worked with has a version of Stu. He has been there for years and carries the institutional memory of the environment. He knows which server can be touched and which one cannot. He remembers the workaround that quietly became mission critical and understands the jobs and dependencies that keep operations running. When something breaks, people go directly to him because he knows not just what to do, but why it works.

That arrangement can feel efficient and even reassuring. Issues get resolved quickly and production continues without prolonged disruption. Leadership may recognize there is risk, yet it feels manageable because someone experienced is holding the system together. Over time, that dependency becomes normalized.

If you’re relying on Stu, you’re living in your parents’ basement.  For a time, this is necessary and beneficial.  It may always be right for you, you may never reach the point where your IT model needs to mature beyond Stu’s security and dependability.

The exposure becomes clear when Stu retires or leaves. If his knowledge was never documented, shared, and built into formal processes, the organization is suddenly vulnerable. What looked like operational stability reveals itself as dependency. Recovery slows down, confidence drops, and the cost of rebuilding that knowledge increases quickly.

A strong IT operating model captures institutional knowledge before it walks out the door. It formalizes processes, builds cross-training into the structure, and distributes accountability so continuity is embedded in the organization rather than concentrated in one person.  It teaches your organization to be ready to leave the nest, just in case it matures beyond the need for its shelter.

When IT Doesn’t Know What to Work on Next

One of the clearest signals that an operating model needs attention is simple: does the IT team know what it should be working on next, and why? In more organizations than leaders care to admit, the answer is unclear. Work gets pulled forward based on volume, visibility, convenience, friendship or enmity. The loudest request wins. The quickest fix gets prioritized. That approach can survive at small scale. As complexity increases, it quietly drains capacity.

I have seen high-impact initiatives stall for months while low-leverage tasks consume the team simply because they were easier to start or one person was more liked than another. That pattern is rarely about laziness, lack of skill, or value. It reflects an operating model that does not provide structured intake, clear business ownership of priorities, or visibility into capacity and dependencies. Without those elements, IT defaults to reacting. The business feels ignored. IT feels pulled in ten directions. Frustration grows on both sides, even though both are responding rationally to the system they are operating within.

Shadow IT Is a Symptom

When alignment breaks down, the business adapts. Teams are not trying to bypass IT to be rebellious. They are trying to move. This is normal growth stressing the confines of a model that it is outgrowing.  If requests stall, if timelines lack clarity, or if explanations feel disconnected from outcomes, people find alternatives. They purchase tools. They build their own workarounds. They solve the problem they feel most closely because it feels urgent.

That is how shadow IT emerges. Framing it as a control problem misses the point. In most cases, it is a response to perceived delay or opacity. When the operating model cannot respond at the speed the business expects, the business stops waiting.

I have watched these quick fixes compound complexity over time. Security exposure increases. Data fragments across systems. Integration debt accumulates quietly. What began as a practical workaround becomes another layer the organization has to support. A strong operating model does not shut down innovation. It makes collaboration the most efficient path forward so teams do not feel forced to operate outside the structure.

But it’s a give and a take, an ebb and a flow.  An IT operating model that matures too fast for the business creates boundaries and red tape that constricts as much as a lack of capacity to meet the growing needs does, just as a parent can place too strict guidelines that force rebellion and resentment for the adult dwelling below them.

Translation Is Operational Work

One of the most underappreciated aspects of IT maturity is translation. Business leaders speak in outcomes such as throughput, margin, risk, and customer impact. IT teams speak in environments, dependencies, releases, and architecture. Both perspectives are valid because they are different teams with different needs. Neither stands alone, and a house divided cannot stand.

This is where structured roles and forums matter. Project Management Offices, Change Control Boards, and Centers of Excellence often get labeled as bureaucracy. In healthy environments, they serve as connective tissue. They create a shared language around tradeoffs. They surface dependencies before they become production incidents. They connect work to measurable outcomes rather than activity.  They provide a way of directing two teams’ focus on solving a shared issue, not on the other’s inability to understand their feelings.

The goal is not to create layers for their own sake. The goal is clarity. Over time, shared understanding reduces friction and shortens conversations. Translation never disappears entirely because different roles carry different accountability. What improves is the speed and quality of alignment.

Release Discipline Changes Behavior

Release discipline is one of the most practical shifts that transforms organizations with complex business and IT environments. When teams operate on independent timelines, disruption feels random. One deployment conflicts with another. Emergency fixes override planned work. Prioritization becomes reactive.

The needs of the business reach a point where Stu can’t just understand what should be done next.  They need to be prioritized by the business through clear communication, and just as clearly organized by IT into time-based, attainable achievements.

Aligning release cadences changes the conversation. The business must decide whether a request justifies an out-of-cycle deployment or can wait for the next scheduled release just as IT must be able to demonstrate what will miss in the next release if their efforts are redirected towards a fire drill. Tradeoffs become visible. Urgency is weighed against impact and stability. Those discussions are uncomfortable at first because they force clarity. Over time, they strengthen trust because expectations are explicit and consistent.

Wrong Versus Hard

Leaders often conflate hard with wrong. Some issues are objectively wrong because they introduce risk, waste money, or degrade customer experience. Those require correction. Many other challenges are simply difficult because coordination across systems and functions is complex.

Scaling IT in a manufacturing environment is hard. Aligning releases across plants, business units, and integrated systems is hard. Saying not yet to a well-intentioned request is hard. None of that automatically signals a broken operating model. When organizations fail to distinguish between wrong and hard, they chase new tools and vendors, hoping complexity will disappear. It rarely does; it just gets more complex the same way thinking of your teenager as a child instead of a maturing adult will rarely lead to a maturing relationship with them.

A disciplined operating model provides the clarity to see which problems require redesign and which require persistence.  Through prioritized business needs and organized IT delivery plans, what is possible becomes clearer.  What changes when priorities are shifted or capacity becomes constrained, becomes an objective conversation between equally mature sides of the organization.  Complexity becomes ordered, complicated becomes simple – your teams are enabled to understand what is difficult and seek solutions.  They are further enabled to understand conflicts that are exacerbated through poor decision-making, putting a spotlight on errors and illuminating a better way.

The Real Goal

There is no final state where an IT operating model becomes complete. Alignment must be reconstructed as the business evolves. The organizations that manage this well do not eliminate friction.  They surface it earlier and address it deliberately. They convert individual knowledge into shared capability. They prioritize with intention. They design structures that support collaboration rather than compete with it.

Just as adults sharing the same home don’t always agree but can get along productively, the key to a positive relationship between the business and IT is a growing model that represents both sides.  It allows each to respond to the other at a level that matches.

When this work is neglected, the impact shows up operationally and financially. When it is done well, the operating model becomes a strategic asset that enables growth instead of constraining it.

If these dynamics sound familiar in your environment, the right next step is not another tool. It is a conversation about structure, accountability, and alignment.

See you next time friends,

Kyler