Staffing for year three from the first week

A programme director asked us, in the second week of a build, which of the four engineers in the room would still be on the account in three years. It is a fair question and most suppliers cannot answer it. We could name two. We said so, and then explained what we intended to do about the other two.

Everyone in this industry says they staff for the long term. The claim is worth nothing without the mechanics behind it, so here are ours.

Two names on every component

No meaningful part of a system is allowed to have exactly one person who understands it. The second person has to be an engineer who has changed that code, carried the pager for it, and broken it once under supervision in an environment where breaking it was safe. A documented handover is a different and much weaker thing, and we have watched enough of those fail to stop counting them.

For the first six months or so this is more expensive than it needs to be, and on a burn-down chart it looks like waste. It stops looking like waste the first time somebody resigns, which on a five-year programme is a certainty rather than a risk.

The pairing is not symmetrical. One person owns the component and the second is deliberately kept at working familiarity: enough to take a production incident and make a considered change, not enough to be a redundant salary. Reviewing every commit is not the same as being able to operate something at three in the morning.

Rotation without a reset

People move, and they should. An engineer who spends a decade on one account is usually a retention problem forming quietly. What can be controlled is the shape of the move.

• One person at a time, never a squad.
• Overlap measured in months rather than weeks.
• Not during a release freeze, a peak trading period or an audit window.
• The incoming engineer sits through at least one full incident and one full release before the outgoing one leaves.

We have done the other version. Early on, a larger bid needed people quickly and we moved most of a team off an account inside a quarter. The client met four new faces at once. Nothing dramatic broke, and everything simply took longer for about eight months while the new team rebuilt an understanding that had walked out of the building. The recovery cost more than the rotation saved.

Saying no at the proposal stage

Sometimes the honest answer is that we cannot staff a piece of work for the length of time it will actually need. A twelve-month build with a decade of operation behind it, priced so that the operation is an afterthought, is a programme better declined than started. Those conversations are uncomfortable and they occasionally lose the deal.

They cost less than being the supplier who delivered a system nobody can maintain. That reputation takes a long time to shed, and the people who remember it move between organisations.

What a client can ask for

Any buyer can ask a supplier for the named individuals on the account, their expected tenure, and who the second person on each subsystem will be. If the response is a set of role titles and a resourcing model, the fair reading is that staffing will be worked out later, which in practice means whoever is free in the month the work starts.

We put the names in the proposal. It constrains us, and that is the intent. It also means that when we do need to change someone, the conversation happens in the open rather than through a quietly amended timesheet.

The people who build your system are the people who answer the phone about it in 2029.

None of this is a methodology and none of it would survive being turned into one. It is a handful of small refusals, each of which looks like inefficiency on a spreadsheet and none of which is. Together they are most of the difference between a platform still being improved in year five and one being quietly costed for replacement.