Only One Person Can Put the Product Live. The Benchmark for a Release Anyone Can Make.

The fix was finished on Friday at four. It was tested, and it worked. A customer had been waiting three days for it.

It did not go out on Friday. Putting a new version live takes about twenty steps, done by hand, from one engineer’s own computer, and that engineer was at a family wedding until Tuesday.

Support told the customer “early next week”. On Monday someone tried to follow the engineer’s old notes, stopped at step six, and wisely went no further. The fix went live on Tuesday afternoon.

What We Found

For this article we went through the public record on why changes to working systems wait: one survey of IT professionals on old systems and one survey of senior leaders on finding skills.

Three findings stand out.

Fear of disruption holds change back. In one survey of about 500 IT professionals in the US, run by a firm that sells software services and covering every sector, nearly four in ten named fear of disrupting operations among their reasons for not modernising old systems. A release that only one person can make, by hand, is exactly the kind of change that feels risky to touch. The survey is not about software firms.

Keeping old arrangements going costs money. In the same survey, nearly four in ten named high maintenance and support costs among the top challenges of their old systems. A release done by hand is part of that cost: each one takes the time of the one person who can do it, and waits for them.

The second person is hard to hire. In one survey of about 500 senior leaders at large enterprises that run mainframes, seven in ten said they had had difficulty finding the right skills. Mainframes are not our kind of work, and these are not software product firms. The point we take is narrow: hiring a second release engineer is not a quick way out.

Our reading is that releases settle on one person for ordinary reasons. Releasing began as a few commands the first engineer simply ran. The steps grew, and stayed in one head and on one computer. And nobody dares to learn on the live product, because a mistake in a release reaches every customer at once.

What Waits While Only One Person Can Release

A firm whose releases belong to one person does not stop releasing. It releases when that person is at work, and waits when they are not.

The first cost is the customer. A finished fix sits on a shelf, and support gives a later date for something that is already done.

The second cost is the person. Being the only one who can be rung at night, or on leave, is a load, however much they like the work.

The third is that each release is a little different. Steps done from memory drift, so a fault in one release is hard to trace to its cause.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Make a Release Not Depend on One Person, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Leave releases with the one person, and plan around their diary	Releases are rare and customers are few	Fixes wait for one person, and that person cannot rest
Teach a second person to do the steps by hand	The steps are few and change little	Two people now carry the steps from memory, and they still drift
Write the steps once as an automated release process, in the firm’s own cloud account, with checks that run first, and hand it to the team	The product releases often, and the person who does it today is willing to show each step	It takes that person’s time at the start, and an automated release puts out a faulty change as readily as a good one if the checks do not catch it
Hand the product to an outside firm to host and release	The firm wants no part in running its product	The firm’s delivery now depends on another firm; IOanyT does not host products or run releases

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own product, each with a target.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Who can make a release	One person	Any engineer your firm allows	Your own record of who started each release
Where the release steps live	In one head and on one computer	Written as an automated process in a cloud account your firm holds	The process, handed over with its instructions
Checks before a release goes out	By hand, from memory	Run automatically before every release, and a release that fails them does not go out	The record of each release
A way back to the version before	From memory, if at all	A written step, tried before it is needed	The process and a rehearsal record
A finished fix waiting because one person is away	Common, and not counted	Counted, and none	Your own support records

The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a software firm.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about your product, how a release is made today and who can make one. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is your own product’s code and the steps that put it live today. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. Here that means an automated release process, built in a cloud account your firm holds from the steps the person who makes releases shows us, with checks that run first, handed to your team. Where a part of the product has to be replaced, we replace a system one module at a time while the old one keeps running. We never do a single cutover. Each rebuilt module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each stage we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

This approach has limits. We do not run your releases, host your product or stay on call for it; your team runs the process afterwards. We do not manage, recover, transfer or secure accounts or passwords; the sign-in details the release uses stay in your own accounts, under your control; and we do not decide who in your firm may start a release; that is a matter of access, and yours. An automated release does not make a product or an account secure, and a list of who holds what does not either. We do not carry out a security review. We give no legal or employment advice, including on who is on call. We do not back up or recover data. We are not a staffing firm, and we have no assistant that answers questions about your code. A product that runs on servers of your own may need more work before its release can be automated. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a software firm.

What changes for the business:

Role	What they gain
CEO	A fix for a customer can go out on the day it is ready, whoever is at work.
CTO or CIO	Releases are made by a written, automated process in the firm’s own account, so any engineer the firm allows can make one, the same way each time.
CFO	The product’s running costs sit in an account the firm holds, and an urgent fix no longer depends on one person being reachable.
Head of operations	Customers get a fix when it is ready, and support can give a date without first asking where one person is.
Head of people	No one is the only person who can be rung at night, and that duty can be shared.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
This article names no organisation. Its figures come from a vendor’s survey of IT professionals and a survey of senior leaders at large enterprises.	We build an automated release process in a cloud account your firm holds and hand it to your team. We do not run releases, host the product, manage accounts or decide who may release.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The free Reliability Review is where to start: one conversation about how your product is released today, and by whom.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →