Building Capability
Chapter 10: Leadership Is Direction, Not Control
Before you read — by the end of this chapter you will understand:
- Why leadership is the single biggest differentiator between organisations that build long-term capability and those that don’t
- The perfection trap and its opposite - why both afraid-to-ship and ship-before-it’s-ready destroy value in different ways
- The political football trap and its opposite - why paralysis through consensus is just as damaging as politics
- The right balance between leadership direction and team autonomy
- Why direction is leadership’s job and control of the nuance is the team’s job
When I look back across the organisations I’ve worked with, the ones that built something genuinely lasting versus the ones that stalled, spun, or quietly gave up, the differentiating factor is almost never the technology.
It’s not the quality of the team. It’s not the budget. It’s not even the quality of the brief they gave us.
It’s leadership.
Specifically: the mindset and behaviour of the person or people at the top who own the vision for where the organisation is going. Not whether they’re smart, they usually are. Not whether they’re committed, they almost always think they are. But whether their instincts around control, risk, and perfection help or hinder the work.
This is a hard chapter to write, because the people I’m describing are not difficult or unreasonable people. They’re often exceptionally capable people. But they have instincts that were built for a different kind of work, and those instincts, in a capability build, create friction that can derail even the most well-designed initiative.
The Perfection Trap
The single most common leadership failure mode I encounter is what I’d call the perfection trap.
It works like this. The organisation sets out to build a new capability. The first release is designed. The development progresses. And then, as go-live approaches, the list of things that need to be “fixed before we launch” starts to grow.
Some of these are legitimate. There are things that genuinely have to work before a system goes live. But many of them are not legitimate in that sense. They’re preferences. Refinements. Things that would be better if they were there, but whose absence would not prevent the system from delivering real value.
And yet the launch slips. Then slips again. Then the scope expands to incorporate the new requests. Then those requests generate further refinements. Then someone notices something that was always true of the original design but only became visible now that everything is almost done.
I’ve watched organisations spend more time in the pre-launch phase than they spent in the entire build. I’ve watched release dates missed so many times that the team stops taking the dates seriously. I’ve watched the commercial case for the investment erode because the value that was supposed to be delivered in month four is still not delivered in month fourteen.
And underneath all of it, when you dig into what’s really happening, you find the same thing: someone is afraid to ship.
Why People Are Afraid to Ship
Fear of shipping is rarely irrational. It usually has roots in real experience.
Sometimes it comes from a previous technology failure: a launch that went badly, a system that turned out not to work as promised, a public-facing problem that was embarrassing or costly. That experience creates a reasonable desire to not repeat it.
Sometimes it comes from perfectionism that’s been professionally rewarded elsewhere. In many domains, the person who sweats the details and never lets something go out the door below a certain standard is the person who gets promoted. That instinct, applied to a capability build, produces endless iteration and no deployment.
And sometimes it comes from something harder to articulate: a discomfort with being judged on partial work. If the system launches and it’s not perfect, someone might criticise it. The only protection against that criticism is to keep it in development, where no one can see it yet.
The problem is that a system in development creates no value. A system in production, even an imperfect one, creates real value from day one and generates the feedback that makes it better.
There is no such thing as a perfect system. There are systems that are good enough to deliver value, and then progressively improved. The only path to a great system runs through an imperfect one first.
The Opposite Problem: Shipping Before It’s Ready
The perfection trap has an equal and opposite failure mode that doesn’t get talked about nearly as often, because it feels like courage rather than a mistake.
Some leaders overcorrect. Burned by previous projects that spent eighteen months in development and never delivered anything, or convinced that speed is always the right answer, they push for deployment before the system is genuinely ready. Not ready in a perfectionist sense, but ready in the sense of being able to deliver real value without creating real damage.
A half-built system in production is not a proof of value. It’s a first impression. And first impressions don’t get revised easily.
Users who encounter a system that doesn’t work as promised don’t wait patiently for the next release. They form a view: that the system isn’t reliable, that the investment wasn’t worth it, that the old way was better. That view hardens quickly. The trust that should have been built through a well-timed launch gets spent instead on managing the fallout from a premature one.
The team learns something too. When shipping fast is rewarded regardless of what gets shipped, the team learns to associate launch with anxiety rather than progress. The discipline of getting something genuinely right before it goes out the door erodes.
The right answer is not “ship everything immediately” and it’s not “wait until it’s perfect.” It’s “ship when it’s good enough to deliver the value you promised and generate the feedback you need.” That bar is lower than perfection and higher than “it mostly works.”
Knowing where that bar sits, and holding it consistently, is a leadership call.
Discovery Is Part of the Cycle
Here is the mindset shift that the best leaders I’ve worked with have made, and that the struggling ones haven’t.
They’ve stopped thinking of the first release as the answer and started thinking of it as the beginning of the conversation.
No matter how well you design something, reality will surprise you. Real users will use the system in ways you didn’t anticipate. Real data will reveal patterns you didn’t model. Real processes will interact with the system in ways that weren’t visible in testing.
That is not failure. That is discovery. And discovery is genuinely valuable. It’s how you learn what the system actually needs to do, as opposed to what you theorised it should do.
The leaders who’ve internalised this are not cavalier about quality. They still want the system to work. But they’re not frightened by the first release being the beginning of the real learning. They ship, learn, adjust, improve, and ship again. They move in cycles, not in straight lines.
The leaders who haven’t internalised this treat every discovery post-launch as evidence that the system wasn’t ready, which reinforces the instinct to keep the next release in development longer, which creates more pressure and more fear, which makes the cycle worse.
The experimental mindset is not optional. It’s the price of admission for building genuine capability over time.
The Political Football
There’s a second failure mode I want to name, because it’s common and it’s destructive and it almost never gets talked about openly.
It’s the political football.
In organisations where different departments or individuals are in competition, for resources, for visibility, for influence, a technology project becomes a kind of proxy battlefield. Success or failure is attributed not to the work, but to the people behind it. A problem with the system becomes ammunition. A delay becomes evidence of incompetence or misaligned priorities. A feature that works for one department but creates friction for another becomes a grievance.
The result is that any challenge in the capability build, and there will always be challenges, gets amplified into something much larger and more charged than it needs to be.
I’ve watched this derail projects that were technically sound and commercially justified. Not because anything went fundamentally wrong, but because the environment around the project became so politically loaded that it couldn’t survive ordinary imperfection.
Tool World is a good example of what happens when leadership gets this right. The owner of a wholesale jewellery business supplying major retailers like Dunklings recognised that his quoting process was a dangerous single point of failure.
Only key people could handle the complex pricing calculations, which meant that any absence created a service crisis. Rather than treating that as an individual performance problem or a reason to protect the status quo, leadership framed it clearly: this is a structural issue and we’re going to fix it together.
The result was a quoting system that let any staff member handle customer inquiries confidently, turning a vulnerability into a competitive advantage. That outcome was only possible because leadership named the problem honestly and gave people the safety to help solve it.
The antidote to the political football is leadership behaviour, not process design. Leaders who model the right response to problems, “that’s useful to know, what do we do about it?” rather than “whose fault is this?”, create an environment where the work can survive reality.
Leaders who allow problems to become ammunition, or who participate in the attribution of blame, poison the environment for the entire project. The team stops taking risks because risks become career exposure. Users stop giving honest feedback because honest feedback becomes weaponised. The system that gets built is the system that can survive the political environment, not the system that the organisation actually needs.
This is a leadership responsibility. It can’t be solved at any other level.
The Paralysis Trap
The political football has its own counterweight, and it’s subtler, because it looks like good management.
Some leaders are so conflict-averse that they never make a hard call. Every contentious decision becomes a committee. Every department with a stake in the outcome gets a vote. The process is consultative to the point of paralysis, and the capability build drifts. Not because of politics, but because of the absence of any decisive direction.
Harmony isn’t leadership. Consensus isn’t direction.
In a capability build, there will always be moments where one department’s needs conflict with another’s. Where the right architectural decision creates short-term friction for a team that’s already stretched. Where the priority that serves the business most doesn’t serve every department equally. Those moments require a leader who can hear all the views and then make the call: clearly, fairly, and without endlessly revisiting it.
The leader who can’t do that, or won’t, creates a different kind of damage to the political football. Instead of a battlefield, they create a swamp. Everything slows down. Nothing is ever fully decided. The team learns to work around the absence of direction rather than within it.
There are times to build consensus. And there are times to lead. Knowing the difference, and being willing to do the harder thing when it’s needed, is what separates leadership from administration.
Handing Over Control of the Nuance
I want to talk about a specific leadership behaviour that I’ve come to see as one of the clearest differentiators between leaders who build great capability and leaders who don’t.
It’s the willingness to hand over control of the nuance to the people closest to the problem.
In almost every capability build, there are decisions that require deep knowledge of the day-to-day reality of the work. Decisions about edge cases, about exception handling, about the specific way a process works in practice as opposed to in theory. These decisions can’t be made well from an executive desk. They require the knowledge held by the people actually doing the work.
Leaders who understand this create space for those decisions to be made at the right level. They set direction: the outcomes they’re trying to achieve, the constraints they’re operating within, the strategic priorities. Then they trust their teams to make the operational decisions that serve those outcomes.
Leaders who don’t understand this insist on being in the room for every decision. They review every design choice. They have opinions about every feature. And in doing so, they inadvertently override the judgment of the people who know the most about what’s actually needed.
The result is a system that reflects the leader’s mental model of the work rather than the reality of the work. Which is, in almost every case, a poorer system.
Direction is leadership’s job. Control of the nuance is the team’s job. The most effective capability builds happen when those boundaries are respected.
The Structure That Works
I’ve found one structural approach that tends to work well for larger organisations dealing with the tension between central direction and departmental autonomy.
Rather than a single, centralised technology budget controlled by leadership, the organisations that build the most effective long-term capability tend to operate with decentralised department budgets. Each team invests in the capabilities that matter most to them, coordinated by a central leadership budget that manages priorities and integration across departments.
This does several things.
It gives departments genuine ownership of their capability investments. When a team controls their own budget for technology, they’re invested in making sure it delivers. They’re not waiting for someone else to prioritise them; they’re driving the work themselves.
It prevents the bottleneck of a centralised approval process that moves at leadership’s pace rather than the business’s pace.
And it creates accountability at the right level: the department that built the capability is responsible for its adoption and its outcomes.
Leadership’s role becomes coordination. Making sure departments aren’t building things that conflict with each other, ensuring integration points are managed, and directing the priorities that genuinely require a whole-of-business view.
That division of responsibility, departments own their capability and leadership owns the whole-of-business picture, is the structure that produces the best outcomes over time.
What Good Leadership Looks Like Here
I’ll close this chapter with a description of the leadership behaviour I’ve seen at the heart of every genuinely successful capability build I’ve been part of.
The leader is clear on direction and loosens their grip on method. They can articulate where the organisation is going and why, and they trust the people building the capability to figure out how.
They treat problems as information, not ammunition. When something doesn’t work, the response is curiosity and problem-solving, not blame.
They ship early and learn fast. They resist the perfection trap, even when the instinct is strong.
They’re in the work. Not over it or around it, but genuinely engaged: making decisions, challenging assumptions, being challenged in return.
And they see the capability build as an ongoing investment rather than a one-time project. The conversation doesn’t end at go-live. It’s just getting started.
That combination, clarity of direction, looseness on method, experimental mindset, genuine engagement, and a long-term view, is what building capability requires from the people at the top.
Everything else follows from that.
Tool: The Leadership Posture Check
This is a personal tool. It works best if you answer honestly, not as you’d like to be, but as you actually are. Consider asking someone who works closely with you to complete it independently and compare answers.
For each statement, rate yourself from 1 (not like me) to 5 (genuinely strong):
Direction vs. control
- I can clearly articulate where this organisation is going and why, in a way that gives my team genuine direction
- When a decision is made below me, I can let it be, even if I’d have decided differently
- I can ship something that isn’t perfect, as long as it’s good enough to learn from
- I don’t push things out the door before they’re genuinely ready to deliver value
Environment
- In my organisation, a problem with a technology project is more likely to be treated as information than as ammunition
- I make decisions when they need to be made, even when they’re contentious
Investment mindset
- I think about this capability build in years, not projects
- I’m genuinely in the work, not watching from a distance or delegating without engagement
What to do with your scores. Your two or three lowest scores are your watch-outs. For each one, name what that pattern looks like in practice, and what you’ll do differently.
Want to go deeper?
The online version of this tool includes a 360-style version for gathering team feedback on your leadership posture, a guide for building the right governance structure around your capability investment, and a facilitation guide for using this assessment in a leadership team conversation.
Available in the members area at [website]