10.8 Maturity models¶

Overview and motivation¶

A maturity model is a structured way to assess how capable and consistent your practice is in some domain, and to describe a path for improving it. It defines a small ladder of levels. At the bottom, work is ad hoc and reactive. At the top, it is measured, managed, and continuously optimizing. Each rung has observable characteristics you can check against.

Maturity models turn a vague question ("are we good at this?") into a repeatable answer ("we are at level 2 here, level 4 there, and this is what level 3 would require"). This book uses a four-level model in every chapter and consolidates them in chapter 12.4. This chapter is about the discipline itself: how the models work, when they help, and how they mislead.

The reason they matter is simple. Large organizations cannot improve what they cannot see. Across dozens of teams, capability varies enormously and invisibly. Some teams have excellent testing and weak security; others have the reverse. A maturity model gives you a shared vocabulary and a common yardstick, so gaps become comparable, investment can be prioritized, and progress can be tracked over time rather than merely asserted. Well-known examples include CMMI (Capability Maturity Model Integration, for process), the DORA (DevOps Research and Assessment) model (software delivery performance), OWASP SAMM (Software Assurance Maturity Model) and BSIMM (Building Security In Maturity Model) for software security, TMMi (Test Maturity Model integration, for testing), the Agile Fluency model, and data-management maturity models, plus countless internal scorecards.

For enterprise and especially government, maturity models carry particular weight. Government contracting has long used CMMI appraisal levels as a supplier qualification, and frameworks like the U.S. CMMC (Cybersecurity Maturity Model Certification) tie cybersecurity maturity directly to eligibility for defense work. That gives maturity models real teeth. It also creates the central risk of this chapter: when a level becomes a gate or a target, people optimize for the appraisal rather than the underlying capability. Used well, maturity models are a mirror. Used badly, they are theater.

Key principles¶

• Maturity is a means, not an end. The goal is capability and outcomes, not a level number.
• Assess to learn, not to score. Honest self-assessment beats a flattering appraisal.
• Higher is not always better. The right target depends on risk, context, and cost.
• Measure per domain, not one global grade. Capability is uneven; a single number hides it.
• Prioritize the lowest-maturity, highest-risk gaps first.
• Beware Goodhart's Law. Once a level is a target, it stops measuring capability.
• Re-assess periodically. Maturity drifts as people, systems, and threats change.

Recommendations¶

Choose the right model for the domain¶

Match the model to the capability you want to improve, and prefer established, evidence-based models over invented ones where they exist:

• Process and delivery: CMMI (broad process maturity), the DORA capability model (delivery performance, grounded in research, chapter 11.2).
• Security: OWASP SAMM and BSIMM (software security practices), CMMC (defense cybersecurity).
• Testing and quality: TMMi.
• Agile and ways of working: the Agile Fluency model (chapter 10.7).
• Data: data-management maturity models (DMM, DCAM).

For internal use, a simple four- or five-level scale applied per capability (as this book does) is often more actionable than a heavyweight external framework. Reserve formal, appraised models for where they are contractually required.

Assess honestly and per capability¶

Run assessments that produce truth, not comfort. Involve the people doing the work. Gather evidence rather than opinions. Score each capability separately, so the picture reflects reality: strong here, weak there. A self-assessment used to guide improvement is worth more than an external appraisal used to earn a badge, because the first rewards candor and the second rewards presentation. Chapter 12.4 provides a consolidated self-assessment across every domain in this book; use it as a starting instrument.

Use maturity to prioritize, not to punish¶

The output of an assessment is a prioritized improvement backlog, not a report card for blame. Combine maturity with risk. A level-1 capability in a low-risk area may be fine. A level-2 capability in a safety- or compliance-critical area is urgent. Direct investment to the gaps where low maturity meets high risk, and connect the work to outcomes (chapter 11.1) so improvement is measured by results, not by climbing the ladder for its own sake.

Set target levels deliberately: higher is not free¶

Each level up costs effort and often adds process weight. The right target is rarely "level 5 everywhere." It is the level where the extra capability still justifies the extra cost for that domain's risk. Regulated and safety-critical capabilities may genuinely need the top rungs, and audit often requires at least a "defined" level 3. Many others are well served at level 3 and would only accumulate bureaucracy by pushing further. Decide targets per capability, and stop climbing when the risk-adjusted return does.

Guard against maturity theater¶

The one failure mode that destroys the value of maturity models is optimizing for the score. Watch for assessments that grade generously, evidence assembled only for the appraisal, or "level 5" claims that production incidents contradict. Keep the assessment tied to observable behavior and real outcomes. Rotate or externally sanity-check your assessors. Treat a suspiciously high self-score as a smell. The moment the level becomes the goal, the model stops telling you the truth.

Trade-offs: pros and cons¶

The central tension is assessment as mirror vs. assessment as target. The same model that helps a team see itself clearly turns counterproductive the instant a level is tied to reward, eligibility, or status. The more a level matters, the more energy flows into the appearance of maturity rather than the substance.

Examples¶

