Two balance sheets, one organisation
Most organisations hold two kinds of productive asset and manage them as though they were unrelated. The first is human: experience, judgement, relationships, credentials and institutional memory, held in people and documented in job descriptions refreshed once a year if at all. The second is machine: models, retrieval structures, workflow logic and evaluation sets, held in platforms, owned by engineers and reviewed continuously or not at all. Between them sits the organisation itself, where the two either reinforce one another or cancel each other out.
The failure is not usually in either asset. It is in the absence of a single operating system joining them. Human capital is planned annually against a workforce budget. Machine capital is built project by project against a technology budget. Nobody owns what the combination can produce, and nobody is accountable when it produces less than the sum of its parts.
Six elements of a single system
Treating the two balance sheets as one system means managing six elements together. Each has an owner, a review cycle and a measure, and the six are reviewed as a set.
| Element | What it covers | Who owns it |
|---|---|---|
| Human capability | Judgement, craft, relationships, credentials. | The CHRO with the line manager. |
| Machine capability | Models, context, workflow logic, evaluation. | The technology owner with the process owner. |
| Role design | Activities, decisions, accountability, allocation. | Joint, with human resources holding the record. |
| Governance | Boundaries, review, evidence, escalation. | The accountable executive, with a risk function. |
| Knowledge | What is held in people, what is held in systems, what is lost. | Joint, per domain. |
| Business results | The measures the combination is meant to move. | The executive who owns the outcome. |
Capability is measured, not asserted
The word capital is doing work in this framework, and it should be taken literally. A capability is an asset only if its value can be estimated, and its value depends on whether it is current. Human capability that has not been exercised, and machine capability that has not been re-evaluated, are both liabilities, and both decay quietly.
Both need a review cadence and an owner accountable for decay rather than deployment. For people: know which roles are exposed to redistribution, and fund the transition before the gap becomes a performance problem. For systems: re-run evaluation against a live population on a schedule, and know which rule changed since anyone last looked.
Knowledge is the element most often left unmanaged
Every organisation has knowledge that exists only in the judgement of a few people, and is introducing systems that produce decisions without it. The two facts meet in the workflow, unrehearsed. A person applies a tacit rule, the machine applies a written one, the outputs differ, and the difference is settled by whoever noticed.
Treating knowledge as an element of the system means asking, for each significant decision in the redesigned work, where the rule lives and who can change it. Where a rule is tacit, the options are to write it down, to have the person own the decision permanently, or to accept that the machine will be wrong on those cases and build the escalation accordingly. Leaving it unexamined guarantees a slow failure.
Governance is a rhythm, not a document
A framework that people can quote is a sign of a framework nobody is using. The governance element should be a recurring review with a fixed agenda, attended by the people who can change things: what the systems did last period, what the people did, where the two disagreed, and which allocation decisions should be revisited. Evidence is collected as a by-product of the work rather than assembled for an audit.
The boundary of what the systems are permitted to do should be reviewed on the same agenda, and the review should be able to tighten a boundary as readily as to widen one. The control environment that surrounds this work is described in the governance collection, and the engineering discipline that keeps the systems maintainable is covered in enterprise agent engineering.
A sequence that starts with the work
- Establish the joint baseline: the activity inventory, the current measures and the current exceptions, taken in the same period.
- Identify the two or three activities where machine capability and human capability together would change the outcome, rather than the ones where capability is most easily bought.
- Decide and record the allocation, the accountability and the escalation route for each activity.
- Fund the human transition explicitly, in the same business case, with the same scrutiny as the technology spend.
- Publish the knowledge that the redesign depends on, and the parts left tacit.
- Run the review rhythm from the first quarter, with the measures and the allocation decisions on the same agenda.
The order matters more than the speed. A programme that buys machine capability before agreeing what the work is, who owns the outcomes and what the people will do next is a technology programme that happens to employ people. The work comes first, the capability follows, and the review keeps the two honest.
What this framework is for
It is not a maturity model and it produces no score. Its purpose is narrower: to let a chief human resources officer, a chief information officer and an accountable executive describe the same organisation with the same numbers, and know what each is responsible for when one moves. The argument for redesigning the work before automating it is set out in the CHRO's new mandate.
Organisations that manage the two balance sheets separately end up with capable people pointing at capable systems and neither of them answering for the result. Managing them as one system is unglamorous, reviewable and slow, and it is the only version of this work that has survived a change of leadership so far. The operating-model design that has to sit underneath it is covered in business and organizational transformation, and the discipline of redesigning the work before automating it is argued in why better processes come before more agents.