Before You Add AI: Assess Your IT Department’s Maturity — Culture and Processes

Everyone wants to “add AI” to their IT department right now. Most of these projects will fail — and almost never because of the model. They fail because the company never assessed the ground it is building on. AI, automation, any new management tool lands not in a vacuum but in a specific department with a specific level of maturity. Point a large language model at a chaotic process inside a culture that rejects it, and you get beautifully formatted chaos.

My core argument is simple: before you deploy anything, assess your IT department’s maturity along two key factors — its corporate culture and its business processes. Everything else is downstream. Below I unpack both factors with working methods and concrete rules, and at the end I show why exactly this assessment is what makes a later AI rollout sensible rather than dangerous — and which cognitive biases can quietly corrupt the self-assessment itself.

IT Department Maturity: The Two Factors That Decide Everything

Whether an IT department works — and whether a new tool takes root in it — comes down to two things. The first is culture: how decisions are actually made, who answers to whom and why, what counts as normal. The second is processes: how well the work is described, repeatable, and managed. Culture is the one that gets underestimated: it is invisible, you cannot buy it with a licence, and it silently “eats” any strategy and any KPI system you drop into it. So I will start there.

Factor 1. Corporate Culture: Spiral Dynamics

To assess culture I use the Spiral Dynamics model in Mark Rozin’s business adaptation (ECOPSY, “Journey Along the Spiral 2.0”). The reason is practical: it shows the difference between levels most clearly through two key requirements — centralisation and management — and those are exactly the two axes that determine how an IT department is actually run. The model sorts culture into six levels, each with a defining phrase:

• Level 1 — Belonging: “because that’s how it’s done here.” Family, tradition, loyalty; work is inseparable from relationships.
• Level 2 — Power: “because I said so.” Authority and personal leadership; order rests on the leader’s will.
• Level 3 — Rules: “because those are the rules.” System, regulations, discipline, reliability, stability.
• Level 4 — Success: “because it produces a result.” Achievement, effectiveness, speed; rules yield to results.
• Level 5 — Consent: “because we agreed on it.” Dialogue, consensus, difference treated as a resource.
• Level 6 — Synthesis (teal): “because the future belongs to it.” An integration of all the earlier states.

An audit establishes the current level — separately for the department and for the company. A typical and very telling picture: the IT department sits at level 1 of 6 (minimal), while the company around it is at level 2. And that raises the real question: what level does an IT department actually need, and why can it not be lifted in isolation from the company?

What Level an IT Department Needs — and the ±1 Rule

For an IT department to function properly, its internal culture must, in my experience, sit at level 3 of 6 at minimum, ideally level 4. Below level 3 you never get the things IT cannot run without over time: regular management, repeatable processes, predictability. A culture of power (2) rests on a hero-manager and collapses the moment he is on holiday; a culture of belonging (1) is not about manageability at all.

But you cannot lift one department in isolation from the company, and here a hard rule applies: if a department is more than one level away from the whole company, or from another department, you get conflict. A level-4 department inside a level-2 company will not “pull it up” by example — it will be seen as alien and bog down in friction. So the goal is set realistically: a considered strategy can, in my experience, take an IT department’s culture to level 3 in about six months — one level above a level-2 company, which the ±1 rule allows; reaching level 4 is possible only if the whole company itself moves to level 3–4. Cultural maturity is a team sport, not a heroic sprint by one department.

And the rule is more general than culture — it governs the relationship between the maturity dimensions themselves. Process maturity and, above all, the level of automation obey the same ±1 discipline: they cannot sit more than one level away from the culture, or from each other. An automation level two steps above the culture that has to run it is doomed the same way — a self-service AI layer bolted onto a team still run by hand gets bypassed, resented, and quietly rejected. This is the mechanical reason “just add AI” fails: bolting a high level of automation onto a low-maturity culture and chaotic processes breaks the ±1 rule by design. You do not raise one dimension — you raise culture, process, and automation together, one level at a time.

To be clear about where this ±1 rule comes from: it is my own field heuristic, but not an arbitrary one — it is the operating form of a principle that several well-established models converge on. Maturity models are explicit that you climb one step at a time: the SEI’s Capability Maturity Model states that each maturity level is a necessary foundation for the next, and that trying to skip levels is usually counterproductive — the same “no leapfrog” logic, applied here to automation as much as to process. Socio-technical systems theory adds the sideways constraint: its principle of joint optimisation holds that a technical layer driven far ahead of the social one does not lift the whole — it degrades it. And the economics bear it out: Erik Brynjolfsson (MIT) showed that IT and automation pay off only alongside complementary organisational change — deployed ahead of it, the return is not merely zero but negative. The theories give the direction — don’t skip levels, keep the subsystems balanced; the specific “no more than one level apart” is the working tolerance I apply in practice.

