2 The Blub Paradox
This chapter is currently in draft form.
In his 2001 essay “Beating the Averages,” Paul Graham described what he called the Blub Paradox (Graham, 2001). He imagined a hypothetical programming language, Blub, sitting somewhere in the middle of a power continuum. A Blub programmer could look down the ladder and immediately see the limitations of weaker languages, but when they looked up at more powerful languages like Lisp, they all seemed equally weird.
The paradox is that unless you’ve actually experienced a higher-level language, you can’t recognize what it gives you. You lack the apparatus to perceive what you’re missing.
Graham was talking about programming languages, but he’d stumbled onto something more fundamental: a universal truth about perception and judgment that also shapes how organizations see problems, solutions, and each other. High-leverage work is consistently misperceived. Not because people are stupid or resistant to change, but because they’re trapped in the same cognitive bind as Graham’s Blub programmer, unable to see value in abstractions they haven’t yet experienced. This is why political capital matters: you’ll need to ask for trust on things people can’t fully understand until they’ve experienced them.
High-leverage work is persistently misperceived because the cognitive machinery required to see its value only develops through exposure, not argument.
2.1 The Asymmetry of Perception
Graham’s insight hinges on an asymmetry. Looking down the power curve is easy. Anyone who’s written Rust can explain why they wouldn’t want to manage memory manually in C. The limitations of less powerful tools are visible, concrete, and often frustrating in ways that stick with you.
Looking up is different. More powerful abstractions don’t announce themselves. They solve problems you didn’t know you had, or eliminate entire categories of work you’d accepted as inevitable. If you’ve never experienced automatic or compile time memory management, you don’t walk around feeling its absence. You just budget time for tracking allocations and hunting memory leaks. That’s just what programming is.
You rarely think your way up the curve. No amount of logical argument will make most Blub programmers suddenly see what Lisp macros offer, because the very concepts required to understand the benefit don’t exist in their mental toolkit yet. They have to write Lisp, live in it long enough for the new capabilities to become part of how they think.
To the C++ programmer, Lisp looks like weird parentheses and academic self-indulgence. They’re not being obtuse. They genuinely can’t see what the parentheses buy you, because seeing it requires concepts they don’t have yet.
2.2 The Management Blub Paradox
The same dynamic plays out in organizations, often with higher stakes and longer feedback loops. The parallels to Graham’s original formulation are sharper than you might expect.
To the process-focused manager, a leader who spends three weeks redesigning the org chart looks like they aren’t working. Why aren’t they closing tickets? Why aren’t they in the standup? Why are they just talking and writing instead of doing? The strategic leader’s calendar (full of one-on-ones, skip-levels, whiteboard sessions, and long blocks of unscheduled time) looks like either laziness or the performance of importance.
To the strategic leader, the process-focused manager looks like someone frantically bailing water out of a boat with a hole in it. All that energy, all that visible effort, all those heroics, and the boat is still sinking. The strategic leader wants to stop bailing and fix the hole. But fixing holes doesn’t look like work to someone who’s only ever bailed.
This is the Management Blub Paradox. High-leverage work looks like weird fluff to low-leverage thinkers, just as Lisp looks like weird parentheses to C++ programmers. The perception gap isn’t about intelligence or work ethic. It’s about the conceptual vocabulary required to see value at higher levels of abstraction.
Consider the relationship between strategy and process. Process is comfortable territory for most delivery leaders. It’s concrete: standups, sprint planning, retrospectives, deployment pipelines. You can measure process. You can optimize it. You can feel productive while working on it.
Strategy is fuzzier. It asks questions like: Should we be building this at all? What capabilities will matter three years from now? How should we position against the competitive landscape? For someone who’s never seen strategy done well, who’s never watched a clear strategic choice unlock momentum that no amount of process optimization could achieve, these questions sound like executive hand-waving, the things people talk about when they don’t want to do real work.
So they keep tweaking process. They add another ceremony. They refine the estimation technique. They’re Blub programmers optimizing their for-loops while someone else reaches for a higher-order function that makes the loops unnecessary.
The same pattern shows up in how people think about structure versus individual performance. When conflict arises between teams, functions, or people, the instinctive diagnosis is usually about the people involved. Sarah is difficult. The platform team is territorial. Engineering and Product don’t respect each other.
Sometimes that’s accurate. But often the real problem is structural: the org chart, the incentive systems, the information flows. The interpersonal friction is just a symptom. People operating within a badly designed structure will generate conflict reliably, regardless of how skilled or well-intentioned they are.
If you’ve never redesigned structure, never experienced the almost magical effect of aligning incentives correctly or clarifying ownership boundaries, then every problem looks like a people problem. You coach. You mediate. You hope people will figure it out. You’re working in Blub while the answer exists at a higher level of abstraction.
The misperception runs deeper than disagreement about methods. It shapes how people see you.
2.3 The Laziness Accusation
As you move up the hierarchy of leverage, you will look increasingly useless to people operating below you.
High-leverage work (thinking, writing, talking, deciding) looks remarkably like laziness to low-leverage workers. Peter Drucker identified this problem decades ago when he defined knowledge work as fundamentally invisible (Drucker, 1969). In manual work, you can see the product. In knowledge work, the product is a decision. The engineer who’s been heads-down coding for twelve hours sees you leave at 5 p.m. after a day of “just meetings” and draws conclusions. The project manager drowning in status updates watches you spend a week on a two-page strategy document and wonders what exactly you do around here.
This isn’t their fault. They’re accurately perceiving what’s visible. You’re not producing the artifacts they recognize as work. What they can’t see is that your two-page document will redirect six months of their effort, or that your “just meetings” realigned three teams in ways that will eliminate half their future coordination overhead.
The Economy of Political Capital exists precisely for this reason. You need an accumulation of trust to survive the periods when your work is invisible to everyone except the people operating at your level or above. And your boss may not be one of those people. Without that capital, you’ll face pressure, explicit or implicit, to demonstrate value in terms your organization’s Blub programmers can recognize. You’ll get pulled back down to visible busyness: back to bailing water, back to optimizing for-loops.
This creates a painful irony. The leaders who most need to do high-leverage work are often the ones least able to afford it, because they haven’t yet built the capital required to make that work legible. They’re trapped in a cycle where proving their worth requires staying at a level of abstraction that will never let them prove their full worth.
Your CTO is staring at a whiteboard while the engineering team types furiously. Your instinct says they’re not contributing.
Don’t judge by visible activity. Judge by the team’s momentum. A CTO writing code to hit a deadline is the highest-paid, least-efficient individual contributor in the building. Their job is to steer the ship, not row the boat.
If the team is stuck on the same problems they had six months ago, that’s the bad kind of quiet. Intervene. If outages disappear, the roadmap stabilizes, and the shouting matches between Product and Engineering vanish, that’s good quiet. Let them work.
Understanding the perception gap is the first step. The second is learning to work across it.
2.4 The Translation Barrier
You can’t explain the value of structure to someone who only speaks process. The concepts don’t translate. But you can translate the benefits down.
Elliott Jaques called this the time span of discretion (Jaques, 1998). Your level in an organization is defined by how long it takes for your mistakes to show up. A junior engineer’s compile error surfaces in a day. A manager’s missed quarter takes three months to materialize. A CTO’s architectural mistake might not become visible for three years. The reason a junior engineer can’t see the CTO’s work is that the feedback loop is longer than their current time horizon. They’re not being obtuse. They can’t perceive consequences that unfold over years when their world operates in days.
If you want to operate across levels of the hierarchy without going insane, learn to express high-leverage outcomes in low-leverage terms. You don’t say, “We’re redesigning the org chart to improve information flow and reduce coordination costs.” You say:
“We’re changing the teams around so you don’t have to go to that 8 a.m. meeting anymore.”
The first framing is accurate but illegible. The second is a simplification, but it lands. People will support changes they don’t fully understand if those changes address pain they feel directly.
This is translation. You’re doing the cognitive work of bridging abstraction levels because you’re the one who can see both. The alternative is insisting that everyone understand the full strategic rationale before they’ll support change. That’s intellectual vanity that sacrifices outcomes for purity.
The best leaders I’ve worked with are fluent in multiple levels of abstraction. They can discuss organizational design with the CEO and then walk downstairs and explain the same change to an engineer in terms of what meetings will disappear from their calendar. Both explanations are true. The leader is just choosing which truth fits the listener’s conceptual vocabulary.
You want to tell your engineering leader to stop over-complicating things. The solution that seems easiest right now looks simple to you, but it isn’t simple to them. To your engineering leader, simple means the solution that won’t bankrupt you in maintenance costs next year.
Don’t argue about the technical solution. You’ll lose, or worse, you’ll win and force a bad decision. Instead, demand translation: “If we don’t do this, what specifically breaks in six months? Put a dollar amount or delay metric on it.”
If they can translate to risk and revenue, the complexity may be warranted. If they can’t, kill the project. But don’t kill it just because it looks weird to you.
2.5 Breaking the Paradox
If misperception is inevitable, the question becomes how anyone ever escapes it.
You don’t argue people up the curve. You can’t. The concepts required to understand your argument are the same concepts they’re missing in the first place. Every attempt to explain why strategy matters will sound like weird Lisp parentheses to someone who’s never experienced strategy working.
The only reliable teachers are outcomes and exposure.
Outcomes means solving problems people thought were insoluble, or dissolving problems they’d accepted as permanent features of their environment. The team thinks they need a better deployment checklist: more steps, more verification, more ceremony. They’re operating in process-space, looking for process-level solutions. You look at the situation and realize the problem isn’t the checklist. It’s that two teams that should be one are artificially separated, creating a handoff where errors breed. You fix the structure, merge the teams, and suddenly they don’t need a checklist at all. The problem doesn’t get solved. It vanishes.
That vanishing is the aha moment that moves people up the curve. They were pushing on a door that you revealed was actually a wall. The door was somewhere else entirely. No amount of arguing would have convinced them. They had to feel the wall stop resisting.
Exposure means letting people watch you operate at a higher level of abstraction, close enough to see your reasoning without having to produce it themselves. When faced with a problem, work through your thinking out loud. Let them hear the questions you’re asking that they aren’t. Let them watch you reach for structural explanations when they would have blamed individuals, or strategic considerations when they would have jumped to tactical execution.
Exposure is slow teaching. You’re not conveying information. You’re helping someone develop new perceptual categories. That takes repeated exposure, multiple examples, gradual pattern recognition. You can accelerate it somewhat by choosing vivid examples, by making your reasoning explicit, by creating safe spaces for people to try higher-leverage thinking and fail. But you can’t compress it into a single conversation.
The patience required is substantial. You’re going to explain something important and watch it bounce off. You’re going to solve a problem elegantly and have people attribute the success to luck or circumstance. You’re going to implement something that works, and watch people try to undo it because they don’t understand why it’s working. You’re going to do your best work and have it be invisible. This is the cost of operating above the Blub line in an organization full of Blub thinkers.
2.6 The Humility Clause
The Blub Paradox applies to you too.
There are levels of abstraction above wherever you currently operate, and you can’t see them yet. Problems you’re solving through heroic effort have solutions you can’t perceive. The frustrated incomprehension you feel toward the process-obsessed manager below you is the same frustrated incomprehension someone above you feels watching you miss the bigger picture.
This keeps you humble about your own position on the curve. It keeps you curious about what you might be missing. And it makes you more patient with the people below you, because you recognize yourself in their confusion. You’re just confused about different things, at a different altitude.
The goal isn’t to reach the top of some imaginary hierarchy and look down at everyone else’s limitations. The goal is to keep climbing, keep expanding your perceptual vocabulary, keep finding new levels of leverage while helping others do the same.
The Hierarchy of Leverage will give you the map: Strategy, Structure, People, and Process, the hierarchy of leverage that most organizations invert. But maps are useless if you can’t read them. This chapter was about developing the eyes to see what the map is showing you, and the patience to help others see it too.