Designing for autonomy: Building capability that lasts

This is the final post in a series about building design capability that scales.

If you’ve followed along, you’ve been doing diagnostic work: looking at where insights get stuck, where coordination creates friction, whether your teams are shaped for their purpose, and how design’s value becomes visible.

What comes next is different. Not another problem to diagnose, but a question about what you’re building toward, and how to act on what you’ve found as a leader. I’m going to share my personal learnings and reflections that can hopefully help. I don’t want to paint a picture of some perfect world that you must be achieving to be successful. These are things that I have to remind myself to do, sometimes things slip and I have to pick things up again. We’re only human.

These changes reflect how leadership evolves as teams grow and organisations become more mature. The work shifts from doing to enabling, from solving problems yourself to building the conditions for others to solve them. That transition is the focus of this post.

Maturity is a spectrum, not a destination

In the very first post, I used a maturity model to introduce this series. They’re a nice tool that makes the concept of maturity digestible. Maturity models are seductive, they promise a progression, with clear stages you move through, boxes you tick, a destination you arrive at. It’s satisfying to believe that with enough effort, you reach “mature” and stay there.

But capability actually doesn’t work that way. It’s not a state you achieve, it’s more like a condition you maintain. The functions that make design effective all require ongoing attention and evolution. Neglect any of them and they degrade, and as the organisation changes around you, priorities shift, people leave, and what worked six months ago stops working.

This is a more honest view of what the work involves. It may sound pessimistic that the work is never done, but it’s also what makes it rewarding. You’re not ticking boxes on a model, you’re nurturing a team and watching them grow into their potential. That’s a fundamentally different kind of work.

It also doesn’t have to be a constant battle. Early on, holding a capability together takes constant effort because the system is weak: you’re compensating for missing functions, filling gaps yourself, firefighting. As the system strengthens, the effort changes. The firefighting gives way to maintenance, the compensation gives way to adjustment. The work doesn’t disappear, but it becomes more sustainable.

The question isn’t “when will we be mature?” It’s “is the system getting stronger or weaker, and is it getting easier to maintain?”

The leader’s role shifts

Early in building a design capability, leadership is hands-on. You’re in the work: shaping projects, making decisions, solving problems directly. The team looks to you because you’re often the most experienced person in the room, and because the system isn’t strong enough yet to function without you.

This is necessary at first, but it doesn’t scale, and that shouldn’t be the goal.

As the capability matures, what the team needs from you changes. They need you to set direction, build the conditions for good work, and create clarity so others can act. This is one of the hardest transitions in design leadership, especially for people who built their credibility through craft. You got here because you were good at the work, and stepping back from it can feel like losing the thing that made you valuable.

I’ve seen many people struggle with this, and I’ve faced it myself. As anyone who’s worked with me knows, I love to get stuck in and try to solve problems… The shift isn’t just practical, it’s emotional. I found myself holding on to things I should have handed over, not because the team couldn’t handle them, but because I felt more confident in doing the work than in handing it over to someone else. “Oh, I can just quickly do this myself rather than taking time getting someone up to speed and asking them to do it”. These things all build up. Recognising that pattern was the first step. The second was trusting that the team I’d built was ready, even when it felt uncomfortable.

This doesn’t mean you should never jump into practical, hands-on work. In the current state of the design industry, leaders are often hands on, but you should be able to be selective and choose where this is needed and where your team can handle things on their own.

The test is simple: what happens when you’re not there? If the team stalls, the system is too dependent on you. If they continue, the capability is starting to mature.

What fills the space you’ve created is the focus of the rest of this post. The shift frees you to work on the system itself, which is where your attention is needed most.

The purpose of all of this

Stafford Beer, whose Viable System Model has been the scaffolding behind this series, had a phrase: “The purpose of a system is what it does.” It’s a diagnostic challenge. Ignore the stated intentions, the strategy decks, the org chart aspirations. Look at what actually happens. That’s what the system is for.