What Changes at Each Transition: Centralisation and Management

The value of this method is that every transition between levels is a concrete shift along two axes, not a vague “it got better.”

On the centralisation axis. Level 1 is loosely held together by tradition as a single centre; the move to level 2 fragments that centre into competing personal power-holders — decentralisation, in effect — yet it imposes real order for the first time. From 2 to 3, authority re-centralises around rules and system while that order is kept, but flexibility is lost: everything now goes by the book. From 3 to 4, creativity and new development become possible again — that rigid centralisation partly gives way and flexibility returns. The path is not linear: you tighten control, then loosen it, and it matters to know where you are on that curve.

On the management axis. The move from 1 to 2 does not change the management system itself — only the format changes, and all the limits of personal management remain: everything is still tied to a specific individual. The key leap happens from 2 to 3 — that is when regular management appears: managing processes instead of running people by hand. This is why the “minimum 3” bar for IT is not arbitrary: regular management is the threshold past which a department can be measured and automated systematically at all.

Factor 2. Business Processes and Their Maturity

The second factor is process. Here there is an established toolset, each with its role:

• BPMN (OMG notation) — the common language to describe a process unambiguously, so people, AI, and a BPM engine all mean the same thing by “the approval step.”
• ITIL (Service Support) — the set of standard processes you actually observe: incident, problem, change, release, and configuration management (with the CMDB as the single source of truth).
• COBIT and Risk IT (ISACA) — the governance layer: the split between governance and management, control objectives, and IT-risk evaluation and response.

The process you have described in BPMN and checked against ITIL and COBIT is then scored on a 0–5 maturity scale (a survey of the methods by BPM analyst A. Koptelov brings together CMMI, ISO/IEC 15504, Hammer’s PEMM, the ABPMP model). The ladder is consistent: 0 — incomplete / chaotic, 1 — performed (it happens, but with no guarantees), 2 — managed, 3 — established (documented and repeatable), 4 — predictable (measured and run on metrics), 5 — optimising. The question is not “is the process good” but “which level is it at, and which attribute is missing to reach the next one.”

And here is a nuance people often miss. Maturity is not the same as “the maximum.” The IoT Security Maturity Model (Kaspersky / IIC) states it plainly: comprehensiveness of implementation is not yet maturity; maturity is relative to a target. A calculator’s process does not need level 5; critical billing does. Driving every process to the top of the ladder is not maturity, it is overspend. The right maturity is the one that is sufficient for the task.

Why This Comes Before AI, Not After

Now the link. Once you know your culture level (and that you must grow up to “regular management”) and your process maturity (and where it is genuinely chaotic versus already on metrics), adding AI becomes meaningful for the first time. More than that — these same frameworks become the grounding for the model. Ask an LLM to “judge who is doing well” with no frame of reference, and it will invent criteria and hand out confident but baseless labels. Give it COBIT, the ITIL processes, a 0–5 maturity scale, and the culture level — and it starts comparing reality to recognised standards instead of making them up. Grounding turns “the model’s opinion” into a checkable claim: “Incident Management is at 2 of 5, because it has an owner but no measured KPIs.”

The same grounding sets the boundaries. An AI observation loop over IT is about measuring the work, not watching the people: metadata and timings, not content; git signals, not the diff; aggregates, not correspondence. Deterministic metrics (SLA, throughput, review latency, load) are computed by arithmetic; the AI sits at the edges — triage, draft summaries, anomaly analysis, plain-language explanations — always as input to a human decision. And the red line: no keylogging, screenshots, or reading of messages; no automated personnel decisions — the line GDPR Art. 22 and LGPD Art. 20 draw around fully automated calls — and no “employee score.” None of this is bolted on later — it is part of the design. Tellingly, a level 3–4 culture welcomes this kind of transparent, rules-based control; a culture of power (2) does not. One more reason to assess the culture first.

The Human Filter: Cognitive Biases

There is one more source of error, and it sits inside you. A maturity assessment is a judgement, and judgements are biased — and the biases line up almost too neatly with the three decisions this method asks of you: assessing honestly, scoring a level, and deciding to automate. When you assess, the trap is the Dunning–Kruger effect: the less mature a department actually is, the less equipped it is to see its own gap, so a manager almost always overrates their own team — and confirmation bias helpfully serves up the cases where “it all works” while hiding the ones held together by goodwill.

