How to coach the system

I was running a workflow mapping session with a product team at a fast-growing e-commerce business. We’d reached the point where an idea becomes something the engineers can build, and I asked what they needed at that stage. One of the developers shrugged and said, “Just the letters and assets from content design.”

The content designers in the room went very quiet.

Letters and assets. Months of research, careful thinking about tone and clarity and decisions about what customers actually needed to read, all squashed into four words. Nobody meant it unkindly, and that was the problem. It had become such a normal way of talking that nobody noticed what it said, but the designers had been feeling it for a long time. Handovers were getting tense. Messages were going unanswered. There was a growing sense that the non-technical people on the team were only there to decorate the real work.

None of that was on anyone’s list of workflow problems. It only came out because we asked people to describe the work in their own words.

Coaching a person is simple. Coaching a system is not.

One-to-one coaching isn’t easy, but its shape is clear. There’s one relationship, a coaching agreement you’ve both signed up to, and time to build trust.

When you coach a system, you’re working with everything at once: the relationships between the people who run it, the behaviours of the individuals inside it and the health of the system itself. That last one means the processes, tools and habits that either let work flow or subtly trip it up.

The hardest bit is working out which of those you’re actually looking at. When something breaks down, the cause might be the system, where a step is missing or a handover lands in the wrong place. It might be an individual, who doesn’t yet have the skills or has fallen into a habit that causes friction. Or it might be a relationship, where two groups have stopped trusting each other and are working around the problem. “Letters and assets” looked like a process gap. It was really a relationship issue wearing a process costume.

Get the diagnosis wrong and you’ll fix the wrong thing very efficiently.

Start by mapping how work really moves

When a team already has a workflow and wants to improve it rather than tear it up, I still reach for a technique I borrowed from service design. Designers map a customer’s journey, spot the pain points and decide where effort will make the biggest difference. You can do exactly the same with the journey a piece of work takes through a team.

Use a definition of “work” loose enough to cover an idea from the team, a request from a stakeholder, a commercial opportunity and a bit of tech debt. Then follow it from the moment it appears to the moment it goes live, and capture every state it passes through. Use the names the people doing the work actually use, not the names in the process document. That’s where the gold is, as our content designers found out.

Then add the people. Note who does each step, who needs to know about it, and where the conversation about it really happens. That might be a meeting, a Slack thread or a document nobody has opened since March. Once it’s all on the wall, ask the group what’s missing. Are we light on testing? Are we skipping research and taking on more risk than we realise? Are the right people in the room when an idea turns into something buildable? Are we really using AI in the right way?

This is tactical work. It won’t fix a broken strategy. But it’s brilliant for finding out why a perfectly reasonable process isn’t behaving the way everyone thinks it is.

Making it safe to say the real thing

Here’s the catch. A lot of system coaching happens in workshops, and workshops are where people are most likely to keep the real story to themselves. Nobody wants to be the one who says “I feel disrespected” in front of their team lead.

So the facilitation matters as much as the map. Mapping the work rather than the people helps, because it gives everyone something neutral to point at. Talking in small groups before the whole room helps too. So does a facilitator who notices the quiet moment after a throwaway comment and gently asks about it. That pause after “letters and assets” was the most useful thirty seconds of the whole session.

Not every problem is worth the noise

Once you’ve got a wall full of opportunities, you’ll be tempted to fix everything. Please don’t.

Every change to how people work creates noise: meetings, new habits, the effort of remembering the new way. That noise has to earn its place. It should make the end product more valuable, make the flow more efficient or make the team happier. Ideally the last one, because happy teams tend to deliver the other two on their own.

I’m working with a national charity at the moment that’s midway through a big transformation. Some of the team live entirely in Microsoft, others are devoted to their Google Docs, and the organisation has secure accounts for both. On paper it’s untidy, and surely we should pick one? But asking people to give up the tools they’re most comfortable with, while almost everything else about their work is changing, would have created a lot of noise for not much gain. So we’ve left it. It’ll be worth tidying up later, once the bigger changes have settled. Right now it would just be one more thing.

Timing matters too. I avoid launching big workflow changes straight after something major like quarterly planning, when people are already full. Smaller, quieter tweaks can usually happen straight away.

What you end up with

By the end, you should have a short, prioritised set of improvements to work through over the next few months. Because the team helped build that plan, they actually want it to happen.

For the e-commerce team, the “letters and assets” moment changed more than anyone expected. Once it was out in the open, we could deal with the real issue. Designers started sharing more of the thinking behind their decisions and we moved technical input much earlier in the workflow. Engineers were now part of the conversation while designs were still taking shape, so feasibility and cost questions got ironed out before anything was locked in. Less work bounced back and forth, and lead times came down. The team’s health check scores went up too, which mattered just as much. Respect turns out to be pretty good for flow.

That’s why it’s worth putting a few simple measures in place before you start. Pick something about how fast work moves and something about how the team feels. Then you can show the difference rather than just sense it.

Sometimes you’ll walk away with something more valuable than a better workflow. You’ll have found the conversation a team needed to have and didn’t know how to start.

If your delivery feels stuck and you can’t quite tell whether it’s the process, the people or something in between, the Delivery Diagnostic is a good place to start working it out.