Startup. A ten-person SaaS startup runs a one-hour self-assessment against a simple four-level scale covering delivery, testing, security, and on-call. It finds delivery and testing at level 3 but security stuck at level 1, which matters because it is about to sign its first enterprise customer with a security questionnaire. So the founders spend the next month raising just security to a defensible level 2 and leave the rest alone, rather than chasing a uniform high score they neither need nor can afford yet.

Enterprise. A financial-services firm assesses its 40 teams with a lightweight per-capability scorecard (delivery, testing, security, observability, on-call). The heat map reveals that security maturity lags most where regulatory exposure is highest, so the platform team funds paved-road security tooling (chapter 4.2) for those teams first. Because the assessment is used to prioritize investment rather than rank teams, managers report honestly. Re-assessment a year later shows real movement, and, crucially, fewer security incidents, not just higher scores.

Government. A defense contractor must reach a required CMMC level to bid on work, and a systems integrator holds a CMMI appraisal as a contract qualification. Here the maturity level is a literal gate to revenue. The well-run version treats the required level as a floor for genuine capability and keeps a candid internal self-assessment separate from the formal appraisal. The poorly-run version assembles evidence for the appraisal and lets real practice decay the day after, passing the audit while remaining exposed.

Business case: motivations, ROI, and TCO¶

The return on maturity assessment comes from directed investment. Improvement budgets are finite. Spent blindly, they fund whatever is loudest. A maturity assessment shows you where capability is weakest against risk, so the same spend buys more risk reduction and more outcome improvement. The assessment itself is cheap, only days of structured, evidence-based review, set against the cost of misallocated improvement programs or, worse, an undetected capability gap that surfaces as a breach, outage, or failed audit.

On total cost of ownership, the discipline is low-cost when you keep it lightweight and high-cost when it hardens into appraisal bureaucracy. The dominant hidden cost is maturity theater: effort spent producing the appearance of maturity returns nothing and can mask real risk, which is negative ROI. To make the case to leadership, present maturity as a risk-and-investment lens, a heat map that turns "improve everything" into "improve these three things first," and explicitly budget against the temptation to chase levels for their own sake. Where a level is contractually required (CMMC, CMMI), the ROI is direct: it is the price of eligibility, and the goal is to meet it with real capability rather than costly pretense.

Anti-patterns and pitfalls¶

• Level as the goal: chasing a number instead of the capability it is meant to represent.
• Maturity theater: assembling evidence for an appraisal while real practice decays.
• One global grade: a single maturity score that hides dangerous unevenness.
• Higher-is-always-better: pushing every capability to level 5 regardless of risk or cost.
• Assess once, never again: a one-time appraisal treated as permanent truth.
• Ranking teams to blame: using maturity for punishment, which kills honest reporting.
• Model worship: following a heavyweight framework's ceremony past the point of usefulness.
• Ignoring outcomes: climbing the ladder while delivery, reliability, or security do not improve.

Maturity model¶

• Level 1 (Initial): No shared notion of maturity; capability is assumed, uneven, and unmeasured.
• Level 2 (Managed): Ad hoc assessments in a few areas; results used inconsistently; risk of scoring for appearance.
• Level 3 (Defined): A consistent per-capability model and cadence; assessments evidence-based and tied to a prioritized improvement backlog.
• Level 4 (Optimizing): Maturity linked to risk and outcomes; targets set deliberately per domain; re-assessed regularly; used to direct investment, with active guards against gaming.

Ideas for discussion¶

1. Which of your capabilities are you assuming are mature without evidence?
2. Where does your lowest maturity coincide with your highest risk, and is that where your improvement budget is going?
3. Is any maturity level in your organization a target or a gate? What behavior has that produced?
4. What is the right target level for each capability, and where would climbing further just add bureaucracy?
5. Would your teams report their maturity honestly, or does the way you use scores punish candor?
6. When you last "improved maturity," did outcomes actually change?

Key takeaways¶

• A maturity model assesses capability against a ladder of levels and describes a path to improve: a mirror, not a trophy.
• Pick established, evidence-based models per domain (CMMI, DORA, SAMM/BSIMM, CMMC); a lightweight per-capability scale is often most actionable.
• Assess honestly, per capability, and use results to prioritize by risk, not to rank or blame.
• Higher is not always better: set target levels deliberately against risk and cost.
• Beware maturity theater and Goodhart's Law: a level that becomes a target stops measuring capability.
• See chapter 12.4 for this book's consolidated maturity self-assessment, and every chapter's own maturity section.

References and further reading¶

• CMMI Institute / ISACA, Capability Maturity Model Integration (CMMI).
• Watts Humphrey, Managing the Software Process (origins of software process maturity).
• Nicole Forsgren, Jez Humble, Gene Kim, Accelerate (capability, not maturity-level, thinking for delivery).
• OWASP, Software Assurance Maturity Model (SAMM); BSIMM (Building Security In Maturity Model).
• U.S. Department of Defense, Cybersecurity Maturity Model Certification (CMMC).
• TMMi Foundation, Test Maturity Model integration.
• James Shore and Diana Larsen, The Agile Fluency Model.
• Martin Fowler, "Maturity Model" (bliki), on their uses and abuses.