> ## Content Index
> Fetch the complete content index at: https://www.ariet.net/llms.txt
> Use this file to discover other available public pages before exploring further.

# Who maintains the machines
- URL: https://www.ariet.net/who-maintains-the-machines/
- Published: 2026-10-10T13:02:50.000Z
- Updated: 2026-10-10T13:02:50.000Z
- Author: Richard Thackeray

## The gauges, not the gun

I took my eldest climbing this morning and sat down with a book. I didn’t read much. I returned to the Stuart Brands Maintenance book and stopped about five lines in, and it triggered this piece. It’s how they happen, and it is a creative process I like.

At the Harpers Ferry armoury in the 1820s, John Hall made a breech-loading rifle that was, by most accounts, an ordinary weapon, but what he built around it was not ordinary, and that’s what triggered this piece, and what it's about.

He developed machines, jigs, and fixtures that let workers without gunsmithing training produce parts to standard, along with a set of gauges to check each part against it. Government inspectors found that parts from rifles made in different years would fit one another.

Stewart Brand makes the point that the achievement lay in the system that made the product. The gauges mattered most in that they let the armoury see drift in its own work before it showed up as a rifle that would not assemble.

Brand also notes that Hall employed as many mechanics to keep the machines in order as there were operators to run them. That statement triggered me when I thought about my own role and contribution. The armoury spent as much labour on the system as on the product.

Hall had an output goal, rifles for the army, but he gave equal weight to a capability goal: parts made to standard, machines kept in order, and gauges to check both. The second goal had its own people and its own measures, and it was what made the first one reliable.

Most organisations I have worked in hold only the first kind of goal. They measure the rifle closely and have nothing like Hall's gauges for the system that makes it.

For all the billions spent on leadership training, we have lost the lessons of 200 years ago.

## Why output goals win by default

Output goals have obvious advantages: you can count them within a budget year, assign them to a person or team, and reward them. Capability goals are harder to state and take longer to show results because they look like a cost in the year they are funded, and the benefit often lands after the people who paid for it have moved on. How do you reward bold investment in the system if it doesn’t land this year, and how do you show the benefit is directly related? It’s all too difficult.

The difficulty is that output goals draw on capability without recording it. A target met by stretching a team, deferring a platform upgrade or leaning on the two people who know how things really work looks like success. The target was met by drawing down the team, the platform and a few key people, and the scorecard records the target but not the cost.

The same logic decides who goes when costs are cut. On an output scorecard, Hall's mechanics would look like overhead; they made nothing that shipped. Their equivalents today are the people who look after the platforms and the data, and the long-serving staff who know how the parts fit together. These are usually the first roles to go, and the effect shows up later as a slower, more fragile operation that cannot be connected back to the decision.

At a large bank, I was told to focus on output goals rather than capability goals. When I asked how we might build a view of the capability those goals depended on, I was told to stop challenging. I have written about that conversation elsewhere; here, it is enough to say the question was reasonable, and most organisations still have no answer.

## Who tended the system, and who let it go

**Toyota and General Motors.** In the 1980s, the two companies ran a joint plant in California, NUMMI, where Toyota taught GM its production system. Quality at the plant improved with much the same workforce. GM found it hard to carry the practice back to its own plants. It could copy the visible parts, such as the cords that stop the line, but Toyota's real asset was a habit of improving the line every day, held in its supervisors and their routines, and that is much harder to copy than a tool. They built a capability for continuous improvement.

**Enfield.** In the 1850s, a British parliamentary committee visited American armouries and came back impressed by what it called the American system of manufactures. The government then bought American machinery for the Royal Small Arms Factory at Enfield. It deliberately sought the capability to make rifles, rather than to buy more of them. That’s a capability strategy too.

**Boeing.** A common reading of Boeing after its 1997 merger with McDonnell Douglas is a shift of attention towards financial results, with engineering treated as a cost and more of the design and build passed to suppliers. The quality problems of recent years are often traced to that shift. Aircraft kept coming off the line for a long time before the system's condition became visible.

**Intel and TSMC.** Intel led chip manufacturing for decades, then lost years to delays in moving to new manufacturing processes. TSMC built its business on process capability; it makes chips for others, and what it sells is the ability to make them well. Much of the industry's most advanced work now runs through its plants.

## When capability hardens around one product

Ford's moving assembly line at Highland Park, from 1913, is the standard example of a system built to make a product. It was also built around a single product. Through the 1920s, while Ford refined the Model T, General Motors under Alfred Sloan offered a range of cars and changed its models every year. When Ford finally replaced the Model T in 1927, it had to stop production for months to retool. David Hounshell's history of the period describes GM's approach as flexible mass production.

