designing work that's good for people and performance.

Randstad Advisory Signals from the Edge: what binds the system and people together

Is your company redesigning the work or just the worker? As organizations adopt artificial intelligence, true productivity gains come from redesigning work systems rather than just retraining workers. The AI transformation requires a shift from technical prompt skills to human judgment, intent and clear quality standards. Learn about the five core shifts in AI systems, how to prevent erosion of the critical tacit knowledge and mortar that hold businesses together, and how you can build systems that leave room for quality assurance while driving performance of both your people and the technology.

When we look back in 2030, we are likely to see that the people building AI systems changed their minds five times in ten years about what actually makes work work. Each time, they will have moved further away from "getting the machine right" and closer to "getting the work around it right."

We’ll also see the majority of companies didn't do this. Instead, they will have trained individuals to be better at using the tools, one step behind where the real problem moved to.

They will have become really good at redesigning the visible parts of an organization; the roles, the processes, the systems. But, at the same time, they will have accidentally devalued and deprioritized the invisible stuff that held them all together.

Today, this is what we should be thinking about to avoid that, and it comes down to one thing: Work only gets better when you redesign the work, not the worker.

what the engineers learned is helpful for non-engineers

The architecture built by engineers to govern AI has gone through five shifts. 

1. 1. The prompt: We thought it was about how you asked.
      Early on, everybody believed the trick to a good AI prompt was phrasing. Say it the right way and you'd get a good answer. There was a job title for it. Whole training programs were built on it. This is important, but not the key, because the same request worded slightly differently can deliver wildly different quality. That's not a skills gap; that's a design gap wearing a skills gap's clothes.
      
      
   2. The context: It was about what the system knew of your world.
      The technology wasn't short of intelligence. It was short of situation. It didn't know the client, the history, the last decision, the thing everyone in the room already understood without saying. So the work shifted to giving the system the full picture. This produced much better answers, though still not enough; being well-briefed only gets you a good answer, not a reliable or nuanced one.
      
      
   3. The harness: It needed a frame.
      We quickly learned AI models could provide intelligence, but intelligence alone can’t do the work. It needs infrastructure around it that allows it to operate in the environment. We determined that AI models need tools, access, memory and state. AI needs to know what systems it can touch; how it can take an action, see what happened, decide what to do next and understand what happens when something fails.
      
      This was important for the people side of work too. Two organizations could use exactly the same underlying model and get very different results depending on what they'd built around that model: the tools, access, context, integrations and orchestration that turned capability into action.
      
      
   4. The loop: Work is a rhythm, not a one-off.
      Real work isn't a single request and a single answer. It's do, look, correct, do again, until it's right. That means someone has to decide what "right" is, when to stop and how to iterate. Anything that cycles without a way of checking itself doesn't fail loudly; it strays, quietly and confidently. This turns out to be just as true for teams as for the technology architecture.
      
      
   5. The graph: None of it happens alone.
      Work is lots of cycles joined together, passing tasks and information between each other, waiting on each other. In a joined-up flow, the value and the risk both sit in the joins, not just in the individual steps. You can improve every single step and make the process and results worse. Many organizations are proving this.
      
      

the one movement behind all 5 shifts

With each shift the solutions expanded outward; from the tool, to the information around it, to the rules around that, to the rhythm, to the whole flow.

And in the same movement, the human job moved from doing the work to designing and overseeing the work.

what the rest of us are doing

Jayney Howson, chief learning officer for ServiceNow, shares insights on how the business operations tech leader is approaching AI transformation within its business. She explains, “The question we need to ask is: Are we being good scientists? Like Lovelace looking at the jacquard loom and imagining the computer, we need to sense the world and wonder 'what if?' Because as AI absorbs more of the technical work, what's left is what makes us uniquely human: adaptive skills, critical thinking, the ability to read a room and lead when a plan breaks. These capabilities — how we think, behave and connect — are the capabilities AI can't replicate."

The challenge is clear: Human talent will always be one step behind the technology, not out of laziness, but out of mechanics. Capability frameworks, job architectures and learning programs are typically built on last year's evidence and then take eighteen months to land. So by the time a program arrives, the problem has already moved on.

This is what that looks like in practice:

