From Engineering Precision to Institutional Patience
Engineering rewards speed and certainty; institution building rewards neither. On learning to hold both standards at once without abandoning either.
Two different clocks
Engineering runs on a fast feedback loop. You change something, you test it, and the system tells you within minutes whether you were right. Over years this builds a particular temperament: a preference for the falsifiable, impatience with claims that cannot be checked, and confidence that most disagreements can be settled by measurement.
Institutional work runs on a slower loop and sometimes on no loop at all. A governance change made this year may not reveal its consequences for five. The feedback, when it arrives, is confounded by everything else that happened in the interval. The temperament that served me well in engineering was, at first, actively unhelpful here.
What I got wrong early
My first serious mistake was assuming that a demonstrably better design would be adopted because it was better. In engineering that is broadly true. In institutions it is not, and the reason is not irrationality.
A better design imposes transition costs on specific people, often people who had no part in the decision and receive no share of the benefit. Their resistance is a rational response to a real cost. I had been treating it as a communication problem — as though sufficient explanation would produce agreement — when it was a distribution problem requiring a different kind of answer.
The second mistake followed from the first: I optimised for the elegance of the design rather than the durability of the coalition around it. Designs that are slightly worse and widely owned outperform designs that are optimal and owned by one person. That was an unwelcome lesson and it took longer than it should have.
What transferred intact
Not everything from engineering had to be unlearned, and the parts that transferred are the parts I have relied on most.
The insistence on defining success in advance, in terms specific enough to be checked. The habit of asking what would have to be true for a proposal to work, and then examining whether it is. The refusal to accept that something is finished before it has operated under real conditions with real users. And the assumption that a system will be maintained by people who did not build it and do not have access to the designer's intentions — which is as true of institutions as of software, and more consequential.
That last habit turned out to be the single most useful thing I brought across.
Holding both
The resolution, such as it is, was not to choose between the two temperaments but to learn which questions belong to which.
Technical questions are still settled by measurement, and I have not become more tolerant of hand-waving there. Adoption questions are settled by understanding incentives and building coalitions, and applying engineering standards to them produces correct answers that go nowhere.
The mistake I now watch for in myself is category confusion — reaching for the engineering answer to a political problem, which feels rigorous and is simply the wrong instrument.