Do you know who has amazing information on the problems of your business? The people who work inside it. Everyone has sat at their desk and said “I could do this a better way… if someone would just let me.”
Let them. With your help, and strategic guidance, sure. But let them.
I’ve talked about this before. Today I want to talk about the tell-tale sign you aren’t asking your staff how things can get better.
The answer is “The Workaround.”
The Workaround
The Workaround is a good person trying to do their job despite the skills, systems and support they’ve been given not being enough. It’s the spreadsheet that sits beside the database. The private tab nobody else uses. The notepad on the desk with the real dates in it. The personal tracker. The prompt sheet somebody wrote out because the process lived in their head and they were sick of forgetting a step at four o’clock on a Friday.
Every one of those marks the exact point where the official system stopped helping. Not roughly. Exactly. Somebody hit a wall, and rather than complain about it, they built a small thing to get past it, and then never mentioned it again.
Don’t ask people what they need
I know that sounds wrong. Asking is the polite thing, and it’s what every requirements-gathering session in the world is built on. It also doesn’t work.
Ask somebody what they need from the system and you’ll get one of three answers. What they think you can actually deliver, which is a guess about your budget rather than a statement of their problem. What they heard somebody else complain about in the kitchen. Or nothing, a long pause, and “I don’t know really, it’s fine”.
That last one isn’t obstruction. Most people aren’t in the habit of designing software, they’ve got a job to do that isn’t this, and nobody wants to look daft in front of a consultant with a notepad. So they say it’s fine.
It isn’t fine. There’s a spreadsheet. A spreadsheet sucks.
Ask to see their morning instead
Sit beside them. Their screen, their login, their actual records. Ask them to walk you through one real piece of work from the moment it arrived.
Then stop talking.
The workarounds surface inside ten minutes, unprompted, and they nearly always arrive with an apology attached. “This is probably not how you’re supposed to do it.” “I know this is a bit rubbish, but.” “Sorry, I’ve got my own way of doing this.”
Every apology is a requirement.
Three things make it work, and all three are easy to get wrong.
Their screen, not a demonstration account. People perform on a clean account. Nobody can perform on their own inbox.
A real live example, not a hypothetical. “Show me the last enquiry that came in” gets you the truth. “What happens when an enquiry comes in” gets you the training manual, recited back.
And no correcting. Not once, not kindly, not at the end. No comparing one person to another out loud either, not even favourably. The moment somebody thinks they’re being marked, the workarounds go back in the drawer, and the workarounds were the entire point of being there.
What you end up with
A specification written by the people who’ll have to live with it.
Which happens to be the same reason they adopt it. Nobody defends themselves against a system built out of their own workarounds, because there’s nothing to defend against. You haven’t arrived and told them they’ve been doing it wrong for six years. You’ve told them they were right, and the system was slow to catch up.
Here’s the reframe that took me a while to get to. These aren’t bad habits to be trained out of people. They’re unpaid design work, done by your best staff, in their own time, usually at their own inconvenience.
And every consultant who turns up with a template throws the lot away.
Not every workaround is a requirement
I need to say this before somebody says it to me. Treat every workaround as sacred and you’ll build the existing mess into the shiny new thing, then wonder why it feels the same. Some workarounds are one person’s preference and nothing more. Some solve a problem that got fixed two years ago and nobody told them.
The nastiest version is the one where somebody meets a real need by putting something into the system that isn’t true. Marking a thing as finished so it stops nagging. Recording it in the only field that makes the next bit happen. The need is real, the person is doing their job, and the organisation’s own numbers stop meaning anything. This isn’t new, by the way. Lars Gasser wrote it up in 1986, watching people knowingly feed false data into their systems to get a usable result out of the other end. Forty years, same behaviour, better logos.
So there’s always a second question, and it’s the one that does the work.
Not “what does this do”, which just preserves the shape of the workaround. “What is this for”, which gets you the need underneath it.
Then meet the need properly. The workaround tells you where to look. It doesn’t tell you what to build.
That’s also the honest limit of the whole method, and I’d rather say it than have it found out. This surfaces every problem somebody has personally worked around. It surfaces nothing that nobody noticed. Finding the ones no one notices… that’s a consultant’s job. But then I would say that.
