Work Before Structure

Work Before Structure Part 4 of 4 · 6 October 2026 · 7 min read

Don’t Design the Job Yet. Design the Work.

Before we design the job, shouldn’t we design the work? AI, organisation design, headcount and return-to-office policy are all questions about work design – and the order matters.

Don’t Design the Job Yet. Design the Work.

More times than I can count in my career, I’ve been handed an org chart to redesign, or a headcount number to hit, before anyone could actually tell me what the work was. To be really honest, in my early days, working in a satellite company with a non-European mother ship, it was sometimes just a list of names – and educating people away from that is a story for another day. My first question is always the same: what are we actually trying to get done here? That matters even if the answer is “cut costs”, because the next question becomes: cut costs at what price? I don’t think that’s a pedantic distinction. I think it’s the wrong order. Before we design or redesign the job, shouldn’t we understand – and design – the work?

Cut costs at what price?

Before we design the job, shouldn’t we design the work?

It’s something I’ve done throughout my career under a lot of different names – process mapping, capacity planning, organisation design, time and motion, business process re-engineering, operating model design. Different labels. Same underlying question: what are we actually trying to achieve, and what needs to happen to achieve it?

It’s proper time-and-motion thinking, if you go back far enough. My father-in-law did exactly that more than 50 years ago – what his stopwatch still has to teach us is a piece I'll be sharing soon. At Motorola, the same discipline was non-negotiable: you didn’t go to your boss asking for more resource without knowing your numbers. And it wasn’t just about data entry or call-centre work – the same thinking applied right up through big, complex operations and management-level roles.

But the short version has stayed with me throughout my career: understand the process, the volumes, the exceptions, the skills required – then, and only then, do you know the skills, knowledge and roles you actually need. It can be painstaking. It’s also incredibly valuable.

In the early 2000s, I was leading a team in a remote advisory centre, supporting one sector of the company. Each team was resourced per capita – by the number of employees it supported. A reasonable assumption, you’d think. But the experience, seniority and understanding of the managers in each group varied enormously, and so did the culture and demographics of the employees. So the capacity model needed data. Luckily, we had call-handling data: the number of issues, the number of calls per issue and the length of those calls. It told a very different story. It got my team the right resourcing – and it stopped them joking that I’d have them catheterised to keep the KPIs up. There was definitely feedback in that joke.

I’ve seen the same principle applied to flexibility. Around 2010, I saw it running remote data-entry and call-centre teams at Canterbury City Council – I’ve told that story properly earlier in this series, but the short version is that we understood the work well enough to trust it, wherever it was being done. Flexibility, remote working, productivity, capacity, technology, AI – they all become easier conversations when you actually understand the work.

And I wonder whether AI has just given us a very good reason to bring some of that discipline back. Because organisations everywhere are now asking: what can AI do? I think that’s another question we’re asking too early. Start further back. What needs to be done?

Map the process end to end. What outcome are we trying to deliver, and what actually triggers it? Where does the information come from, and why does it so often get entered again somewhere downstream? What decisions get made along the way, and which of the approvals in there genuinely add value?

Then look at where it actually gets difficult. Where are the exceptions? What needs specialist expertise, and what needs human judgement or empathy rather than a rulebook? What’s purely repetitive?

And – perhaps the most useful question of all – what doesn’t need to happen at all?

Only when we understand that should we decide who, or what, does it. Some activities need a human. Others can be automated, performed or supported by AI, or delivered through specialist technology – and some, honestly, probably don’t need to exist at all any more.

For the activities that do need a human, you can then ask the practical questions. What skills do they need? How much capacity do we actually need? Do they need to be full-time employees, or could this be fractional or specialist capability? And do they need to be based in a particular country? And – coming back to the office debate – which of these activities genuinely require them to be physically somewhere?

This is why I think AI, organisation design, headcount, flexibility and return-to-office policy are far more connected than they first appear. They’re all questions about work design. If we start with the existing org chart, we unconsciously preserve the existing organisation. We take today’s jobs and ask how AI can make them faster. We take today’s team and ask how many people we need. We take today’s office and ask how many days people should attend.

If we start with the existing org chart, we unconsciously preserve the existing organisation.

What if we started with a blank sheet instead?

What’s the most effective way to deliver this outcome now?

Not how we delivered it five years ago, not how the technology happens to be configured, not how responsibilities have historically been split between HR, Finance, Procurement or IT – and not based on protecting the roles or structures that already exist.

Design the best process first, then work out the data, technology and automation that enable it. Do it completely agnostic of the org chart, and of the functions the processes and data currently run through – design around who needs them, not who currently runs them. Only then do you understand where human judgement, capability and relationships genuinely add value – and only then can you calculate the capacity you actually need. Only then design the jobs and the organisation around the work.

Design around who needs them, not who currently runs them.

It’s a subtle change in sequence. But potentially a huge change in outcome. Maybe that’s the real case for bringing a little of that old-fashioned discipline back – not because people need to work faster, but because we need to understand the work before we decide how many people we need, what technology we buy, what AI we introduce, or where everybody needs to sit.

It’s a subtle change in sequence. But potentially a huge change in outcome.

People. Process. Technology. The order matters.

Sources

About the author

Juli Oliver-Smith is a transformation and people change consultant – senior interim, consultancy and programme leadership across people, process, technology and transformation.

More about Juli

Found this useful? Get my monthly newsletter, Understand the Work First, on LinkedIn – or start a conversation.