When you score a specific process on the 0–5 ladder, anchoring ties the whole rating to the first number named — or to a slick vendor demo — instead of to the evidence. And the fundamental attribution error is the classic trap of control: we blame the person (“he’s careless”) when the real culprit is an immature process with no owner and no rules. Confusing “a bad employee” with “a broken process” means scoring the wrong thing — and then treating the wrong disease.

And when you decide to automate, three biases push you to jump a level too early. The planning fallacy compresses the months of culture and process work into weeks, so a premature rollout looks reasonable. The bandwagon and authority effects whisper that “everyone already has AI” and “the analysts recommend it” — the exact hype this whole article argues against — while survivorship bias hides the quiet failures behind the success stories. And once AI is in, automation bias is the sharpest edge of all: people favour the machine’s suggestion and stop checking it, so the low-maturity team least able to catch the model’s mistakes is precisely the one that will trust them. Each bias attacks one of the three gates that keep culture, process, and automation within a level of each other — which is why the human filter is not a footnote here.

The defence is the same in every case: ground the judgement on an external model — the maturity ladder, the culture scale — rather than on your own gut, and keep a short checklist of these biases beside any conclusion the AI itself reaches about people or processes, forcing it to flag where it might be biased. Maturity, in the end, includes being honest about your own distortions.

The Order of Operations

Put it all together and a clear sequence emerges. First assess: the culture level (on the spiral, department and company separately) and the maturity of your key processes (on the 0–5 scale, described in BPMN and checked against ITIL/COBIT). Then align: bring the IT culture up to at least level 3 (regular management), mindful of the ±1 rule, and raise your critical processes to sufficient maturity. Only then automate — grounding the AI on those same frameworks and keeping it inside “measure the work, not the people.” The order is the methodology: whoever starts with AI and skips the assessment automates their chaos; whoever starts with maturity gets a department the AI will actually strengthen.

I run these audits and build up the maturity of IT departments as a fractional CTO. If you would like to work through your own case, get in touch here.

Frequently Asked Questions

Why not just deploy AI and use it to create order?

Because AI lands inside your existing culture and processes rather than replacing them. In a chaotic process it automates the chaos, and in a culture of power (2 of 6) transparent control is rejected. Assess and align maturity first, automate second.

What culture level does an IT department need?

At least level 3 of 6 (rules and regular management), ideally level 4 (success/results). Below 3 there is no repeatability or predictability. And a rule applies: a gap of more than one level from the company or a neighbouring department produces conflict.

Why Rozin’s Spiral Dynamics and not another model?

Because it shows the difference between levels most clearly along the two axes that matter for management — centralisation and management — and answers directly whether regular management has appeared (the 2-to-3 transition).

What is “sufficient” process maturity?

Maturity matched to how critical the process is, not the maximum on the scale. Comprehensiveness is not yet maturity (the IoT SMM point). Take critical billing to level 4–5; leave routine trivia lower — otherwise it is overspend, not order.

Sources & Frameworks

• Mark Rozin, “Journey Along the Spiral 2.0” (ECOPSY) — Spiral Dynamics of corporate culture.
• Process-maturity methods surveyed by A. Koptelov — CMMI, ISO/IEC 15504, Hammer’s PEMM, ABPMP.
• COBIT and the Risk IT Framework (ISACA) — governance and IT-risk management.
• ITIL (Service Support) — IT service-management processes.
• BPMN 2.0 (OMG) — process-modelling notation.
• IoT Security Maturity Model (IIC / Kaspersky) — maturity as fitness-for-purpose (“comprehensiveness is not maturity”).
• GDPR Art. 22 (and LGPD Art. 20) — limits on fully automated decisions about people.
• Capability Maturity Model (SEI / Carnegie Mellon, after Watts Humphrey) — maturity as a staged foundation: each level supports the next, and skipping levels is counterproductive.
• Socio-technical systems theory (Trist & Bamforth, Tavistock) — “joint optimisation”: the social and technical subsystems must advance together.
• Erik Brynjolfsson & Lorin Hitt, “Beyond Computation” (Journal of Economic Perspectives, 2000) — IT and automation pay off only with complementary organisational change.
• Cognitive-bias research — Dunning–Kruger (self-assessment), Tversky & Kahneman (anchoring, planning fallacy), and automation bias (Parasuraman & Riley).

---

Need a Consultation?

If you want to assess your IT department’s maturity — culture and processes — before you invest in automation and AI, book a free 15-minute call.