Every DevOps maturity model we have read assumes the reader is somewhere on the curve between weekly deploys and trunk-based development. The mid-market clients we work with across the continent are often somewhere else entirely. Quarterly releases through a shared file server, change advisory boards that meet on Wednesdays, environments hand-configured by the senior systems engineer who has been at the company for fifteen years. The conventional maturity models do not meet these teams where they are, and that is why we built our own.
Five levels, honestly named
Our model has five levels, and we picked the names to be candid rather than aspirational. Level one is heroic. Releases work because a specific person makes them work, and the company has no plan for that person's vacation. Level two is documented. The hero has written the steps down, but the steps still require the hero to execute them. Level three is scripted. The steps are automated, but the automation is fragile and runs only on the hero's laptop. Level four is pipelined. The automation runs in a CI system and any qualified engineer can trigger it. Level five is invisible. Releases are a routine event nobody notices because the system was designed for them.
Most mid-market clients we engage with land at level two. The interesting jump is from level three to level four, because that is where the work stops being about tooling and starts being about how the team works. Tooling is the easy half of DevOps. The cultural half is harder and takes longer.
// Our maturity self-assessment, condensed.
const signals = {
level1: deployRequiresSpecificPerson(),
level2: deployRequiresWrittenRunbook(),
level3: deployScriptedButFragile(),
level4: deployRunsInSharedCI(),
level5: deployIsRoutine(),
};
function maturity(team: Team): number {
return Object.values(signals).filter(Boolean).length;
}The level four ceiling
Many teams plateau at level four for years, and the reason is almost always organizational rather than technical. The pipeline exists, but releases still require sign-off from three departments, and at least one of those departments treats every release as a risk to be minimized rather than a normal business activity. Breaking through this ceiling requires executive sponsorship, because it requires renegotiating the change management process with departments that have built their identity around being gatekeepers.
“We did not unlock continuous deployment by buying a tool. We unlocked it by convincing the head of compliance that smaller, more frequent changes were safer than fewer, larger ones.”
Where we usually start
- Map the deployment process honestly. Include the manual steps people stopped writing down because everybody knows them.
- Identify the single biggest source of release-day failures. Fix that one thing before you touch anything else.
- Move the deployment script off the hero's laptop and into a shared CI runner. Do not pretty it up. Just move it.
- Add observability before you accelerate. Faster deploys without visibility are faster ways to break production.
- Negotiate the cultural pieces in parallel with the technical work. Both have to move or neither will.
The mid-market clients that have made the journey with us tell the same story afterwards. They wish they had started earlier. They wish they had picked smaller initial scope. They wish they had not let a vendor sell them a platform before they had agreed on what they wanted the platform to do. The maturity model is not a target to chase. It is a mirror to hold up so you can see where you actually are. The honesty is the point.