If your design capability produces frustrated people, duplicated effort, and insights that never reach decisions, then that is what the system produced as it is designed today, regardless of what you intended.

So, what should the system produce? Two things, and they’re inseparable. Better work , and happier, healthier people doing it. These aren’t competing priorities where you optimise for one and hope the other follows. A system that takes in motivated, skilled designers and produces decent outcomes but burns through them in the process is treating people like fuel. That’s not sustainable, and it’s not what any of us set out to build. Also, a team where people feel comfortable but aren’t creating meaningful value isn’t viable either. Both need to be true at the same time.

When the system is struggling, it often shows up in people first. Exhaustion that doesn’t match the workload. Talented people quietly updating their CVs. A growing sense that the work has become harder than it should be. These are signals about the system, not just about individual resilience. They tell you where things are failing even when the outputs still look acceptable.

The reverse is true too. When people have clarity about why their work matters, when coordination enables rather than drains, when effort goes into the work itself rather than fighting the friction around it, that tells you the system is starting to function. You can feel the difference before you can measure it.

As designers, we don’t leave user experiences to chance. We shape them deliberately, and the system your team operates within deserves the same rigour. If the purpose of a system is what it does, then changing what it does requires intentional design, not just hoping that things will improve on their own. Diagnose where it’s falling short, then change the conditions.

If your team isn’t thriving, the system isn’t working. That’s not a soft metric, it’s the most honest one you have.

Diagnose before you act

When you see problems across the system, the instinct is to try fixing everything at once. Coordination is broken, so you introduce new rituals. Teams are misaligned, so you restructure. Standards are inconsistent, so you document everything.

Each intervention makes sense on its own, but tackling them together becomes overwhelming quickly. Change fatigue sets in, people start to see improvement efforts as just more friction, and nothing gets the sustained focus it needs to actually work.

The alternative is to diagnose before you act. Get clear on which function is weakest in your context, and be honest about it. It’s tempting to focus on the problems you’re best equipped to solve, or the ones that will be most visible to leadership, but the highest-impact work is usually wherever the pressure is felt most. The diagnostic questions from earlier posts can help here. Where are insights getting stuck? What’s exhausting your people? Are teams shaped for their purpose? Is design’s value visible in ways that matter?

But knowing where the problem is isn’t enough. You also need to understand what kind of problem it is. Not all issues are the same, and they don’t all respond to the same kind of intervention. Donella Meadows, a systems thinker whose work complements Beer’s, identified that interventions in any system operate at different depths. I’m using a simplified version of her thinking here, but her original essay is well worth reading if you want the full picture.

Working from the surface inward:

Parameters are the most tangible things you can adjust. Meeting cadences, templates, tools, how often you run a particular ritual. These are easy to change, and sometimes that’s all you need. But if the underlying structure is wrong, tweaking parameters won’t fix it. You’ll just keep adjusting the same things.
Feedbacks are about whether the right information is reaching the right people at the right time. Are your teams hearing how their work lands? Does leadership see design’s contribution in ways that are meaningful to them? Missing or broken feedback loops are one of the most common causes of system problems, and restoring them is often simpler than people expect.
Design refers to the structures and rules that shape how work happens. Team configurations, decision-making authority, how design connects to the rest of the organisation. Structural changes take more effort and more political capital, but their effects are durable. Much of what we covered in earlier posts about team shape and coordination lives here.
Intent is the deepest level. What does your organisation believe design is for? What goals is your capability oriented toward? If leadership sees design as a production function that makes things look good, no amount of structural change will give you strategic influence. This is the hardest work because you’re trying to shift beliefs, not processes. But it’s where the most fundamental change happens.

The instinct is often to start at the top, because parameters are the easiest to change. Sometimes that’s genuinely the right move, but if you find yourself adjusting the same parameters repeatedly without lasting improvement, that’s a signal that the problem sits deeper. The diagnosis isn’t just “what’s broken?” but “at what level is it broken?”

Start with where the pressure is greatest, then consider what depth of change that problem actually needs.

Build capability into the system, not into yourself

There’s a version of strong leadership where you become the person everyone depends on. You hold the context, unblock the problems, maintain the relationships. It feels like strength.

It really isn’t.

If the strength of the capability lives in and depends on you, it’s limited to what you can personally sustain. Anything that depends on one person is one departure away from collapse. Resilience isn’t about how much you can personally hold, it’s about how much the system can absorb without you holding it.

The diagnostic work tells you where the system is weak and what depth of change is needed. The question now is how to make those changes stick in the system rather than in you. But that doesn’t mean stepping away from everything equally. Some work should function without you. Other work genuinely benefits from your ongoing attention. The skill is knowing which is which.

Start with the shallowest level: operational knowledge and parameters. If your processes, standards, and ways of working live in your head or in scattered conversations, they’re not really part of the system yet. Documented playbooks, shared onboarding materials, clear descriptions of how things work and why. None of this is glamorous, but it’s the difference between a capability that can absorb new people and one that stumbles when someone leaves. This isn’t bureaucracy for its own sake. It’s about creating enough shared understanding that people can act without needing to ask you first. Your goal here is to make yourself unnecessary. If you’re still the person people come to for “how do we do this?”, the system hasn’t absorbed it yet.

The same applies to feedback loops. If leadership only hears about design’s impact because you personally present it, that’s a vulnerability. If your teams only understand how their work landed because you relay it back to them, that’s another. Building showcase rituals, reporting structures, and review processes that function without you in the room means the system keeps learning even when you’re not there to facilitate it. These are flows that should sustain themselves. Every one you build is time and attention you get back.

Structural changes sit deeper and need more of your involvement to set up, but the goal is still self-sufficiency once they’re in place. Can your teams make good decisions without escalating to you? Do they have enough clarity about direction and enough authority to act within it? This is where the investment in team shape and coordination from earlier in the series pays off. Well-configured teams with clear purposes and manageable cognitive load don’t need constant oversight. Poorly configured ones will always pull you back in, no matter how much you try to step away. You’ll do the design work to get these structures right, but they shouldn’t need you to operate day to day.

The deepest level is different. The organisation’s understanding of what design is for, the case being made at the leadership table, the connection between design strategy and business outcomes. This is where leadership naturally sits at maturity, and it’s not something you hand off in the same way. This work genuinely benefits from your experience and your relationships. The shift here isn’t about stepping away, it’s about making sure you’re not the only voice. Bring others into those conversations. Make value visible through evidence rather than just your personal persuasion. Build enough shared understanding that the argument doesn’t collapse if you’re not in the room. You’ll keep doing this work. The goal is that the organisation’s belief in design doesn’t depend entirely on your presence to sustain it.

This is what fills the space you create by letting go of the shallower work. Less time spent relaying information, maintaining processes, and unblocking day-to-day decisions. More time spent on the strategic and relational work where your experience matters most. The capability gets stronger because the system handles what it should, and you’re free to focus where you can add the most value.

Look across your team with the same lens. Where does critical knowledge live in one person’s head? Where would a departure leave a gap no one else could fill? These vulnerabilities aren’t just about you. They exist at every level, and part of your role is dispersing them before they become crises.

If you’ve read this far, you’ve been asked to think about your capability as a system, to diagnose where it’s struggling, and to consider what kind of change it actually needs. That’s a lot to sit with. None of it is simple, and none of it happens quickly.

The work of building capability isn’t glamorous. Much of it is invisible: clearing obstacles, creating clarity, holding the space for others to do their best work. You won’t get credit for most of it. The credit goes to the team, to the work they produce, to the outcomes they enable. That’s as it should be.

What you get is something harder to measure: a capability that doesn’t depend on you to hold it together, a team that can absorb change and keep moving. People doing work that matters, and knowing that it does.

You don’t arrive at this. You tend to it, and the tending is the work.

If any of this has resonated, or if you’re navigating these transitions in your own context, I’d genuinely like to hear from you. The work of building capability can be challenging and lonely, but it doesn’t have to be.