Leadership, Talent & 360 Specialists | Hogan Assessments Authorised Distributor UK & Ireland

Latest Insights

Blog: What happens to job design when we can test a role before we build it?

Blog: What happens to job design when we can test a role before we build it?

Author: Ali Akkaya, Senior Digital Solutions Manager, CRF

In a recent business strategy meeting, my colleague Karen – the MD of our sister company, PARC – said something I haven’t been able to put down. She said she doesn’t ask AI how to do her job. She asks which parts of her job should be AI’s at all.

Read that back. A business leader, not a technologist, had just described which might be the most important skill of the next decade, and she’d have called it common sense.

Because for sixty years, the science of work has quietly known how to answer Karen’s question. Decades of research, from the Tavistock coal-mine studies onwards, converged on one stubborn finding: performance is a property of how the work is designed, not of the worker, and not of the tool. The theory was settled. The experiment was the problem. Redesigning a human role takes months and lands on real people, so mostly we guessed, restructured, and read the post-mortem three years later.

Last time, I asked whether we’re building AI agents the same careless way we’ve built jobs for sixty years. This piece is the other half of that thought. Because GenAI has just handed the science of work the one thing it never had: a way to test a role (with scope, tools, authority, hand-offs, checks) before we commit a single human being to it. Stand it up, tear it down in minutes, watch exactly how it performs. Aviation had a machine (wind tunnels) that did this for flight, and I’ve leaned on that image before; borrow it if it helps. But the machine matters far less than what it lets us finally do: design the work on purpose.

So, here’s the flag I want to plant, and I’ll be blunt about it. The biggest risk in this transition isn’t the technology. It’s who we’ve left holding the design. If it’s IT leading the automation in your company, you might want to think again. Automation is an operating-model transformation, not an IT project. IT can lead the tooling, but designing the work is a business and people decision, and the leaders best placed to make it are too often the ones still waiting to be told what the tool can do. Technology is the enabler here. It was never meant to be the author.

A forty-year-old prediction, coming true at scale

Before anyone tells you GenAI’s effect on work is unprecedented, let me introduce Lisanne Bainbridge. In 1983 she wrote a short paper, Ironies of Automation, and its central irony has aged frighteningly well. Automate the hard parts, the thinking went, and people are left with the easy ones. What actually happens is the opposite. Automation strips out the easy, routine work and leaves the hard residue behind,  more abstract, more vigilant, heavier per decision.

Four decades on, BCG put numbers to her hunch. Two-thirds of regular AI users, 67%, say their job satisfaction went up. And 41% say their cognitive load went up too. Wait a minute, you wouldn’t normally expect those two to move together, would you? Higher satisfaction usually comes with less strain, not more. Both are true, though, and once you think in job-design terms you can see why. AI clears out the repetitive parts of a role and leaves the residue: the ambiguous, judgment-heavy, someone-has-to-decide work. And let’s not forget the chore nobody put in the budget: checking the machine’s homework which is why nearly half of users now spend more time directing and reviewing AI than doing the task themselves.

In Hackman and Oldham’s language, the very same change can enrich a job (more skill variety, more autonomy) or hollow it out (less sense of the whole task, relentless load). And which one you get is not a property of the model. It’s a property of the redesign you did, or didn’t do.

So, these tensions aren’t contradictions to argue about. They’re design variables. And here’s where I get a bit stubborn: those variables belong on a business leader’s desk, or a job designer’s, not the IT department’s (alone), and not the desk of whoever happens to be building the agents. This is HR’s fight, and the C-suite’s. If the people who understand the work aren’t in the room when the work is redesigned, don’t be surprised when the redesign forgets the human in it.

Which brings me back to Karen’s point: If most of your organisation is still asking “how do I write a better prompt?”, they are, in effect, asking the machine how to do their jobs. And I get it, how you prompt a tool does matter and there is definitely value in it. But what matters far more is the question you ask yourself, as a business leader, long before you ever open the tool.

Don’t ask AI how to do your job. Ask which parts of the job should be AI’s at all.

That one reframe does most of the work. It turns a technology question into a design question, and it puts you, not the model, back in charge of the answer. Map the process first, then interrogate it honestly. What are you actually trying to achieve, and would you or your clients still want it if the tool didn’t exist? Which parts of the work are routine and rule-bound enough to hand over? And which parts turn on judgment, carry the weight of accountability, and should stay firmly with a person? Hand over the first kind. Guard the second. That is the job, not prompt-craft.

The gauges lie, unless you fit real ones

Here’s the catch. We built the tunnel before we learned to read the instruments. In 2025, METR ran a proper randomised controlled trial, experienced developers, real tasks, codebases they knew well. Going in, they expected AI tools to speed them up by 24%. In reality, they were 19% slower. And afterwards, they still believed they’d been roughly 20% faster. That’s a forty-point gap between what people felt and what actually happened which should worry anyone whose AI business case rests on asking staff how much time they think they saved. Which, let’s be honest, is most AI business cases.

And the failure isn’t loud, either. BCG’s field experiment with 758 consultants mapped what they called the “jagged frontier”: just outside the boundary of what AI does well, on tasks that looked almost identical, consultants using AI were 19 percentage points more likely to be confidently wrong. AI doesn’t fail like a machine. It fails like a plausible colleague.

Think about your own experience with GenAI for a second. From time to time, hasn’t it felt like that? Sometimes the answer reads beautifully and sounds completely plausible, and only when you stop and look harder you notice it’s wrong, or simply not adding any value.

Autonomous does not mean unsupervised

If I had to defend one line of the AI budget hardest, it would be instrumentation: the ability to see what the work is actually doing, continuously, from the inside. Taylor measured work once, from the outside, with a stopwatch. A traced agentic workflow measures it all the time, and the same signal tells the engineer whether the agent is drifting, the risk officer whether decisions can be audited, and the executive whether the freed-up capacity a

? ? !