Start With the Job, Not the System

A platform can look completely healthy on a dashboard and still be making someone's day harder.

The integration ran. The report refreshed. The ticket closed inside SLA. And somewhere in the business, someone is copying data from one screen into another, chasing an approval they can't see, or asking three different teams the same question because nobody has told them who owns the answer.

So I've stopped judging platforms by what they run, and started judging them by the work they take away. Nobody experiences Workday, ServiceNow, Salesforce or a data platform as separate systems. They experience something they are trying to get done.

That is why I use the established Jobs to Be Done framework as a lens for platform decisions. The framework is not mine; the way I apply it here is to examine the work that remains after a system migration.

The usual starting question is: what should this system do? I prefer: what is this person actually trying to accomplish?

It sounds like a small change in wording. In practice, it changes the whole conversation. An employee going on parental leave is not trying to complete a business process. They want to know what they are entitled to, what happens to their pay and benefits, what they have to do and by when, and whether anything has been missed.

A manager changing someone's role isn't thinking about the integrations between HR, payroll, finance, identity and half a dozen downstream systems. They want the change to be right, on time, and done once.

Once the job is clear, you can work backwards into the technology. Doing it the other way round is how you end up with a beautifully configured process that nobody can finish.

Consolidation helps, but it isn't the outcome

Fewer systems can genuinely remove complexity, and I'm usually in favour of it.

But moving five complicated processes into one application doesn't make them simple. If the employee still enters the same information twice, waits for the same sequential approvals, and calls a support team to learn where a request stands, we have changed the system count without simplifying the process. The consolidation pays off for the employee when those hand-offs, duplicate fields, and unnecessary steps actually disappear.

So before consolidating anything, I want straight answers to four questions:

• What job are we helping someone complete?
• Which steps genuinely help them complete it?
• Which steps exist because of regulation, security or policy?
• Which steps exist because this is how we've always done it?

That last question is where a lot of the value hides, and it's the one we tend to skip. Then, instead of asking whether every feature was migrated, we can ask something more useful: does the new experience get someone through the job with less effort, less waiting and less doubt?

That's a far better measure of success.

The job crosses system boundaries

One job rarely lives in one place. A request starts in ServiceNow, triggers something in Workday, runs through an integration, updates a data platform, and eventually shows up in a handful of downstream systems.

The employee doesn't care where one platform ends and the next begins. To them, it's still one job. Which means ownership, data quality, security, integrations and support are all part of the experience, not sitting next to it.

When one of them breaks, nobody asks which system caused it. They just know their work is stuck. This is the part I think platform teams have to get comfortable with.

A technically successful system can sit inside a genuinely poor end-to-end experience.

Make the hand-offs visible

Try this with something ordinary, like a simple employee data change. Map it from the first request to the last downstream update, then ask:

• Who owns each step, and why does that step exist?
• Which system owns the data?
• What happens when it fails, and who fixes it?
• Where does the work sit and wait?
• Where is someone moving information by hand?
• Where are we asking the employee for something we already know?

You'll learn more from one map like that than from reviewing each system on its own. It also gives you a baseline worth measuring.

How many manual touches are there today? Where do the errors cluster?

Which exceptions really need human judgement? And which steps could disappear altogether?

Good platform work usually becomes invisible

Some of the best work we do is work nobody notices. The job gets done faster. Fewer hand-offs. Less rework. Less waiting. Fewer tickets. And fewer occasions where someone has to understand the org chart just to get something done.

Architecture, integrations, and data matter because they determine whether that simpler journey is reliable. They are means to the outcome. A platform earns its keep by what it removes from someone else's day.

So the question I'd want to answer at the end of any platform programme is a simple one:

Did we make the job easier to complete?

Which leads straight to the next question. If we start with the job rather than the system, are all jobs equally important?

Probably not. There are points in someone's working life where the experience carries far more weight.

Joining a company. Getting promoted. Becoming a manager. Having a child. Moving countries. Taking extended leave. Leaving. Those aren't just transactions.

They're moments that matter, and that's where I'll go in Part 2.

Start with the job. Then look at the moments where getting that job right matters most.

Ideas and perspectives are my own. Writing and editing assisted by AI.