Something happens in businesses like yours somewhere around the eight-month mark. It is never dramatic. Nobody quits over it. Nothing catches fire. Nobody's spreadsheet breaks. 📊
Somebody fixes something. It is a genuine improvement — a shared folder that finally works, a booking link that stops double-booking, a phone number that reaches the office instead of a voicemail box. Two weeks later it is undone. By somebody who was trying to help. In a way that made complete sense to them.
Then somebody else fixes it back. And back. And back. And by the third cycle the people involved are quietly avoiding the part of the business where it lives, because every time they go there they get to feel slightly foolish. 🧩
This is not a discipline problem
I want to be careful here, because the first thing most people do with this is blame whoever undid the fix, and the second thing they do is decide their team is careless. I don't think either of those is true, and I think both of them cost about six months. 🛑
Here's the mechanism, and it's the whole post. A fix is a message. When somebody changes something and it holds, the message that lands is: that's how it works now. When somebody changes it back, the message that lands is: it was wrong and I fixed it. Neither message mentions ownership, because neither one was aimed at ownership. Both people behaved reasonably. The system still lost. 🔍
They want you to call this a people problem. I think that's wrong, and worse, I think it sends you looking in the wrong direction for half a year — at the team, at the training, at the handover document — while the actual gap is sitting inside the software asking a question nobody has ever been given the authority to answer.
Most systems don't fail because nobody cares. They fail because nobody was ever named.
The three questions that find it
A Digital Systems Scan starts somewhere most people don't expect. Not with the messy folder, and not with the tool everyone hates. With one question, asked of the people who touch the setup every single day: who owns this?
1️⃣ Name every piece of software your business runs on that a customer ever touches. Now ask, out loud, in a room: who can change it? Watch what happens. There is usually one person who says that's mine, and then three who go quiet — because they have all made small changes to it and were never told they were allowed. 📝
2️⃣ Ask the one who said that's mine: when did you last change it, and did you tell anybody? The answer is usually a long pause. Usually around eleven months.
3️⃣ Ask what happens to a customer if that thing goes down for four hours tomorrow. Who notices? Who fixes it? Who tells the customers? Three separate questions — and in most businesses the answers are three different people, none of whom have ever been told they are the answer.
If you got a clean answer to all three, you have a system. If you got a shrug on any one of them, you have a setup, and no amount of tidying is going to change that. The tidy-up is the part everybody can see, which is exactly why it gets the attention and it isn't the part that's costing you. 💌
What it actually costs
Not the redo. The redo is an hour, and honestly the hour is fine. The cost is that your most capable people stop volunteering for work in the part of the business where they used to be useful — and you find out about it when one of them hands in something that surprises everybody except them. 🕯️
I see this constantly. It is the single most common thing that separates a business that is busy from one that is running, and it has never once appeared in a report, because nobody has ever built a report for it.
It also does not fix itself with better people. I know that is the easy answer. It equally does not fix itself with a better tool, which is the other easy answer and the expensive one — I have watched businesses buy an entire platform to solve an ownership problem and end up with a bigger, more expensive, equally unowned thing. 🏦
The prescription
Three things, and not one of them is software.
One. Every tool that touches a customer gets exactly one named owner, written down where the whole team can see it, with a date next to it. A person's name, not a job title. Job titles outlive the people who hold them, and they survive people who have quietly moved on. 💅🏾
Two. Nobody changes anything inside a system another person owns without saying so first, in the place the owner will actually look. This costs nothing and takes a day to install, and it is the entire difference between a fix and a message.
Three. Every quarter, pick the one system that would embarrass you most to lose, and run one real test of it. Not a check that it exists — a test where you pretend it doesn't, and time how long it takes for a customer to notice. 📦
Then put what you learn somewhere. That part is free, and it is the part everybody skips.
What changes once it's fixed
Somewhere in month two, somebody changes something and tells you about it, and your first reaction is a completely normal one. It used to be a small internal alarm every single time somebody said the words I changed something. 🔐
What you have actually built, and what will never appear on a slide, is permission to fix things. That is the asset. A team that can change a broken thing on a Tuesday afternoon is worth more than any platform, and it costs one page of writing to keep. 🌿
The takeaway
Today: pick one piece of software that touches a customer and write one person's name next to it. Then ask the team who can change it, and write down the hands that go up. Ten minutes. That is most of a Digital Systems Scan in miniature — not the tidy-up you've been meaning to schedule, but the one question sitting underneath all of it.
You didn't have a technology problem. You had an unanswered question and three good people doing their best with what they were given. ⚡