The request already contains an answer

People rarely arrive with a problem. They arrive with a solution: we need a new CRM, we need an app for the drivers, we need to automate the invoicing. Each of those is already an answer to a question nobody wrote down. By the time it reaches a developer, the diagnosis buried inside it has become invisible, because it sounds like a requirement rather than a guess.

Why people do it

They are not being presumptuous. Most of the time they are being considerate. They think they are saving the developer's time by arriving with something specific rather than a vague complaint. They are trying not to burn expensive hours on open-ended conversation. Inside a company, turning up with a problem rather than a request can feel like dumping work on a colleague who has enough on already. And they usually have a genuine, often decent, instinct about what would fix things.

None of that is a fault. It is what a reasonable, considerate person does when they want something fixed and don't want to waste anyone's time getting there.

My share of it

Here is the part I have to own, because it is mine: a clear, confident request is a pleasure to receive. It is specified. It is satisfying to build. Nobody has to have the slightly awkward conversation about whether it is actually the right thing. The path of least resistance, every time, is to simply build what was asked for.

I have done this more than once. Not because the client was wrong to ask, but because it was easier for me to say yes to a well-formed request than to slow down and ask what was underneath it. That is on me, not on the person who asked. A clear request is not an instruction to switch off judgement, and treating it that way is the mistake, every time it happens.

Why the request is so often the wrong shape

The person bringing the request can only see their own layer of the business. They experience the problem exactly where it surfaces, which is often nowhere near where it actually starts. Someone asks for a better way to correct order errors, because correcting them is their job, day in, day out. The errors themselves might be coming from a step two departments upstream that they never see and have no reason to think about.

Someone holding the whole system, rather than one desk in it, can trace a problem back further. And the fix found that way is nearly always smaller than the one that was asked for: a step removed, rather than a system added on top of the step that was causing the trouble.

Questions worth asking before commissioning anything

These are useful whether or not a developer is in the room:

• What would actually be different in a week if this existed?
• Who does this work today, and what do they really do, not what the process says they do?
• What happens when it goes wrong now, and who finds out?
• If this is the answer, what was the question?
• When did you first notice this problem, and what changed around then?

You may notice these are the same questions an audit starts with. That's not a coincidence, it's the same instinct applied on purpose rather than left to chance.

What I'd ask of you instead

Not to stop bringing ideas. Keeping your own instinct out of it would throw away knowledge you genuinely have, about your own business, that nobody else has. The better version looks like this:

Here's what's happening. Here's what I think would fix it. Here's why I think that.

That third line is the whole difference. Your instinct is data. Treated as data, rather than as a finished specification, it becomes something a developer can actually use, alongside everything else they find out by asking around it.

The reframe

It can feel like you're asking too much of a developer to involve them before you've settled on what you want. In my experience it's the opposite: that's precisely the part of the job they are most useful for. A developer's job is to solve the problem you actually have, not just to write the code that was ordered. The same thing happens with briefs in general: see the brief doesn't match the real job.

If you'd rather start that conversation before deciding what to build, that's what the Admin Automation Audit is for.