You automated your worst process. Congratulations — you now produce garbage at unprecedented speed.

That’s where the efficiency question gets you. Point AI at the monthly report and it comes back in forty minutes instead of a day and a half, everyone nods, and nobody in the room asks whether the report was worth writing.

Peter Drucker was asking that question back in 1963 — if we weren’t already doing this, would we start? — and it never became routine practice, because answering it properly took a consultant, three months, and a budget line nobody wanted to own. That’s the bill AI has just torn up.

Why we start with speed

Efficiency is legible. A before and an after, a number you can put on a slide, and nobody has to explain themselves or lose anything to get it approved.

Effectiveness gives you none of that. When you stop doing something, the saving doesn’t show up anywhere — the metric it improves is one you weren’t measuring, and the person who used to do the work is standing there with an empty Tuesday. There’s no chart for it. So the speed project gets approved and Drucker’s question never makes the agenda, which is a perfectly rational thing for a busy management team to let happen.

You can see the pattern in where the money goes. When MIT’s Project NANDA asked executives in 2025 how they’d allocate a notional AI budget — early findings, but telling ones — close to half went on sales and marketing, yet some of the clearest savings the same study documented came from the unglamorous back office: BPO contracts ended, agency fees cut, outsourced work brought back in-house. The researchers’ own explanation was measurability. Sales and marketing win the budget because their outcomes are the easiest to put in front of a board, which is the efficiency slide all over again.

Drucker already wrote the test

In May 1963, Drucker published Managing for Business Effectiveness in the Harvard Business Review. A few pages in, he names the problem almost exactly as it still presents itself today: “It is fundamentally the confusion between effectiveness and efficiency that stands between doing the right things and doing things right. There is surely nothing quite so useless as doing with great efficiency what should not be done at all.”

He doesn’t leave it there. At the end of the piece he stops philosophising and hands you a procedure. Every product, operation and activity, he says, should be put on trial for its life every two or three years, considered exactly as you’d consider a proposal to start it fresh — budget, capital request, the lot. And one question gets asked of each:

“If we were not in this already, would we now go into it?” And if the answer is “no”, the next question should be: “How do we get out and how fast?”

The question now sold as AI-native was written sixty-three years ago, for a world of typing pools and carbon paper.

The reason it stayed in books rather than operating meetings is what an honest answer demands: who actually consumes this output, what decisions it changes, what happens downstream if it stops. Gathering it all is what the consultant and the three months were for. Put a process on trial for its life and you had to fund the trial, so for sixty years it mostly didn’t get asked.

What has actually changed

Reading two years of support tickets and telling you what people are really asking about used to be a research project. Now it’s an afternoon. Working out whether anyone acts on the weekly management pack, whether the qualification notes ever get opened, which approval step has never once produced a rejection — that’s dull, high-volume pattern-reading, which models are unreasonably good at and which humans were always far too expensive to be pointed at. Cheap isn’t the same as trustworthy, of course: treat what the model surfaces as a place to start looking, and check it against the logs and the people who own the decision before you delete anything on the strength of it.

Drucker’s trial-for-its-life just got cheap — and most of us are spending the windfall on emails.

Somebody has to lose

Speed projects are easy to present as non-threatening. Everyone keeps their role, the work simply arrives faster, and the meeting where you announce it goes down well with the room. Some of them do eliminate a supplier or a contract, but the story you tell about them is a story about doing more, and that’s a comfortable story to tell.

Ask whether a process should exist and you lose that comfort. Somebody sits in the meeting and hears that the thing they’ve organised their week around might be waste. Compute is cheap; what costs is the conversation where a report three people produce every Monday is shown to go unread, or where a two-stage approval turns out to exist because of an incident in 2017 everyone has forgotten.

Drucker saw all this coming and was refreshingly honest about it. The last and most crucial requirement of his whole procedure, he wrote, was “the courage to go through with logical decisions” — and he knew of no checklist for managerial courage. Sixty-three years on, still no checklist. It remains the part of this that no tool will do for you. Approving a productivity project makes for a much pleasanter meeting than telling a good person their best work is redundant. Whether cheap evidence is enough to shift that, I honestly don’t know; it takes away the excuse and leaves the discomfort exactly where it was.

I’ve written before about businesses automating the thinking and keeping all the busywork, and it grows from the same root: we treat the process as fixed and the tool as the variable.

What this looks like in practice

Take customer support. Point a model at the ticket queue, have it draft replies, watch response times halve — genuinely useful, and most teams should do it. Now feed the same model six months of tickets and ask what people are actually contacting you about. It may come back and tell you that a third of your volume traces to one confusing screen in onboarding. You fix the screen, the tickets stop arriving, and there’s nothing left to draft replies to.

The second version is more work, and it’s work of a kind your support manager may not thank you for. It also stops the problem instead of subsidising it.

Marketing gives you the same fork. You can have AI write the monthly campaign in a fraction of the time, or you can have it read seven years of engagement data and tell you the segment you email most has opened nothing since 2024, and the channel that converted best is one you dropped in 2019. One of those makes your Thursday easier. The other changes what your marketing team does on Monday.

The fork is the same wherever you point it: speeding a thing up improves the artefact, while Drucker’s question asks whether the artefact was ever earning its keep.

Where to start

None of this needs a transformation programme. I’ve argued before that the businesses which benefit most from AI are the ones redesigned around it rather than merely enabled by it, and that redesign starts a great deal smaller than it sounds — with a slightly different habit.

  1. Gather the evidence before you gather the requirements. The whole argument rests on evidence being cheap now, so go and get some. Usage logs, ticket themes, CRM activity, who opens which report, how many approvals have ever produced a rejection. A day of that will tell you more about your operation than a fortnight of workshops.
  2. Put one process on trial. Pick something recurring — a report, a meeting, an approval, a handoff — and ask Drucker’s question with the modern condition attached: if we were starting today, with these tools available, would we build this at all? The condition matters. Plenty of processes exist only to compensate for something a model now handles in the background.
  3. Move the metric up a level. If what you’re improving is “time to produce X”, you’re still in speed mode. Track what proportion of proposals convert, or how many tickets arrive, and the effectiveness question starts asking itself.
  4. Give someone permission to lose. Whoever owns the process you’re questioning has to be safe to conclude it should go. If deleting their work costs them status or headcount, they’ll defend it, and they’ll be right to. This is a leadership problem well before it’s an AI one.
  5. At scale, start in one function. In a business of thirty you can put the whole recurring workload on a whiteboard in a morning. At three thousand, the process nobody can justify is the process four departments have wired themselves into, and a company-wide review will stall. Run it properly in one team, publish what you deleted, and let the next function ask to go second.

The bottom line

Speed is worth having and I’d never tell a business to turn one down. But every competitor is collecting the same gains, which makes it a thin sort of advantage. The larger opportunity is sitting in the work you’d never start today, and reaching it now takes an afternoon of evidence and the nerve to act on what it shows. The afternoon is new; the nerve was always the job.