Borrowing technology readiness levels for teams that do not build spacecraft

The central idea

A readiness scale is useful not because it measures maturity accurately but because it forces two people who disagree to point at the same rung and say which evidence is missing.

Technology readiness levels were built for hardware procurement, where the difference between a component tested in a laboratory and one flown in a mission is a matter of physics and cost. Software teams generally dismiss the scale as bureaucratic, and for its original nine-level form applied literally, that dismissal is fair. What survives translation is the underlying move: define maturity by the environment in which something has been demonstrated, not by how finished it feels.

What changed, and why it matters now

The recurring argument in most product organisations is some version of is this ready. It is unresolvable as posed, because the participants are each using a private definition — the engineer means the code works, the operations lead means it can be supported at three in the morning, the commercial lead means it can be sold without caveats. All three are correct and they are not discussing the same property. Teams that adopt an explicit scale do not stop disagreeing; they start disagreeing about which rung has been demonstrated, which is a question that evidence can settle. The shift is visible in how estimates change. Before a scale, a team asked when something will be ready produces a date; after one, the same team produces a rung and a list of what is missing to reach the next. The date is usually less optimistic and considerably more accurate, because it is assembled from named gaps rather than from a general sense of progress, and it can be challenged on specifics by someone who was not in the room when it was made. The scale is also useful in the other direction, as a way of declining work honestly. A request to ship something next month can be answered with the rung it currently occupies and the evidence still outstanding, which is a more productive answer than no and a more defensible one than yes.

Build the operating model

Collapse the nine levels to five, define each by the environment the thing has run in and the evidence that proves it, and require the evidence to be named before the level is claimed.

A workable five-rung version: one, it works on a developer machine with chosen inputs; two, it works on shared infrastructure with real historical data; three, it has served real users in a limited slice with a rollback path; four, it has carried representative production load including a peak, with alerting and an owner; five, it has run a full business cycle including the seasonal edge cases and a personnel handover. The last rung is the one teams skip and the one that separates a system that works from one the organisation can operate.

Measure what the decision produced

Track the level claimed against the evidence recorded, the time spent at each rung, and how often something is promoted without the evidence that rung requires.

Time-at-rung is the informative measure. A component that sits at rung two for eight months is not being matured; it is parked, and the scale makes that visible in a way a status column does not. Promotions without evidence are the number to watch most closely, because they are how a scale decays into vocabulary: once two or three things have been declared rung four on assertion, the scale has stopped being a control and become a label.

Where execution breaks

The main risk is that the scale becomes a reporting layer — every project self-reports a level, nobody records the evidence, and the numbers drift upward toward whatever the roadmap needs.

The second risk is applying it to work where it does not fit. A scale of this kind assumes a thing that can be demonstrated in progressively harsher environments. It works for a model, a service, an integration. It works poorly for design direction, organisational change, or anything whose success is a matter of adoption rather than function, and forcing those into it produces false precision that is worse than the ambiguity it replaced.

What this looks like in practice

In use it is a single column on an existing board and one sentence per item naming the evidence. The conversation it changes is the planning one: a request to ship something at rung two becomes a specific negotiation about what would be needed to reach rung four and how long that takes, rather than a general exchange about confidence. Teams report that the main effect is not better decisions but shorter meetings, because the ambiguity that used to consume half of them has been removed.

The strongest argument against this

The objection worth taking seriously is that readiness scales encode a linear, hardware-shaped view of maturity that modern delivery abandoned deliberately. Software is meant to reach real users early and mature in production, and a framework that treats production exposure as a late rung can be used to justify exactly the long pre-release phases that continuous delivery exists to prevent.

The resolution is that the rungs describe scope of exposure, not calendar sequence. Reaching rung three in the first fortnight with a one-per-cent slice is the intended use, not a violation of it. The framework becomes harmful when the rungs are read as project phases with gates and sign-offs attached, which is precisely how it will be read if it is introduced by a governance function rather than by the team that has to use it.

A 30-day implementation sequence

Add a readiness column to the board this week, populate it for everything in flight, and require one sentence of evidence beside each number.

Day one, write the five rung definitions in your own words and circulate them — borrowed definitions do not survive contact with a specific team. Day two, have each owner assign a rung to their work and name the evidence. Day three, review the assignments together and expect a third to move down once the evidence is stated aloud. Week two, use the rungs in one planning session and see whether the discussion changes. Week four, keep them only if that discussion stayed shorter.

Audit the evidence, not the numbers

Every quarter, take five items and check the recorded evidence against reality: did that load test happen, is that alert configured, did the seasonal cycle actually complete. Five is enough. The purpose is not comprehensive verification but establishing that claims are occasionally checked, which is what keeps a self-reported scale honest. Record the audit result next to the claim so the history is visible when the item is discussed again.

Re-assess levels when the environment changes rather than on a fixed schedule. A dependency upgrade, a traffic pattern shift, or the departure of the only person who understood the system are all events that can move something down a rung, and the last of those is the one no framework catches automatically. Make handover an explicit demotion trigger, and the scale starts describing operational reality rather than technical history.

Editorial conclusion

Frameworks borrowed from other industries usually fail because they are adopted whole. This one survives translation if it is cut to five rungs, defined locally, and used by the people doing the work rather than reported upward. What it buys is modest and real: an end to the argument about whether something is ready, replaced by a shorter argument about what is missing.