If You Want to Become an IT Company, You Need to Behave Like One
Some colleagues tease me about it. “You probably have a model for that,” they say and honestly, they are not wrong.
Over the years I have developed what you might call a fondness for models and frameworks. Not because I think reality fits neatly into boxes, but because a good model gives me an umbrella. A place to start reasoning, a shared language to explain what I am seeing. Handlebars for situations that would otherwise feel slippery and hard to grip.
And sometimes a model does something even more useful: it gives words to something I already sensed but could not articulate. That moment of recognition. That YES!, that is exactly what is happening here, is worth a lot when you are trying to get a team or a leadership table aligned.
This is one of those models. I use it regularly, share it often, and it has served me well. I hope it does the same for you. If you want to learn about more models, visit the Models section of this site.
A few years ago, a good friend of mine and I took a day to walk through a city. We do that sometimes: no agenda, no client to prep for, just walking and talking. The kind of conversation where you end up somewhere completely different from where you started.
At some point we asked ourselves: what do we actually do? What is the thing that connects all the work?
Our first answers were all technology. Cloud migrations, DevOps, platform engineering, software quality. Which is true. But it felt like the list of things we carry, not the reason we carry them.
After a few hours of walking and pushing back on each other, we arrived somewhere different. Every person on our team, whether a developer, an architect, an agile coach, or a transformation consultant, is working toward the same thing. We help organisations become IT companies. And if you want to be an IT company, you need to behave like one.
That conversation was the seed of the Engineering Culture Model.
What the model actually is
The Engineering Culture Model maps eight dimensions that separate an engineering organisation that merely functions from one that consistently excels. Not as a checklist, not as a maturity ladder, but as a diagnostic.
The eight dimensions are: Clear Digital Vision, Empowering Operating Model, State of the Art Software, Smooth Delivery, Appropriate Continuity, Power Through Platforms, Knowledge Driven, and Epic Workplace.
What makes the model useful is not the list itself. Most CIOs would nod at every item. What makes it useful is the pattern it reveals when you plot an honest assessment across all eight. In almost every organisation I work with, two or three dimensions absorb all the attention, usually Smooth Delivery and State of the Art Software, while the rest drift quietly sideways.
That drift is almost always behind the stalling, the attrition, and the missed delivery promises. The visible problem is rarely the real problem. The real problem is in the adjacent dimensions nobody is watching.
Why this matters even more now
With the rise of AI, organisations are moving fast. AI is being injected into products, processes, and pipelines at a rate that would have seemed implausible five years ago. And I understand the urgency. The opportunity is real.
But here is what I keep seeing: organisations trying to embed AI into a foundation that was already cracked.
If your digital vision is unclear, your teams cannot decide what to use AI for, or where to draw the line. If your operating model is structured around approval chains and handover rituals, AI-generated code still gets stuck in the same queues. If knowledge is hoarded rather than shared, the people who understand the AI tools and the people who understand the business domain rarely talk.
Injecting AI into that environment does not fix it. It amplifies it. The speed goes up, and so does the rate at which the existing problems compound.
Clear Digital Vision and Empowering Operating Model need to come first. Investing in AI capabilities before those two dimensions are sound is building fast on a foundation that was never stable.
How to use it
The model works as a starting point for a conversation, not as a conclusion. I use it before any transformation engagement to plot where an organisation is strong and where it is quietly breaking down.
Walk through all eight dimensions with the leadership team. Not to score them, but to surface the gaps that do not show up on project dashboards. The dimension that gets no attention is usually the one generating the most drag.
Then ask: what sequence makes sense? Not all eight at once, not in a rigid order, but with awareness of which dimension creates the conditions for the next one to succeed.
That is the move. Not more technology. Not a faster sprint cadence. A clear picture of all eight dimensions, an honest read on where you are, and a deliberate choice about where to start.
You probably have a model for that, they say. And in this case, I do. I hope it is useful.
Extra links
I wrote quite a lot about this for my company Xebia. You can find more about the Engineering Culture Model in these posts: