Shaping teams so the work can actually move

One of the more useful things I took from the Level 7 programme was a way of describing something I'd already half noticed. A lot of customer problems are created upstream, in operations, technology, policy or ownership. The interface is simply where the customer eventually encounters them.

That changed how I diagnose things. When a journey is broken, my first question is usually not what the screen should look like. It's which team owns the decision that produced this, and whether they know it landed here.

It's a slower way to work. It also tends to stop you redesigning the same page for the third year running.

At Selfridges I grew UX from three designers to more than twenty specialists across UX, Research, Digital Design and Content. That didn't happen in one restructure. It happened in a series of fairly small moves, each one justified by work that was already visible and already mattering to someone outside the team.

I learned to be honest about the sequencing. Adding people before there's a clear demand for their craft usually creates frustration on both sides. The designer feels underused, and the business quietly concludes the role wasn't needed.

The research function was the clearest example. I established it from nothing, and it only became permanent once other teams started asking for it by name.

Introducing product and agile ways of working was probably the hardest structural change I've led. Not because people disagreed with it in principle, but because it asked several functions to change their planning rhythm at the same time.

The design system work had a similar shape. Rolling it out across Product, Technology and Creative was less a technical exercise than a negotiation about who decides what a component is allowed to do.

I've come to think the interesting part of any operating model is the handover points. That's where things get dropped, and it's rarely written down anywhere.

I tend to connect information quite quickly, and earlier in my career I underestimated what that costs other people. I'd arrive at a structure that made sense to me and then be surprised that the reasoning didn't travel with it.

Now I involve people earlier and let teams participate in forming the answer. It takes longer and it's often messier, but the change usually holds.

The programme made the same point in a blunter way. Creating a new operating model on a slide is easy. Getting a large organisation to actually work differently is much harder, and I don't think I'd fully respected that gap before.