Building an Institution for Systems That Cannot Fail

Two firms can describe themselves in the same words — engineering, security, critical systems — and be different things. One is execution capacity rented by the project: it arrives, delivers what was asked for, leaves, and whatever it learned leaves with it. The other is an institution: what it learned on one piece of work is available on the next, including to people who were not there.

The difference is not size and it is not rhetoric. It is what survives the end of the contract. The founding letter answered why we exist; this one is about what we are building and how we intend to be measured. Three claims, none of them comfortable: technical judgement either accumulates in the organisation or evaporates with the people; refusal is part of what we deliver rather than an occasional courtesy; and the right measure of a technical institution arrives far too late to be useful as a sales argument.

What an institution accumulates

What accumulates is not code, and it is not methodology. Methodology tends to be what is left over when someone tries to write judgement down and it does not fit. What accumulates is the ability to recognise a shape: to see in the first week that the migration ahead has the same structure as four others, that the likely point of rupture is the usual one, and that the argument the team is having about technology is really an argument about who answers for a piece of data. That recognition is expensive to acquire and cheap to lose.

An institution exists so that it does not stay locked inside one person, and that imposes unglamorous obligations. Writing the reason next to the decision, while the reason is still obvious to the person writing it. Keeping one vocabulary, so that engineering, security and capital describe the same system in the same words rather than three imaginary ones. And publishing positions in the open, like this one, because a published position is a position that can be held against us — including by us, against ourselves, when practice shows it was wrong.

Refusal is part of the work

There are two refusals and they do not weigh the same. The first is refusing a piece of work: it happens up front, it is visible, and it costs a proposal. The second is refusing inside the work — saying, once engaged, that the thing asked for should not be done, or not that way, or not before something else. That is the hard one, because it contradicts the person paying at a point when a schedule already exists, and because it almost never proves itself: the incident it prevented does not happen, and therefore does not appear.

The ability to say no is the only evidence that a yes means anything.

Refusal has a structural precondition: only an organisation that does not need the next contract can afford it. That makes the shape of the firm, before anything else, a decision about the quality of judgement it will be able to sustain. We would rather grow slowly, keep fixed costs low and avoid any target that can only be met by saying yes, because the alternative is well documented and requires no bad faith: an organisation that needs the work always finds a technical justification for taking it. Nobody lies in that process. Judgement simply adjusts to necessity, and whoever is adjusting is the last to notice.

How a technical institution measures itself

The usual measures measure activity: headcount, project count, mentions. All of them keep rising while quality falls, which is precisely why they are popular. The measure that interests us is different and it is uncomfortable, because it is made of questions that can only be answered later, preferably by someone who is not us:

• —Does the work still stand without us? A system that depends on the people who built it was not delivered; it was lent.
• —Could it be changed afterwards, by another team, without the change requiring nerve?
• —Are the decisions still explicable when whoever made them is not in the room?
• —Does what we wrote a year ago still hold — and where it does not, was it corrected in public, in the same place it was asserted?

None of those can be answered on the day of delivery, and that is the central discomfort of building on a long horizon: the right measure arrives late, and never in time to win a piece of work. Until it arrives, all that can be done is to apply the same criterion in advance to every small decision, including when nobody is watching. That is the operational definition of technical integrity, and it is the only part of the subject that does not depend on time.

Ten years is not a figure of speech

Ten years is roughly the interval over which nothing of the original context remains. The platform has changed, the vendor changed product or owner, the business rule became an exception and then became the rule again, the volume is not the same, and the people who knew why it was built that way are at other companies. What survives that interval is exactly what was made explicit, and nothing else. So the ten-year test is not a prediction about the future: it is a test of explicitness, and it applies today, to this decision, in this meeting, to whoever is in it.

Building for ten years is not predicting ten years. It is refusing to do, today, what only works while today's people are still here.

We have no results to display and we are not going to manufacture any. What exists today is what this site publishes: the positions we hold, the conditions under which we agree to begin, and a way of working that can be checked by anyone who works with us. An institution is not announced — it accrues — and the only honest thing to do at the start is to state the ruler we want to be measured by later, once there is something to measure. This letter is that ruler.