3 The Hierarchy of Leverage
This chapter is currently in draft form.
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.
The hierarchy of leverage is 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 is your lens 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. Use it to examine problems and think 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. Some levers change the entire system; others change only the local experience. Your job is to pull the highest-leverage lever available to you, not the one that feels safest.
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. 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 real trade-offs isn’t a strategy. Rumelt calls real strategy “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. Martin’s “Playing to Win” cascade (Martin and Lafley, 2013) makes the same point differently: each strategic choice (where to play, how to win, required capabilities) constrains the next, creating the sharp trade-offs that actually guide decisions.
One thing neither framework emphasizes 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.
This is, admittedly, a quiet inversion of Chandler’s principle. He argued that structure follows strategy, implying strategy flows down from the top. That’s the view from the ivory tower. In the trenches, it’s dirtier. When top-level strategy is absent or incoherent, you don’t have the luxury of waiting for someone else to fix it. You build what your teams need and let the absence of guardrails above you become permission to lead.
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.
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 platform 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. Platform 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.
Platform 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.2 When Gates Signal Systemic Failure
When you feel compelled to add gates to the delivery process, treat it as a signal of capability gaps at the people and process layers. Gates are responses to past failures, not solutions. The architecture review board often appears after a system fails to scale. Security approvals show up after vulnerabilities reach production. QA gates follow broken features reaching customers.
The issue is not that these failures occurred; in complex systems they will. The issue is responding with new gates instead of building capability inside delivery teams.
Replace approvals with capability. Equip teams with the tools and training to make secure decisions, and embed security expertise where the work happens. If regulation requires independent checks, keep them narrow, automated, and auditable.
Apply the same approach to quality, architecture, and compliance. These concerns are legitimate. The goal is to place the capability to address them as close to delivery teams as possible.
If your CTO reacts to production problems by adding gates (security approvals, release checkpoints, or separate deployment teams), you have a structural problem. These barriers create coordination issues and bottlenecks instead of fixing root causes.
This pattern signals your CTO does not yet know how to design a strong delivery organization. Your job is to decide whether they can learn or whether you need someone else.
Ask your CTO for an organizational plan. Ask for three elements: target design, the tenets behind it, and an implementation schedule. Judge it on whether it speeds decisions and accountability, not on headcount charts. Look for unified delivery and minimal organizational distance. If the plan adds gates instead of embedding capability in delivery teams, send it back with clear criteria.
3.1.2.4 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. 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.
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. I don’t care what you think about HR personally. We in technology have this extraordinarily stupid idea that HR is the enemy. They’re not. They’re not going away. And that relationship drives what you can accomplish everywhere else in people management. Without it, you’ll be hindered at every turn. With it, you’ll be supported when you need to make difficult decisions.
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 Matching Your Approach to the Person
Effective delegation requires matching your approach to where someone sits developmentally. Hersey and Blanchard’s situational leadership model (Hersey and Blanchard, 1977) captures this: leadership style should vary based on the person’s competence and commitment for the specific task at hand.
A new manager facing an unfamiliar challenge needs direction: clear expectations, frequent check-ins, explicit guidance. You might delegate implementation planning but retain architecture decisions. As their competence grows, you shift to coaching: challenge directly, care personally, tell them when they’re making mistakes, ask probing questions, provide context. They might own team performance conversations with your active support.
Once they’re competent but still building confidence, you step back further. You’re available when requested, encouraging their decision-making, but no longer driving. And eventually, you reach true delegation: they own the outcome completely and come to you only for major decisions.
The mistake most CTOs make is treating delegation as binary: you either own something completely or hand it off completely. Effective delegation is graduated, moving through these stages based on the person’s development level for each specific responsibility.
Development opportunities emerge constantly: new teams need leadership, critical systems need ownership, major projects require coordination. Match the opportunity to the person’s development needs. The real leverage comes when your managers adopt the same approach with their teams. Make your managers effective at situational leadership, and that capability cascades through the organization.
3.1.3.3 Pruning: The Necessary Discipline
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 (and you will if you’re coaching actively), bring HR into the conversation early. Not to start a termination process, but to create a development plan with clear expectations and timelines. Your job is to decide whether to grow someone up or grow them out.
The mistake most technical leaders make is waiting too long. They hope problems will resolve themselves, or they work around poor performers instead of addressing them directly. This is unfair to everyone: the underperformer doesn’t get the feedback they need, 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. Help people transition out with dignity and support.
I still haven’t learned to do this well. After years of practice, I’m still trembly and useless after letting someone go. I schedule these conversations for late afternoon and take the rest of the day off because I know I won’t be good for anything else. I do it because it needs to be done, but most of the time I hate it. If you find firing easy, something is wrong with you. If you find it hard, that’s the appropriate response to ending someone’s livelihood.
Your ability to execute this depends on your organizational culture and your relationship with HR. Some organizations support quick, clean transitions. Others require extended documentation processes. 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 limited 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 able to meet expectations. They couldn’t mentor junior engineers, couldn’t lead technical discussions, couldn’t drive cross-team initiatives. These were capabilities that had become 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 protected due to their relationship with leadership. The path forward wasn’t to fight that constraint; it was to design around it.
I crafted a specialized role 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.
This approach had real costs. Other engineers noticed the different standards. Some questioned the fairness, and they weren’t wrong to ask. It required difficult conversations about why different expectations applied. But fighting an unwinnable political battle would have cost far more 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. Once you recognize that reality, redirect your energy toward what you can control: craft roles that contain the impact, design workflows that minimize dependencies, and focus your development efforts on the people who can grow.
These situations are frustrating. Accepting the constraint doesn’t mean you have to like it. But dwelling on what you can’t change depletes energy you need for the work that actually moves your organization forward.
3.1.3.4 The Balance of Growth and Pruning
The right balance depends on context. High-growth startups can carry some underperformers temporarily because roles are fluid and hiring is fast. Mature organizations need higher performance bars because there’s less room for passengers.
Context changes, and your approach must adapt. The engineer who thrived in startup chaos might struggle as the organization matures. The manager who excelled with a small co-located team might falter with distributed teams across time zones. This doesn’t make them bad employees. It makes them people whose fit with the organization has changed. Your job is to optimize for 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 more emotional intelligence than the others. You’re dealing with careers, livelihoods, and human dignity. But approached thoughtfully, it becomes one of your most powerful tools for building delivery capability. You’re not just managing individuals. You’re cultivating the human system that executes your strategy within your structure.
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 What Good Process Delivers
Process should be designed with your teams, not imposed on them. But whatever form it takes, it needs to deliver predictable dates, early problem detection, reduced ambiguity, and team momentum.
Engineering doesn’t exist in a vacuum. Marketing needs launch dates, sales needs feature commitments, support needs resolution timelines. You’re not aiming for perfect estimates but reliable patterns that stakeholders can plan around. Problems caught late cost exponentially more than problems caught early, so good process surfaces risks, blockers, and quality issues while there’s still time to address them. Unclear requirements kill velocity; teams spend more time debating what to build than actually building, so your process should force sufficient shared understanding upfront. And teams need to feel they’re accomplishing something meaningful. Good process creates visible progress markers. 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.
Leadership saw the upfront investigation differently. To them, it looked like excessive design time. They mandated a leaner process that reduced the technical discovery work enabling our accurate predictions. The new process looked more responsive (less time before coding started) but handled ambiguity poorly.
The outcome was predictable: date accuracy declined significantly. This created a frustrating dynamic where the constraint causing the problem remained invisible to those who imposed it. We optimized within the new boundaries as best we could, but never recovered the prediction accuracy we’d had before.
Stakeholders optimize for what they can see, and upfront investigation is harder to see than visible coding activity. If you face similar constraints, your options are to build the case for why the previous approach worked, find ways to preserve essential discovery within the new constraints, or accept the trade-off and manage expectations accordingly. Sometimes none of those options work. You absorb the loss and keep moving.
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. Checklists don’t ship products. People working within clear structures toward sharp strategic goals ship products.
Pull the highest lever you can reach. That’s the job.