Hall's own system shows another path. His gauges and jigs were made for one rifle, but the methods behind them spread through the machine-tool makers into sewing machines, typewriters and bicycles. This is called technological convergence: different products turned out to need the same underlying abilities, and the firms that held those abilities could serve them all. The capability that travelled sat a layer below any single product; where are these in your operation?

Toyota is the third case. Its production system is a routine for improving whatever line it is applied to. David Teece's work on dynamic capabilities gives the language for this; the ability to sense change, seize an opportunity and reconfigure is distinct from the ability to run today's operation well.

From these cases come some tests for whether a capability will outlast its first product:

- Is it named as an ability or as a product? An insurer that builds a capability to “price home policies” ends up good at one product. One that builds a capability to “turn data into a price for any risk” can use it for motor, commercial or farm insurance too.
- Could a second product use this investment, and has anyone checked?
- Are platforms funded separately from the product lines that use them?
- Do we know how long it would take to reconfigure, and how well the current line runs?

## Holding both goals

Hall's armoury makes capability look like machinery, and it would be easy to read this as an argument about production lines and not the organisations of 2026.

Most of an organisation’s capability is less visible: the knowledge held by experienced people, the trust between teams, the informal routes by which problems reach someone who can solve them, and the communities where practice is shared and improved. A good community is capability. It ships nothing itself, but much of the work that does ship depends on it, and it is also easy to cut.

The answer is not to drop output goals; it is to stop letting them stand alone. The balanced scorecard tried to address this in the 1990s with its learning and growth perspective. In many organisations, that was the first part to thin out because it was the least connected to revenue-earning capabilities.

A more practical approach is to pair each output goal with the capability it draws on, and to ask three questions of every target:

- Which capabilities does this goal depend on?
- What condition are those capabilities in, and who is measuring them?
- Will meeting the goal build them up or wear them down?

The second question is Hall's gauge applied to the organisation. A capability model can make it answerable; without one, few can answer it with any confidence.

Capability also needs its own funding line, treated as an asset that wears out if it is not maintained. If it sits inside product budgets, it will be spent to meet output targets.

## Defending the capability line

Funding capability separately makes it visible, and visible spend attracts the question "how much do we spend on that?" Trying to show a return on capability by itself is usually a losing argument; the benefit is spread across many outputs and arrives later.

A better response is to turn the question round. If each output goal names the capabilities it draws on, the capability line becomes part of the cost of those outputs. A proposed cut then becomes a question of which outputs the organisation is willing to give up, and that is a harder conversation to have casually.

Physical asset management offers a second argument. Nobody asks for the return on maintaining a bridge; they ask about its condition, the risk of failure, and the total cost over its life. Standards such as ISO 55000 treat assets this way, and finance teams already accept the language.

The evidence then comes from Hall's gauges rather than from forecasts:

- Condition measures, such as the time to deliver a change, failure and rework rates, and dependence on a few key people
- Reuse, recorded each time a second product draws on an existing capability instead of building its own
- For less tangible capability such as a community, how quickly problems reached someone who could solve them, and how quickly new people became useful

It also helps to let the users defend it. When product owners draw on a capability and feel its condition, a proposal to cut it meets resistance from them, not only from the people who run it.

## Strategy as a choice of capability

An insurer I worked with had a goal to grow. Two parts of the business could deliver it. One was agribusiness, where growth meant building data-rich relationships that help farming clients perform better; that needs advisory depth, data about farms and their risks, and long relationships with clients. The other was home insurance bought in three clicks, where growth meant pricing models, low cost and distribution through comparison sites.

Either would meet the goal. They call for very different investments, and over five years they would build very different organisations. Agribusiness growth is slow and hard for a competitor to copy, and the capability it builds could serve other commercial lines. Three-click growth is quicker and contested mostly on price, and its capability is tied closely to one product and one channel.

Left to the incentives, the business would drift towards whichever showed volume first. "Grow" becomes a strategy only when it names the capability to be built, and that choice should be made openly rather than by the sales targets.

## A question for any target

Hall is remembered for the system he built around an ordinary rifle. For any target set this year, I would ask what meeting it depends on, and whether anyone is maintaining that. If nobody can say, the organisation is measuring its rifles closely and will learn about the state of its armoury late.

---

*A note on how I write. The observations, questions, message and arguments are mine; so is the experience behind them. I work with Claude, Google, and Grammarly on research and drafting, and I edit and check until I can stand behind each statement. Any errors are mine too.*