• • Running big training pushes on how to prompt at almost exactly the same moment when the technical world stops believing that prompt would generate value
  • Ordering information — necessary, but a step late — rather than investing in people who can confidently say what good looks like
  • Never really developing the frame for humans: building careful boundaries and checks for the technology, then giving people a powerful tool with a limited stated quality bar, no clarity on what they are allowed to decide and no idea when to escalate 
  • Treating checking as a personal habit, rather than a designed part of the work
  • Ultimately, measuring the step long after the value had shifted elsewhere
    
    

two consequences of this approach

Many companies are building individual capability against a system problem, and adding governance and top-down priorities. They are teaching an enormous number of people to be personally faster inside processes nobody has redesigned. The gain shows up in the task and disappears at the handover. 

This is the oldest failure pattern in work design, and many companies and their leaders are walking straight into it, again. This approach also elevates efficiency as the pinnacle and cost savings as the goal, rather than as parts of the solution. 

That means punishing people who are getting it right; the people who are checking immediately, everywhere, on their own. They reread things. They rewrite what looks fine but isn't. They sense-check with a colleague before the work product goes out. That is quality control, self-organized and completely unfunded.

Because nobody is naming it, it shows up in the data as slowness. In some places it is actively managed out. Executing at pace is seen as what good looks like. AI is highly convincing. When people are overwhelmed, they will stop doing the checking — especially when being measured against the old metrics.

5 imperatives for building systems for people, with people

Because AI use is moving through these shifts, people need matching capabilities, not technical ones. Following are five considerations that will help you fulfill both the needs of technology and people when designing the systems.

• • Intent: Everyone mistakes this for a technology skill, but it’s not. Most poor output is a faithful delivery of an unclear ask, without considered outcomes and guiding human principles.
  • Judgement: Everyone has the same tools. What separates people is knowing which details matter most for the specific client, case and decision. The tacit knowledge in people's heads is genuinely valuable; but only when it can be said out loud. 
  • Standards: Setting a standard isn't like setting a restriction; boundaries can’t be treated as a compliance job rather than a design job. They’re what make speed safe. Standards cannot be governance of the mighty few, but a frame for all; alignment to the big picture in action.
  • Checking: This is the one area where both people and technology need exactly the same thing for exactly the same reason. 
  • Visibility: In an interconnected workflow, information isn't the limiting factor. The true challenge lies in reconstructing the underlying reasoning — the why — while maintaining clarity and confidence in the entire process. This is what generates trust, and it is how trust becomes part of the infrastructure.
    
    

Technology gets better by moving intelligence out of the tool and into the system around it. But when it comes to people, judgement must move in the opposite direction: out of the system and back to humans. As more of the specifiable work gets absorbed, what's left for people is precisely what a process can't hold: intent, judgement, standards, checking, trust.

Howson cautions, "In Spanish, confidence and trust are the same word — confianza. If we don't understand the system, we don't have confidence in the answer, and trust degrades. And trust is the greatest human currency."

bricks and mortar

An organization looks like a structure of bricks: roles, processes, systems, targets, reporting lines. That's what the org chart draws and what the operating model describes.

But the bricks aren't the only thing holding the building up. The mortar does too, but it gets left out of the org chart drawing.

The mortar is all the connective work that nobody is assigned:

• • Knowing who to actually ask, as opposed to who owns a project or task
  • Absorbing ambiguity so it doesn't reach the customer
  • Translating between two teams who use the same words differently
  • Quietly covering the gap where two processes don't quite meet
  • The corridor conversation that stops the bad decision
  • Being willing to say "this looks wrong" to someone more senior
  • Knowing the way work actually gets done here
    
    

And four things are true about this workplace mortar:

1. 1. It's load-bearing — and invisible — in every model. It shows up nowhere in the process map, the job description or the productivity number. It only shows up when it's gone.
   2. It fails quietly, then all at once. It degrades for months with no visible effect, and then the building moves; usually under pressure. No standard dashboard has a leading indicator for it.
   3. It's made of conditions, not activities. It forms where there's slack, continuity, closeness, safety and credit. You can't order it into existence.
   4. You may not want to specify it. The moment you write it down and assign it, it becomes a brick; a process, a role, a line in a RACI, and it loses the very thing that made it useful: the ability to read the situation and adapt. Specified mortar is more masonry — sometimes useful and other times not.
      
      

