An engineering standard for a team

The team is busy all the time, and nothing comes out.

There are enough people and they work honestly. But there are more systems than people, and each has its own conventions, its own build, its own way of shipping, its own history. What has to be counted is not systems but switches: eight to ten are in play at once, and every entry into someone else's costs a person a day of remembering.

It looks like technical variety and it costs like human variety: the team stops coping before the applications run out.

The pain gets standardised, not the technology. Uniformity by itself is worth nothing and nobody needs it. What gets brought to one shape is exactly what forces people to remember from scratch every time: how to build, where the dependencies live, how to place configuration, how to ship.

What the team already knows gets chosen. A tool is judged not by its merits but by whether it fits the mental model people already have. A familiar model is cheaper than a correct one.

What does not hurt is left alone. This is half the work and the least obvious. Neighbouring systems, less mobile teams, someone else's area of ownership — bringing them to a common shape means acquiring an adapter, an owner and new complexity.

The standard is written as something people use, not as a document. A rule you have to remember does not work; what works is what applies itself.

Switching between your own systems stops costing a day. A change in the environment — a new platform, a new regulation, a new version — moves one thin layer instead of fifty applications.

And, which matters more for the budget: the first change is made by the most expensive person on the team, and the rest repeat it by the cheapest.

Five developers and fifty-odd applications, a large share of them assembled between 2005 and 2010 by different hands.

Then the environment changed its requirements and the whole estate had to move elsewhere. The applications themselves barely changed — one layer moved, the same way for everyone it touched. Work that would once have meant rebuilding fifty applications cost almost nothing.

More than sixty percent of the landscape has been moved to the new approach, incidents stay quiet, and five people still hold fifty applications.

A single stack for everything. Some systems are deliberately left out of it, and that is written down with the reason — a trade, not an omission.

And it is not about hiring. A standard does not replace the people you are missing; it gives time back to the ones you have.

Tell me how many systems your team has in play at once and how many people hold them. If those two numbers differ by several times, there is something to count.