The Person Who Never Complains

In 2012 we went to register our company properly and found out we couldn’t have our own name.

The name was AMS Technologies. A company in Maharashtra already had it. There was nothing to argue about and nobody to appeal to. We had to throw the name away and think of a new one.

I remember it being a genuine mess. Letterheads, visiting cards, email addresses, all of it had to change. But more than the paperwork, it just felt wrong. It was our name.

We registered as Brainium Information Technologies on 21 March 2013.

Thirteen years later, I honestly can’t remember the last time I thought about any of it. Brainium is the company. AMS is a story I tell at dinner now and then. Not one client has ever asked me about it.

I bring it up because of what that rename taught me, and what it didn’t. It taught me that grief about a change can be real and still be wrong about the future. What it didn’t teach me, and what took me far longer to see, is why that change was so easy compared with the ones my clients face.

A rename is the simple kind of change. Everything that needed fixing was written on something. A letterhead, a card, an email signature. You could list every piece of it on one page and tick them off.

Now think about the systems nobody can list on one page.

Most companies with some years behind them have one. A platform that has quietly run the business for ten or fifteen years. An order system, a billing engine, a warehouse tool. It was built by a small team back then, and over time, the team shrank to a person.

I want to be careful here, because I’m not describing a villain. I’m describing the best person in the room. They built the thing, or they inherited it early and made it their own. When it breaks, they’re the first to log in. They know why one field must never be left blank. They know which job must never run twice. They’ve never threatened to leave, and in all those years they’ve hardly made a fuss about anything.

Now here’s the thing. That is exactly why nobody sees the risk.

Think about what an unreliable person does to a company. You can’t depend on them, so you document everything. You write down how things work because you have to. The paperwork is annoying, but it exists, and it protects you.

Now think about what a completely reliable person does. Everything works. Nothing breaks for long. Nobody has a reason to ask how it works, because the answer is always “ask them, they’ll sort it.” So nothing gets written down. Year after year, the knowledge moves out of the system and into one head.

Nobody planned it. Nobody did anything wrong. To be fair, it happened because the person was so good at the job.

And the person doesn’t tell you either. Loyal people tend not to. They don’t want to look like they’re making themselves indispensable. They don’t want to ask for time to write documentation when there are tickets in the queue. They’d rather quietly carry it than make it your problem. So the one signal that might have warned you never arrives.

The risk doesn’t show up in any dashboard. It isn’t in your risk register, because nothing has gone wrong yet. It sits there for years.

Then one day the person retires, or falls sick, or takes a better offer. Or they simply go on holiday, and a month-end run fails for the first time in years. That’s when you find out what was never written down. And by then it’s usually the worst possible time to find out.

This is also where modernization projects go wrong, and it’s the part I most want leaders to hear. People assume a migration fails because the new architecture was poorly chosen. In my experience that’s rarely the reason. It fails because the plan was built from the code and the documentation, and the real behaviour of the system lived somewhere else. The plan never asked the one person who knew.

So when we assess a system, the first thing we do isn’t read the code. We find out who built it, and we go and talk to them. Quite often that conversation changes the whole plan. Sometimes it saves it.

You don’t need a modernization project to start. Here is what I’d do this week.

Ask your longest-serving builder one question. If you were away for a month, what would break first? Not what should break. What would.

Listen to the whole answer before you react to any of it. It’ll probably be longer than you expect. Some of it will worry you. That’s the point.

Then ask them to walk someone else through it, and record it if they’ll allow it. A recording is rough, but it’s a hundred times better than nothing. Pair someone with them for a few weeks, and protect that time, because it will feel like a luxury and it isn’t.

Do all of this kindly. They’ve given you years of quiet work, and this isn’t an audit of them. It’s a look at how the company arranged things. If one person holds that much, the company let that happen. The person didn’t. And say thank you while you’re at it. It’s probably overdue.

If the answer to my question frightens you, and you’re thinking about moving off an old platform, that’s a good time to talk. We start every migration by finding out who built it and what they know, before we draw a single diagram. If you’d like to see how that works in practice, you can start with our platform migration work.

And if you’re the builder reading this, the one who’s kept something alive for years and has never been asked, I’d like to hear your answer. I suspect nobody has asked you.