Build Once, Run Forever: The Operating Model Behind the People Capability System

Build once, run forever is the operating model behind the People Capability System. The build is what architects the work to the strategy. The run is what keeps that line true as the work changes. Do the first and skip the second and you have a line that was correct on the day you drew it and wrong within a year.

The full working paper is at peoplecapabilitysystem.com. This article is about the operating model on its own.

What does build once, run forever mean?

Build once, run forever means a capability system is two different activities pointing in two different directions. You build it once, top down, deriving the work from the strategic bets. You run it continuously, bottom up, reading that line back from the work.

Build is design with an end date. Run is operation with no end date. Most capability work is all build and no run, and that is the whole diagnosis.

Build: intending the work to the strategy

Building runs downward from the bets.

You name the bets the business is making. You derive the human capabilities those bets require, defined across all roles rather than tied to any one of them. You define the competencies each role needs to turn those capabilities into delivered work, with proficiency levels and observable indicators. You specify the skills that sit under each competency. Then you generate the position descriptions from the competency framework and the skills taxonomy rather than writing them freehand.

Every step exists because the step above it required it. That is the difference between intending the work to the strategy and describing the work and mapping the strategy onto it afterwards, and it is the difference between a structure and an annotation.

Build is a project. It has a scope, a sequence and an end date. It produces artefacts: a capability framework, a competency framework, and a skills taxonomy. You maintain those as strategy moves, and an organisation rebuilding them every year has a governance problem rather than a design problem.

Run: reading the line back

Running goes the other way.

You check whether a person has the skill at the level the role needs. You evidence whether the competency is held rather than claimed. You read whether capability is deep enough across the workforce to actually execute. You roll that into a single question: given the people we have and the level they are at, is this strategy executable.

Run is business as usual. It has a cadence, an owner and no completion date. The state of the work becomes a live state of the strategy, which is the thing a mapped architecture can never produce, no matter how good any single one of its documents is.

Why the separation matters so much

Keeping the two directions apart is what saves the system from the usual fate.

A framework is designed, launched and admired, and then it sits on a shelf, because nobody designed the operation that was meant to keep it alive. That is not a design failure. It is a category error. The project team delivered a build and everyone treated the build as the system.

The system is only worth standing up if you intend to run it. If you are not going to run it, do not build it. I mean that literally rather than rhetorically. A capability framework that will never be operated is a cost with no return, and the organisation would be better off keeping the money.

What running it actually takes

Three things carry the run.

A named owner

A capability lead in human resources or organisation development who maintains the frameworks and calls the assessment cycle. A committee that meets and disperses is not an owner. Decide who owns the run before you start the build, because a framework with no operational owner is a shelved artefact waiting to happen.

A system of record

The artefacts have to sit somewhere that can be queried and read by the functions that consume them, rather than in documents and slide decks. That does not mean buying a platform. It means giving the frameworks and the matrix a home, in the HR system you already run or in a capability tool, that can surface a current read on demand. A competency matrix living in a spreadsheet nobody opens is not a system of record.

A cadence that rides the cycles you already run

Keep the updates light and continuous as the work changes. Review the frameworks against strategy on a set rhythm, and once a year is usually enough for that. A read produced once, in an annual event cut off from the work, is not a run. It is a build that happens to repeat.

How the run assesses each layer

The method is different at every layer, and that is not an inconsistency. It follows from what each layer is.

• Skill. A presence check at a level. Evidence is demonstrated performance or verified output, not a completion record. Reliability comes from clear level descriptors and, where the skill matters, a practical demonstration in place of a claim. The levelling logic is well established, most visibly in SFIA's levels of responsibility.
• Competency. Assessed against behavioural indicators by the person and their supervisor. The obvious risk is that two assessors read the same behaviour differently, and the system handles this the way the assessment field does, by anchoring indicators to observable behaviour, calibrating and moderating across assessors, and triangulating against real work. That bounds the problem rather than removing it.
• Capability. Not scored on demand. Capability is revealed under novelty and consequence, so it is read from accumulated evidence of performance in real work over time, weighted towards the non-standard situations where it actually shows. This is the least mature part of the system and the paper says so plainly.
• Strategy. A workforce read, rolled up. The board's call.

Development inverts as you climb

The run does not only measure. It tells you how to develop, and in what mix.

Closing a skill gap is mostly formal and social learning. A module, a job aid, a peer. Building a durable capability is mostly deep experience: stretch assignments, exposure and reflection, because capability grows under real consequence rather than in a classroom. The 70-20-10 mix inverts as you move up the layers.

This explains a common failure that has nothing to do with effort. A great deal of learning spend produces little change because the learning is decoupled from the work it was meant to serve. Tying each piece of development to the specific competency or skill it serves, and matching the method to the layer, is what lifts transfer from an accident to a design choice.

The run is where acceptance is won or lost

The build produces a line. The run is where people find out whether the line is real.

If the read is used in decisions about staffing, development spend and succession, people accept the line, because it visibly does something. If the read changes nothing, the line becomes a form, and it is filled in carelessly within a cycle. Acceptance is not a communications exercise at launch. It is a consequence of whether the run has teeth.

Sequencing advice that carries most of the risk

Start narrow and prove it. One job family, or the roles that matter most, before scaling across the organisation. A partial system that is genuinely run beats a complete system that is not.

Decide who owns the run before you start the build. I have now said this twice deliberately. It is the piece of advice most consistently ignored and most consistently fatal.

Generative tools can accelerate the build by deriving and drafting framework content at speed, and that is a real saving. Validation stays human, against the strategy and against a disciplined glossary. Speed on the build changes nothing about the run.

FAQ

What is the operating model behind the People Capability System?Build once, top down, deriving the work from the strategic bets. Run forever, bottom up, reading the line back from the work. Build has an end date. Run does not.

Why separate build from run?Because collapsing them is what produces shelved frameworks. When the build is treated as the system, nobody designs the continuous operation that keeps the line true as the work changes.

Who should own the run?A named capability lead in human resources or organisation development, who maintains the frameworks and calls the assessment cycle. Not a committee.

Do I need a platform to run it?No, but the artefacts need a home that can be queried on demand. That can be the HR system you already have. Documents and slide decks are not a system of record.

How often should the frameworks be reviewed?Light and continuous updates as the work changes, with a review against strategy on a set rhythm. Annually is usually enough for the framework review.

Can generative AI do the build?It can accelerate it substantially by drafting and deriving framework content. Validation stays human, against the strategy and against a disciplined glossary. It does not touch the run.

‍