3 The Hierarchy of Leverage
This chapter is currently in draft form. It is currently undergoing active authoring.
Political capital is your power to drive change. It’s the currency of transformation, the credibility that opens doors, the trust that makes people listen. But the hefty balance in your account won’t matter if you don’t deploy it effectively. Money doesn’t work for you if you leave it in the bank.
This is where the hierarchy of leverage comes in: your investment strategy for political capital. You can spend your influence on countless initiatives, but some investments yield exponentially greater returns. Some changes ripple through organizations like stones dropped in still water. Others barely register.
The hierarchy of leverage provides a mental framework for deploying political capital with maximum impact. This isn’t a rigid formula. Remember, this book is called The Dao of Delivery, not The Laws of Delivery. You can’t reduce this to a checklist or extract simple rubrics. If that’s what you are looking for, you are reading the wrong book and you may be in the wrong role. This framework is a lens for examining problems and a structure for thinking about your role as a delivery leader.
Every organization operates through four fundamental levers of change: strategy, structure, people, and process. They’re not equal, don’t operate in isolation, and certainly don’t respond to uniform approaches across contexts. The art of leadership lies in knowing which lever to pull, when to pull it, and how much force to apply.
This hierarchy isn’t about following rules. It’s about developing judgment.
3.1 The Inverted Pyramid of Leverage
The four levers exist in descending order of impact. Strategy commands the highest impact, followed by structure, then people, then process.
I’m ranking by leverage, not importance. Every lever is important, but the higher levers are more powerful than the lower ones. Unfortunately, we tend to play at the lowest lever: process. We choose it because it’s easy. Process changes are safe. No one loses their job. No hard conversations. No teams get ripped apart. We play at the process level because it’s easy. It’s also the least impactful place to spend our attention.
Time allocation will vary by context. Sometimes structural issues demand focus, other times people problems require immediate attention. But consistent engagement across all four levers is non-negotiable.
You can’t ignore any lever completely. They must be worked simultaneously because they affect each other in complex ways.
Problems in higher-level levers often manifest as symptoms in lower-level areas. Take structural misalignment. Two teams with different priorities, success metrics, and reporting lines who must collaborate. The dysfunction often presents as interpersonal conflict. Team members badmouth each other. That sounds like a people problem. Your knee-jerk reaction is to coach those people to treat each other better, or maybe even remove the worst offenders.
Wrong diagnosis. This is a structure problem masquerading as a people problem. Fix the structure problem and the people problem magically disappears. As your first step you must distinguish between where problems originate and where symptoms appear.
Hierarchy matters because it’s a diagnostic framework, not just prioritization. When you see dysfunction, look up the hierarchy first. The real problem usually sits one or two levels higher than where it’s presenting.
3.1.1 Strategy: The Decision-Making Razor
Strategy sits at the apex of the leverage hierarchy because it does something no other lever can: it enables your organization to make decisions in your absence. Strategy is a razor. It helps you and your org “shave away” unnecessary assumptions, explanations, or options. Think of it as a mental tool for simplifying reasoning.
I’ve walked into too many organizations where leadership claimed to have strategy but couldn’t articulate it when pressed or worse, was a wet towel of a useless strategy like “Be good” or “Hire smart people”. I am over simplifying, of course, but you get the point. These feel-good mantras are worse than useless. They are a security blanket in a foxhole. They make you feel better, but they are not going to stop bullets.
Consider the CTO who tells me their strategy is “technical excellence.” What does that mean when the sales team demands a feature that requires cutting corners? How does “technical excellence” help an engineer choose between refactoring legacy code and building new capabilities? It doesn’t. It’s a platitude masquerading as strategy.
That is the kind of strategy we see most often. So those of us in the crucible of technology organizations have become dismissive of strategy. We dismiss it as a waste of time. We dismiss it as a distraction. We dismiss it as a luxury. That’s a mistake. It’s like dismissing the effectiveness of a knife because you keep trying to cut with the handle.
Strategy commands the apex of the leverage hierarchy precisely because, as Alfred Chandler showed sixty years ago, misalignment at the strategic level cascades through everything downstream (Chandler, 1962). When strategy fails, structure follows that failure.
A strategy that doesn’t guide these trade-offs isn’t a strategy. It’s a security blanket. This is what Rumelt means by diagnosis, focus, and coherent action (Rumelt, 2011): sharp decisions that technical leaders can actually use. Do we build or buy? Optimize for velocity or reliability? Invest in automation or accept manual processes? If your strategy can’t answer these questions, you don’t have strategy.
These choices need to constrain and enable each other, forming the decision-making razor your teams need. Martin’s “Playing to Win” cascade captures this: winning aspiration, where to play, how to win, required capabilities, and supporting systems (Martin and Lafley, 2013). Each choice narrows the next, creating the sharp trade-offs that actually guide decisions.
One thing that Martin’s framework doesn’t emphasize enough for technical leaders: your strategy must be instantly articulable by every member of your team. If your team members can’t explain the strategy in two minutes to a new hire, you don’t have strategy.
That would be a champagne problem if you had it. You most likely have a different problem. Your company already has a strategy, and it’s useless.
You can still usually set strategy for your organization without it having an upward effect. Do not try to improve your company’s strategy unless you have a very unique relationship with your CEO and other senior leaders. It’s a waste of political capital that you need for other battles.
Focus downward instead. If the strategy truly is weak, vague, contradictory, or nonexistent, that actually works in your favor. Garbage strategy has no guardrails, which means your technical strategy will align by default. You’re free to create the decision-making razor your teams need without interference.
If your leadership is dismissive of strategy but doesn’t care what you do day-to-day, that can actually be your sweet spot. You can’t be seen focusing on strategy, that will cost you political capital because you’re “focused on the wrong things” as defined by your stakeholders. However, if you just do strategy definition as side-of-desk work and roll it out through your normal communications without making it a big production, you can capture most of the benefits without burning political capital.
If your CEO has strong opinions about strategy and you don’t see the ability to set independent direction because they’ll be invasive, that’s also okay. Don’t waste capital fighting a battle you can’t win. Strategy is highly leveraged and valuable, but it’s not the only lever you can pull.
Success requires recognizing which battles to fight and how to fight them. Save your political capital for the structural and people changes where you have more control and can generate immediate impact. Sometimes the most strategic thing you can do is ignore strategy entirely and focus on the levers you can pull.
Your CTO responds to problems escaping into production by adding gates. Security gates. Delivery gates. Separate release teams that control deployment. Teams have coordination problems and bottlenecks because work stops at these protective barriers.
This indicates your CTO doesn’t understand how to create a strong delivery organization. The question is what you do about it. You need to evaluate whether they can learn or if you need someone else.
Ask your CTO to come up with an organizational plan and the underlying tenets for why they believe that plan will work. Schedule implementation of that plan. Evaluate those tenets. Hopefully they align with unified delivery and minimal organizational distance. Even if they don’t, judge the plan based on how it will streamline decision-making. If they can’t articulate coherent organizational principles or their plan adds more gates instead of removing them, you need a different CTO.
Chandler was right: structure follows strategy. Sharp strategy makes every downstream decision cleaner. Dull strategy makes every cut messier.
3.1.2 Structure: The Architecture of Delivery
Structure is the backbone of delivery providing the rails that work rides from idea to customer value. A structure that allows work to flow freely into production unlocks incredible development velocity, but get it wrong and you create bottlenecks that stifle even the best teams.
Structural changes require significant political capital and cause temporary productivity dips during transitions. When you pay this cost, you want the outcome to be as optimal as it can be. To optimize that outcome, you need clear principles to guide your changes. I will provide those principles here, but realize that my perspective is shaped by years in traditional hierarchical organizations, so I’ll focus on principles that hold true there. If you operate in flat or matrixed structures, adapt these ideas to your context and move with caution.
3.1.2.1 Tenets of Organization Design
Effective structure rests on two principles: team purpose and organizational distance.
3.1.2.1.1 Clear Goals, Hard Boundaries
In most cases, we can divide teams into two types, delivery teams and bureau teams, with each having very specific purposes. Delivery teams own the end-to-end process of shipping customer value. They write code, deploy it, monitor it, and fix it when it breaks. They make product decisions within their domain and are directly accountable for business outcomes. Bureau teams, by contrast, are force multipliers. They build tools, platforms, and shared infrastructure to help delivery teams move faster. For example, internal APIs or monitoring systems.
Bureau teams exist to enable, not control. Left unmanaged, they drift into gatekeeping. If you see that pattern, that’s on you; you lost trust or never built it. Do not add checkpoints. Fix the boundary and build capability inside delivery, including security, testing, and discipline, so the work can flow. See “When Gates Signal Systemic Failure” for the playbook.
3.1.2.1.2 Organizational Distance: Minimize Layers, Maximize Delivery
Organizational distance is the number of reporting layers between people who need to collaborate. The principle is simple it’s the greater the distance, the harder alignment becomes. Banet identified this dynamic in 1976 as a key variable in organizational design (Banet, 1976), and it remains one of the most reliable predictors of coordination problems.
At distance zero, one person can deliver everything. It is clean and fast, though it rarely scales beyond simple tasks. Add a second person and distance begins to grow. If both report to the same manager, the gap is still small; they share alignment and direction. As soon as they sit under different managers or directors, the gap widens. Each additional layer adds interpretation, delay, and drift.
This reflects a deeper truth about organizations. Your manager defines your alignment and goals; their manager defines theirs. Even with clear direction at the top, each layer translates it into local priorities. By the time two people only converge at the CEO, collaboration has become translation across competing goals.
The remedy is unified delivery. Place responsibility for customer value within a single team. Every handoff between product, engineering, and operations introduces translation errors, delays, and diluted accountability. The ideal delivery team owns everything from customer research to production support. When a system fails at 2 a.m., the team that built it is on call. Tight feedback loops drive quality and speed.
3.1.2.3 The Human Cost of Restructuring
Structure changes over time as your team matures. Early constraints loosen as you gain credibility and organizational understanding. You should absolutely take advantage of that evolution. But restructuring has a frequency limit.
Restructuring has a frequency limit. In my experience, that rhythm usually looks like 6–12 months between structural shifts. Any faster, and you exhaust people. Any slower, and you drift. This matches what organizational researchers have found: change works best as a rhythmic pulse rather than one-off events (Huy and Mintzberg, 2003), with tempo, duration, and sequencing determining success or failure (Kunisch et al., 2017).
Restructuring takes a human toll. People need time to get resituated, understand new roles, rebuild working relationships. You’ll see a productivity dip during any reorganization. If you’ve made good structural choices using these tenets, productivity should recover to a higher level. But that recovery takes time.
Early in your tenure, political constraints and organizational immaturity will force suboptimal structures. As you build credibility and your teams mature, those constraints ease. Use that opportunity strategically. But remember that each restructuring spends political capital and human energy. Make sure the structural improvement justifies both costs.
Structure is the lever most technical leaders underutilize because it requires political capital and organizational courage. Easier to optimize processes or coach people than fundamentally reorganize how work flows. But structural changes have exponential impact. Fix structure and many people and process problems solve themselves.
The goal isn’t perfect structure; that doesn’t exist. The goal is structure that lets delivery teams own their outcomes with minimal external dependencies. When your teams can ship value without asking permission from platform teams, you’ve achieved structural leverage.
But even the best rails need locomotives. That’s the people lever.
3.1.3 People: Gardening Your Teams
People management sits third in the hierarchy of leverage, but don’t mistake that for low importance. While strategy and structure create the framework for delivery, people execute within that framework. Get the people lever wrong, and even perfect strategy and structure won’t save you.
Before diving into hiring, development, and performance management, let me start with the most practical advice I can give you: cultivate a relationship with HR. Build political capital with your head of people, or whatever they call that role in your organization. Include them early when development problems arise. Go to them regularly, not just when you need something.
I don’t care what you think about HR personally. We in technology have this extraordinarily stupid idea that HR is the enemy. They are not the enemy, they’re not going away. You need them. Cultivate the relationship.
I lead with this because that relationship drives what you can accomplish everywhere else in people management. Without that relationship, you’ll be hindered at every turn. With it, you’ll be supported when you need to make difficult decisions. Build the relationship.
3.1.3.1 The Garden Metaphor
My general philosophy for people management is simple: think of your teams as a garden. You’re constantly growing, fertilizing, watering, and also pruning. Both activities are necessary for a healthy garden, and both are necessary for a healthy team.
You grow the people you can. You prune the people you can’t. This is a constant process, not an annual event tied to performance review cycles.
Which side you lean toward depends on your organizational context. If you’re leading a team of five people in a startup and your people are performing well, you won’t be pruning very often. If you’re managing 150 people in a larger organization, you’ll be pruning regularly. But you should always be growing.
The garden metaphor matters because it reframes difficult decisions. Pruning isn’t punishment; it’s maintenance. A gardener doesn’t prune a branch because they hate it. They prune it because the overall health of the garden requires it. Some branches take resources without contributing to growth. Others grow in directions that harm the whole plant.
3.1.3.2 Growing People: Situational Leadership in Practice
For CTOs, growing people means growing managers. This happens through delegation: giving your direct reports ownership of meaningful work and coaching them through the experience using radical candor. Real growth comes from progressively handing over responsibility for systems, teams, and decisions that matter to the business, then mentoring them through delivery with frank, unambiguous feedback.
Delegation serves dual purposes: it develops your managers while returning bandwidth to you. Every responsibility you successfully delegate is capacity you regain to focus on higher-leverage work. But delegation without coaching is abdication. You must stay engaged through honest, direct conversations about what’s working and what isn’t.
3.1.3.2.1 The Situational Leadership Framework
Effective delegation requires matching your approach to where someone sits developmentally. You can’t hand off the same responsibility the same way to a new manager and an experienced one. Hersey and Blanchard’s situational leadership model captures this reality (Hersey and Blanchard, 1977): leadership varies based on the person’s competence (skills and experience) and commitment (confidence and motivation) for the specific task at hand.
This creates four leadership approaches that correspond to different development stages:
Directing: High direction, low support. For people who are new to a task or role and need clear instructions, frequent check-ins, and explicit guidance on approach.
Coaching: High direction, high support. For people who have some experience but still need guidance, combined with encouragement and problem-solving support as they build confidence.
Supporting: Low direction, high support. For competent people who may lack confidence or motivation. They know how to do the work but need encouragement and collaborative problem-solving.
Delegating: Low direction, low support. For people who are both competent and committed. They own the outcome and come to you only for major decisions or when they request input.
3.1.3.2.2 Applying Situational Leadership to Delegation
Effective delegation requires calibrating what you delegate and how much support you provide based on where someone sits in this development cycle. For new managers or unfamiliar challenges, you start with directing: clear expectations, frequent check-ins, explicit guidance on approach. You might delegate implementation planning but retain architecture decisions, or give hiring responsibility but with your approval required.
As their competence and confidence grow, you shift to coaching: challenging directly while caring personally. You tell them when they’re making mistakes in frank terms, ask probing questions that expose gaps in their thinking, and provide context that helps them work through problems. The delegation expands—they might own team performance conversations with your coaching support, or lead cross-functional projects with regular strategic guidance.
When they demonstrate competence but need confidence building, you move to supporting: available when they request help, encouraging their decision-making, collaborating on problem-solving when asked. Your role becomes less about giving direction and more about reinforcing their capability.
Eventually, you reach delegating: they own the outcome completely and come to you only for major decisions or when they request input. This is true delegation—they have both the competence and commitment to succeed independently.
The mistake most CTOs make is treating delegation as binary. You either own something completely or you hand it off completely. Effective delegation is graduated, moving through these four stages based on the person’s development level for each specific responsibility.
3.1.3.2.3 Development Through Meaningful Ownership
Development opportunities for managers emerge constantly. A new team needs leadership, a critical system needs ownership, a major project requires coordination with other groups. These aren’t burdens to distribute fairly. They’re strategic investments in your organization’s leadership depth.
Match the opportunity to the person’s development needs and career trajectory, then apply the appropriate leadership style. The technical leader exploring people management gets responsibility for team health and performance conversations with directing or coaching support. The experienced people manager who’s weak on technical strategy gets ownership of architectural decisions with coaching around business context. The domain expert gets cross-functional coordination that stretches their business perspective with supporting encouragement.
The real leverage comes when your managers adopt the same approach with their teams. Teach them to assess their people’s competence and commitment for specific tasks, then match their leadership style accordingly. Your primary lever for making individual contributors more effective runs through your managers. Make your managers more effective at developing people using situational leadership, and that capability cascades down through the organization.
3.1.3.3 Pruning: The Necessary Discipline
Now for the harder conversation. Pruning. Firing isn’t optional in healthy organizations. It’s necessary maintenance. If you’ve never had to let someone go, either you’re incredibly lucky with hiring, or you’re not maintaining the garden properly.
This is where that HR relationship becomes critical. When you identify performance issues early, and you will if you’re coaching actively, bring HR into the conversation. Not to start a termination process, but to create a development plan with clear expectations and timelines.
If you’re coaching actively using situational leadership, performance issues become obvious quickly. Someone who requires constant directing on tasks they should have mastered, or who remains uncommitted despite appropriate supporting, signals a development problem. Your job is to decide whether to grow someone up or grow them out. That decision depends heavily on your context. If you’re in a successful company with good revenue, you may have the luxury of investing time in developing underperformers. If you’re in a startup with a fixed runway, you probably don’t have that luxury.
The mistake most technical leaders make is waiting too long to address performance issues. They hope problems will resolve themselves, or they try to work around poor performers instead of addressing them directly. This is unfair to everyone. The underperformer doesn’t get the feedback they need to improve, the team carries extra load, and you burn political capital managing around the problem instead of solving it.
When pruning becomes necessary, do it quickly and cleanly. Drawn-out performance improvement plans rarely work and create anxiety for everyone involved. If someone isn’t going to make it, help them transition out with dignity and support. This isn’t cruelty. It’s kindness to everyone involved, including the person who isn’t succeeding.
Your ability to execute this approach depends entirely on your organizational culture and your relationship with HR. Some organizations support quick, clean transitions. Others require extended documentation processes that drag out the inevitable. Work within your constraints, but understand that prolonged performance management rarely benefits anyone.
3.1.3.3.1 When You Can’t Prune: Building Around Constraints
Sometimes, however, you’ll encounter people you simply cannot touch. Leadership may have explicitly or implicitly put guardrails around certain employees for political, historical, or relationship reasons. In these cases, getting angry or continuing to push for termination wastes your political capital and accomplishes nothing. Instead, you must adapt your organizational design to work around the constraint.
I once managed someone who was an excellent individual executor but had zero ability to influence others or scale their impact. Give them a clearly defined task and they would deliver solid work. But as the organization matured and the bar for senior engineers shifted toward influence and team impact, they became less and less able to meet expectations. They couldn’t mentor junior engineers, couldn’t lead technical discussions, couldn’t drive cross-team initiatives—all capabilities that became essential for their level.
Under normal circumstances, this would trigger either intensive coaching to develop those skills or a transition out of the organization. But this person was untouchable due to their relationship with leadership. I could either waste energy being frustrated about the situation, or I could solve it within the constraints I faced.
I chose to craft a specialized role for them. I created a position that maximized their execution strengths while minimizing their need to influence others. They became our go-to person for complex, independent technical work that required deep focus but limited collaboration. I restructured team interactions so their work fed into the broader system without requiring them to drive consensus or mentor others.
Did I like having to explain to other engineers why different standards applied? Of course not. It cost me credibility and created questions about fairness. But the alternative—fighting an unwinnable battle—would have cost me far more political capital while achieving nothing.
The reality is messier than any framework suggests. You’ll recognize these constraints when you hit them. Leadership makes it clear through their actions, if not their words, that certain people are off-limits. Stop fighting it. I wasted months trying to performance-manage someone I couldn’t touch before I accepted the situation and started working around it.
Build scar tissue around the problem. I gave my untouchable executor increasingly isolated work that played to their strengths without requiring them to influence anyone. Was it efficient? No. Did it let the rest of the team function? Yes. Sometimes that’s the best you can do.
You’ll have to explain the different standards to your other engineers, and that conversation will suck. They’ll see the inconsistency. Some will call it unfair. They’re not wrong. But you can’t manage around organizational politics by pretending they don’t exist. Focus on what you can control: developing the people you can develop, building the systems you can build, delivering the results you’re accountable for.
Getting angry about untouchables burns energy you need elsewhere. I learned this the hard way.
3.1.3.4 The Balance of Growth and Pruning
You must maintain the right balance between growth and pruning for your context. High-growth startups can afford to carry some underperformers temporarily because they’re hiring fast and roles are fluid. Mature organizations with stable teams need higher performance bars because there’s less room for passengers.
But context changes, and your approach must adapt. The engineer who thrived in a chaotic startup environment might struggle as the organization matures and requires more process discipline. The manager who excelled with a small, co-located team might falter when managing distributed teams across time zones.
This doesn’t make them bad people or even bad employees. It makes them people whose fit with the organization has changed. Your job is to optimize for your organization’s delivery, which means recognizing that what the organization needs evolves constantly.
Your technical organization never fires anyone. Your CTO claims they have excellent hiring judgment and strong team performance.
It’s probably not a sign of exceptional leadership; it’s more likely avoidance of difficult personnel decisions. Technical leaders often avoid firing, hoping problems will resolve themselves or working around underperformers instead of addressing them directly.
Ask your CTO about their approach to performance management. Look for clear processes, regular feedback cycles, and evidence of difficult decisions when necessary. If they can’t point to examples of people they’ve helped transition out, dig deeper. The goal isn’t arbitrary firing, but ensuring your technical leader understands that team health sometimes requires difficult decisions.
The people lever requires the most emotional intelligence and interpersonal skill of all four levers. You’re dealing with careers, livelihoods, and human dignity. But approached thoughtfully, with clear expectations and genuine care for people’s growth, it becomes one of your most powerful tools for building delivery capability.
Remember: you’re not just managing individual contributors. You’re cultivating the human system that executes your strategy within your structure. Invest in that system deliberately, maintain it consistently, and it will deliver results that no amount of process optimization can match.
Even the best people need a timetable. That’s process; useful only when everything above it works.
3.2 Process: Outcomes Over Rituals
Process sits at the bottom of the leverage hierarchy. That makes it useful and dangerous. It’s seductive because it feels like progress. You can swap ceremonies in a meeting, update templates, ship a new checklist. It’s concrete and safe. Nobody gets hurt, nobody loses their job, nobody’s responsibilities change. They just do things a little differently. It is so tempting to try to fix things with process, and that’s exactly why it’s dangerous.
That’s why most technical leaders spend too much time here. Process changes are easy to implement and hard to evaluate. The feedback loops are long and the signal is weak, making process the perfect place to hide from harder decisions.
But process done right becomes a powerful multiplier when aligned with strategy, reinforcing structure, and supporting your people. The key is focusing on outcomes, not rituals.
3.2.1 The Four Outcomes That Matter
When you design your process, and you should design your process along with your teams, the outcomes you should design the process to elicit are as follows:
Predictable delivery dates. Engineering doesn’t exist in a vacuum. Marketing needs launch dates, sales needs feature commitments, support needs resolution timelines. Your process must help teams consistently predict when work will complete. You’re not aiming for perfect estimates but reliable patterns that stakeholders can plan around.
Precision without accuracy is theater. Single-point promises create false confidence; calibrated ranges create usable plans. Internally, plan with a target date and backup window. Externally, speak in confidence levels: “70% by Friday, 95% by Tuesday.” Most stakeholders won’t embrace probabilistic thinking, so you manage this internally and translate it externally.
Early problem detection. Problems caught late cost exponentially more than problems caught early. Good process surfaces risks, blockers, quality issues, and delivery slippages while there’s still time to address them.
Reduced ambiguity. Unclear requirements kill velocity. Teams spend more time debating what to build and how to build it than actually building. Your process should force clarity upfront on both the problem and the approach. You’re not seeking perfect specifications, but sufficient shared understanding that teams can make progress without constant clarification.
Team momentum. Teams need to feel they’re accomplishing something meaningful. Good process creates visible progress markers and celebrates completion. Teams that feel stuck lose energy and focus.
Within those constraints, process can be anything. What matters is whether your chosen approach delivers those four outcomes for your specific context. Remember: process is the lowest leverage point, so get the fundamentals right first.
3.2.2 The Maturity Curve
Teams mature over time, and your process approach should evolve with them. Early teams need scaffolding; mature teams need ownership.
When you inherit a team or start building one from scratch, you’ll often need to impose process initially. This is the Blub Paradox at work. They don’t know what good looks like until they see it. You have to insert a lever to hoist them up. Once they see what good looks like, they can iterate to better and great.
But scaffolding is temporary. As teams develop their own rhythms and build trust, they should take increasing ownership of their process. Your job shifts from defining the process to teaching them how to evaluate and evolve it.
The best teams eventually own their process completely. They experiment, measure what works, and adapt based on their specific context. This is the goal: teams that manage their own continuous improvement.
Getting there requires deliberate handoff. When teams identify problems, ask them to propose solutions. When they propose changes, let them run experiments. Gradually shift from “here’s how we do things” to “here’s how you evaluate whether things are working.”
This handoff isn’t just about team autonomy. It’s about your leverage. Every process decision you can successfully delegate is bandwidth you regain for higher-leverage work.
3.2.3 When Process Becomes a Crutch
The biggest danger with process is using it as a substitute for leadership. When strategy is unclear, leaders add more ceremonies. When structure creates bottlenecks, they add coordination meetings. When people aren’t performing, they add checkpoints and approvals.
You’re solving at the wrong level. Process can’t fix problems that originate at higher levels of the hierarchy. Unclear strategy doesn’t get clearer with better sprint planning. Structural bottlenecks don’t disappear with more standup meetings.
If you find yourself constantly tweaking processes without seeing improvement in delivery outcomes, look up the hierarchy. The real problem is probably one or two levels higher than where you’re applying the fix.
Use process to amplify the leverage you’ve created elsewhere, not as a substitute for creating that leverage in the first place. When process is aligned with strategy, structure, and people, it becomes a powerful multiplier. When it’s trying to compensate for problems at higher levels, it becomes expensive theater.
Your CTO constantly introduces new processes. Sprint planning gets reorganized every quarter. Standup formats change monthly. Teams complain about “process churn” but your CTO insists they’re “continuously improving.” This pattern signals weak leadership, not continuous improvement. Constant process churn usually indicates a leader who’s avoiding harder decisions at higher leverage levels.
Ask your CTO to explain the business case for process changes. Look for clear hypotheses about what outcomes will improve and how success will be measured. If they can’t articulate the connection between process changes and delivery results, you have a leadership problem.
If they can’t justify process changes with business outcomes, impose a moratorium on new processes for six months. Direct them to focus on strategy, structure, and people issues instead. Strong technical leaders make fewer process changes because they’re working at higher leverage levels.
3.2.4 When Stakeholders Have Process Opinions
It’s common for stakeholders to inject their opinions into your process. They’re optimizing for perception rather than outcomes (Pfeffer, 2010), which hinders your ability to iterate toward what actually works.
I once had a team with a solid process. We were predicting dates accurately, signaling problems early, addressing them quickly. We spent time upfront investigating what we needed to do, especially in complex legacy systems. This made our iteration more confident and our dates more reliable.
At some point, this triggered leadership. They felt like we were spending too much time designing systems. They banned the technical design work that enabled our accurate predictions. We ended up with a smaller process that didn’t deal with ambiguity as well, but looked more responsive to stakeholders.
The outcome was predictable: our dates became much more inaccurate. We got complaints about the inaccurate dates, but stakeholders never connected those complaints to their process restrictions. We improved the process to the best of our ability, but given the constraints, we were never able to restore the accuracy we had before.
Remember the leverage hierarchy. Process sits at the bottom for a reason. It can amplify good decisions made at higher levels, but it cannot fix them. When your strategy is clear, your structure supports flow, and your people are capable, process becomes a reliable multiplier. When those fundamentals are broken, process becomes expensive theater. Start at the top of the hierarchy and work your way down.
3.2.5 The Art of Judgment
You won’t always have access to the top lever. Sometimes the CEO owns strategy and won’t budge. Sometimes structure is frozen by politics or history. Sometimes the people you need to prune are untouchable. That’s real life. Judgment is how you deal with it.
Start with honesty about constraints. If the highest lever you can pull today is process, fine, but name the trade. You’re buying relief, not resolution. You’re managing symptoms while you accumulate political capital for a higher cut.
The discipline is diagnose up, intervene as high as you can. When a problem presents at level N, look one or two levels up first. If N+2 is blocked, try N+1. Only then touch N. When you do, tell your team what higher lever you’d pull if you could: “We’re tightening deployment hygiene now, but the real fix is unifying ownership across product and ops.” This keeps everyone aligned on what the actual problem is.
Timing matters. Sometimes you spend capital early and hard because drift will compound into a year of waste. Sometimes you wait because a forced restructure before a key launch will cost more than it saves. Don’t confuse urgency with importance. The urgent stuff is usually at the bottom of the pyramid. The important stuff is at the top.
Sequence matters too. Get strategy sharp before structure makes every downstream cut cleaner. Get structure right before mass hiring prevents you from pouring people into bad plumbing. When you can’t change sequence, explain it: “We’re hiring into an imperfect structure; here’s how we’ll minimize organizational distance until we can refactor the org.”
Not every misalignment demands a reorg. Sometimes a shared metric, an embedded specialist, or a weekly alignment ritual collapses practical distance enough to ship. You’re buying time so your future structural change is cleaner and cheaper.
You’ll be tempted to hide in process because it’s visible and safe. Don’t. Spend your capital where it compounds, even when that means fewer ceremonies, harder conversations, and less visible progress.
3.3 Closing Reflection
Strategy, structure, people, process. In that order of leverage.
You’ll get more impact from pulling the right lever than from pulling the wrong one harder. Diagnose up the hierarchy first. Intervene as high as you can. Spend political capital where it compounds. When you can’t reach the top lever, stabilize what you can and keep chipping away at the barriers until you can make the higher cut.
This is the Dao of Delivery. Not laws, not checklists. Judgment under constraint. Your teams need outcomes, not rituals. Your organization needs flow, not theater. Your job is to deliver results that compound over time.