AI adoption starts with the work

I’m less interested in whether a company has an AI strategy than whether it knows which parts of the working day need improving.

There’s a temptation to begin with a demonstration. A report appears in seconds, a meeting becomes a summary, a spreadsheet answers back. Impressive. But the useful question comes afterwards: what changes for the person doing the job?

Four things would guide my approach.

Look at tasks, not job titles

A job description is a starting point, not a recording of the working day. I’d want to see the interruptions, the checking, the unofficial spreadsheet and the colleague everyone asks when the instructions stop being helpful.

Brynjolfsson and Mitchell’s work makes an important distinction: tasks within the same job can differ substantially in their suitability for machine learning.¹ That is a better unit of analysis than deciding that an entire role is “automatable”.

For each task, I’d record how often it happens, what it costs in time, what good looks like, and what happens when it goes wrong. Then ask whether it needs AI, simpler software, a change in the process, or nothing at all.

Test the whole workflow

A faster first draft is not an improvement if somebody else spends the afternoon repairing it.

The research on the “jagged technological frontier” found that AI could help with some consulting tasks while undermining performance on another.² A convincing demonstration is therefore not enough. I’d test on representative cases, including the awkward ones, and compare the entire result with a baseline.

That comparison should include checking, corrections and handoffs. Decide who can judge the output, when a human needs to intervene, and how to stop or reverse a mistake. And before making a step faster, ask whether it needs to exist.

Let people help shape the change

“This will save you time” leaves a fairly obvious question unanswered: what happens to the time?

Mollick describes incentives and fears that can make employees reluctant to reveal their AI use. His answer involves leadership, internal experimentation and the people doing the work, not just a technology rollout.³

I’d make room for that conversation early. Be honest about the aim and the uncertainties. Train on real tasks. Let people try, question and reject an approach that does not work. Keep supervisors involved and give feedback somewhere useful to go.

The person who points out an exception may be protecting you from an expensive mistake, not resisting progress.

Measure what actually gets better

Logins and training attendance tell you something about activity. They don’t establish value.

In a study of customer-support agents, Brynjolfsson, Li and Raymond found that the benefits of an AI assistant varied with workers’ experience.⁴ I would not assume that one tool, one course or one average describes everyone’s experience.

Choose a few measures before the pilot: time to finish, quality, rework, or the ability to handle a difficult case. Review them with the team. If time is being freed up, decide deliberately what it is for.

For me, auditing the work and supporting the change belong in the same loop. Understand, try, check, adjust. A deployment is an event. Better work is the result worth looking for.