Building engineering teams that outlast the project

Plenty of programmes deliver on time and leave behind something nobody can safely change. The code shipped, the consultants left, and the knowledge went with them. The failure is not technical, and it is visible long before handover if you know where to look.

Staff for the second year

Teams assembled purely for delivery speed optimise for the wrong horizon. The people who will operate the system should be writing it, reviewing it and being paged by it from early on, not briefed on it at the end.

Knowledge transfer sessions in the final sprint are a symptom. If a walkthrough is the mechanism, the transfer has already failed.

If the handover meeting is where your client first sees the code, the project is already a liability for them.

Write things down where the work happens

Documentation nobody reads is usually documentation stored away from the code. Decisions recorded next to what they affect, in the repository, survive. Wikis drift within a quarter.

The entry worth writing is not what the code does, which can be read, but why it does it that way and what was rejected. That is the part nobody can reconstruct later.

Make the system legible under pressure

• A new engineer can run the whole thing locally on their first day.
• The deploy path is one documented command, not institutional memory.
• Alerts name the user-visible symptom, not the metric that crossed a line.
• Every scheduled job has an owner who would notice if it stopped.

These sound like hygiene. In practice they decide whether the first incident after handover is resolved in an hour or becomes the reason the system gets replaced in two years.

The test

A simple one: could the client's own team ship a meaningful change next week without calling anyone who is leaving? If the honest answer is no, the project is not finished, regardless of what the plan says.