Companies don’t lose the mortar deliberately; rather it’s a side effect of decisions that are each perfectly sensible on their own.

Technology can be excellent at replacing bricks, but it also removes the friction that used to create contact between people. It replaces a colleague you'd have asked with a system you can ask; but the colleague is often the factor that makes the next problem solvable.

Most importantly, technology often automates the junior work through which mortar was always formed: asking obvious questions, sitting in on meetings you didn't strictly need to be in, slowly learning the informal map of the place.

A decade of rational efficiency decisions may systematically remove the conditions that mortar needs. Nobody will have intentionally chosen that, but it will be a direct consequence nonetheless.

Howson shares, "Uniformed efficiency to organizational strength is like ivy to mortar — slowly breaking it down, covering the cracks. The trick is to prune it before it takes root. That's what it means to create the right conditions, and it all comes back to trust. Without psychological safety, without leaders who extend trust, none of this works."

should the mortar sit inside the same model as everything else?

No, and it matters. Give the mortar its own model. It should stand on its own, but connect to the rest of the organization at two points: checking and visibility.

The reason isn't neatness. Any model written in the language of systems inherits that language's core assumption: Anything real can be defined, measured and improved. 

The point of mortar is that it's real and undefinable. Put it inside the system model and one of two things will happen, both fatal: It will become a process, or it will get classified as waste and stripped out. This is why it needs a different kind of governance; one without specifications, but conditions.

You can't design mortar. You can only mix it, and then leave it alone long enough to set.

These conditions should be in your mix:

1. 1. Slack and unallocated time: Mortar forms in the margins. A fully loaded organization is a dry one.
   2. Continuity: It's specific to relationships, and it resets when you reorganize. Every restructure is a mortar event, and almost none are costed as one.
   3. Closeness: Shared context and repeated, low-stakes contact hold it all together. Closeness is not necessarily physical, nor is it accidental.
   4. Safety: Unless people can safely say "this looks wrong," the checking will never happen, and you’ll find out something is wrong far too late.
   5. Credit: Mortar work is often invisible in the reward system, so the moment you measure people tightly, sensible people stop doing it. This is the fastest and most common way to destroy it.

what you should do next

“Humans need to decide: Do we want to be the authors of this story, or a footnote? A level of self-awareness that we're one step behind gives us a chance to stay in the lead. In practice this looks like: redesigned learning that is embedded, continuous and in the flow of work; shifting the readiness conversation from course completions to competency; protecting psychological safety and building trust; design thinking that starts with the human, not the system; and a focus on creating the conditions for people to develop the skills no agent can replicate," says Howson.

Many companies are on their journey to this stage of human-AI collaboration at work, while others aren’t sure how to move forward. Here are six measures you can take now to design systems that work and help prevent the erosion of the mortar at your business:

1. 1. Assume anything you build for people is one step behind.
      Build it for the next shift, not the one you're in. If you're teaching people how to ask, you're really teaching intent. Say so, and skip ahead deliberately.
   2. Redesign the work before you automate it.
      Consider outcomes first, then tasks, then skills — in that order, every time. The organizations that automate first and redesign later won’t get half the benefit. They’ll mostly get rework at the handovers.
   3. Name the checking and staff it.
      It's happening in your organization right now, invisibly, at your people's expense. Make it a step, a standard, a resourced part of the work. Don’t let unnamed quality control read as slowness and get managed out.
   4. Ask three sets of questions.
      What can be accepted without review? What must be checked, why and by whom? What must be escalated? That's the frame for humans. 
   5. Measure the joins, not the steps.
      A gain in one step that creates rework in the next isn't a gain, and your current measures probably can't tell the difference.
   6. Protect the conditions that mortar needs.
      Slack, continuity, closeness, safety, credit and treat every reorganization as a real cost to be priced rather than a free structural change. Keep some deliberately inefficient junior work; what you automate this year is the mortar you won't have in ten.
      
      

does your system pass the tests?

There are two tests that can help determine whether your work system is successful, and most organizations only run the first one.

1. 1. Does it perform better? 
   2. Is the work better to be in?

You can pass the first and fail the second for quite a long time before anyone notices. That's the whole risk.

Companies have spent a decade getting very good at designing the bricks. But they can’t ignore what holds them together — even if it means admitting you can't specify it, and having the discipline to protect it anyway.