FIELD NOTE 21  ·  APRIL 2026  ·  7 MIN

Who owns the tool your operations manager built in a weekend

People who cannot write code are now building working software. Most of it is fine. The trouble starts on the day the business cannot run without it and the person who made it has left.

This is new, it is happening in most organisations I walk into, and I want to be clear that I am not against it. Somebody in operations who has never written a line of code describes what they want, and by Monday there is a working tool doing a job nobody was ever going to fund properly.

That is a good outcome. The spreadsheet it replaced was worse. The request that would have sat in the IT queue for a year got solved by the person who actually had the problem, and that person usually understands it better than anyone else in the building.

The moment it changes

It changes when other people start depending on it. One person's private shortcut is their own business. The same tool six months later, feeding the numbers into a report that goes to your board, is part of how the company operates, and nobody has ever looked inside it.

Nobody decided that would happen. It happened because the thing worked.

How these go wrong

The person leaves. Rarely in dramatic circumstances. They move to another department, or they are on leave in the week it stops working, and it runs under their name on their account, and no one else has ever opened it.

Nobody can explain what it does. This one catches people out, because the answer is often that the person who built it cannot explain it either. They described the outcome they wanted and accepted what came back. It worked, so no one asked further. Then a figure looks wrong and there is no way to check how it was produced.

It can reach further than it should. This is the one I would worry about first. The tool was built using somebody's own login, and that login belongs to a person who has been with the company nine years and has quietly collected access to almost everything. The tool inherited all of it. It needed to read one folder and it can read payroll.

How to tell a shortcut from a liability

Five questions per tool, and the sorting takes an afternoon.

  • If it stopped this morning, who would notice, and would anything beyond their own work stop with it?
  • Does it only read, or does it write into something other people rely on?
  • Does it touch money, information about named staff or customers, or anything an inspector can ask about?
  • Does anyone outside the company see what comes out of it, directly or inside a document?
  • Whose account does it run as, and what else can that account reach?

Anything that only reads, is used by one person, and touches nothing sensitive should be left alone. Interfering with those is how you guarantee that the next one gets hidden from you.

What to do about the ones you already have

You will not get an honest list by auditing. An audit produces a partial list, because people who suspect their tool might be confiscated do not put it on the form.

Run an amnesty instead. Say it plainly: for the next two weeks, tell us what you have built, nothing gets taken away without a conversation, and we will help with the ones that matter. Then honour it, including for the one that makes you wince. The first time you break that promise the practice goes underground and stays there.

Adopting one properly is smaller than people fear

For the few that turn out to be load-bearing, meaning the business genuinely stops without them, the work is dull and short. Move the code somewhere the company controls rather than a laptop. Give it an account of its own that can reach what it needs and nothing else. Write one page covering what it does, what it reads, what it writes and what to do when it breaks. Name an owner, who does not have to be the person who built it.

That is usually a week of somebody's attention. Rebuilding it from scratch with engineers, which is the instinct, costs many times more and is often unnecessary. The hard part was understanding the problem, and that part is already done.

The outcome I would avoid is the one where the tool is taken away to be rebuilt properly, eighteen months pass, it still has not been, and the operations manager is running the original from a laptop under their desk. I have seen that arrangement more than once. Nobody planned it and everybody knew about it.

If you want a straight opinion on which of yours are fine and which need attention, a list of what people have built and what each one touches is enough to start from. It does not need to be tidy.

Working through this on a live programme?

A 45-minute call with the engineer who would run the work. We will tell you whether AI is the answer, including when it is not.