← Writing

Conditions, not direction

I start with the premise that the function of leadership is to produce more leaders, not more followers.

— Ralph Nader

Every technical organization has hard problems and leaders who feel the pull to solve them. Supplying direction and making decisions feels like leadership. It looks like leadership, and it's how many leaders understand their jobs.

I've come to think that this leadership style is bad for most technology work. The reason is it doesn't match with the way teams of humans actually operate best in conditions of uncertainty. Here's the principle, stated plainly:

A technology leader's primary job is to set up working conditions so that their people will be most likely to produce breakthroughs. The leaders job is not to produce the breakthroughs themselves.

It's important to understand what this principle rules out. It rules out the fixed top-down control. It rules out the roadmap as a commitment device. It rules out what review and approval gates usually do. And it reframes a large share of the management calendar as overhead on the real work rather than the real work itself.

The literature keeps rediscovering this at every altitude

One academic term of art used to capture this philosophy is generative leadership. Surie and Hazy's work on complexity leadership (Generative Leadership: Nurturing Innovation in Complex Systems, 2006) argues that generative leadership means managing complexity and institutionalizing innovation by balancing connectivity and interaction among individuals and groups — explicitly not by dictating outcomes. The key construct they borrow from Lane and Maxfield's Strategy Under Complexity: Fostering Generative Relationships (1996) is the generative relationship: a mode of connection between people that reliably produces new learning relevant to innovation.

The important move in their framework is what the leader is doing. The leader does not create the innovation. The leader experiments with, fosters, and sustains the conditions in which generative relationships occur. Condition-setting is the bulk of a leader's job.

In the nonprofit governance literature, Chait, Ryan and Taylor's Governance as Leadership (2005) describes "generative thinking" as something a board does — periodic collective reframing, at the very top of the organization, about purpose and strategic assumptions. Meanwhile, the DevOps research community has spent over a decade measuring generative culture at the level of individual delivery teams.

The same structural truth, leader as condition-setter rather than answer-giver, keeps getting rediscovered at the board, the executive team, and the delivery team level. It's a pattern that, in my experience, many leaders today are still blind to.

The claim is not that innovation happens at the bottom of the hierarchy and therefore leaders should get out of the way. The claim is about orientation: the leader's attention points downward, toward the creative capacity of the people they lead, rather than inward, toward their own judgment as the scarce resource.

That applies to a first-line manager with two developers under them, as well as a director with five teams. It describes an executive whose direct reports are all themselves managers, and whose condition-setting is mostly about budget, political cover, and priorities. The same leadership approach appears like a fractal at all levels of the organization.

The arithmetic, stated weakly

There is a strong version of this argument says breakthroughs come from the bottom, executives don't innovate, and hierarchy is the enemy of creativity. That's false, and anyone who has had a truly great leader knows it's false. Good leaders are actively a part of the team's innovation engine.

The weaker (and truer) way of putting it is: genuine breakthroughs are rare events per person per unit time. There are far more people at the lower levels of an organization than at the top. Therefore the expected number of breakthroughs an organization produces scales with how many of its people are both positioned to have one and able to act on it. An organization that treats generativity as an executive function is sampling from a much smaller pool. Breakthroughs are unevenly distributed and hard to predict in advance — which is bedrock premise in technology.

A word about "complex"

The leadership literature leans hard on a distinction between complicated problems and complex ones. Complicated problems are hard but tractable: with enough expertise and analysis, you can work out the right answer ahead of time and then execute it. Complex problems are different in kind — the answer isn't knowable in advance, not because you haven't analyzed hard enough, but because the relevant information doesn't exist yet. It gets produced by acting.

I'll be honest that I find this distinction a little tired, and less sharp than the people who deploy it seem to think. Plenty of real work sits on the boundary, or crosses it halfway through. But I keep coming back to it for two reasons.

The first is that "complex" really does describe most interesting technology work. Whether an architecture will hold, whether a data model survives contact with real data, whether a product motion resonates — these are discovered, not deduced. Ryan Singer's version of the idea is sharper than the literature's. In Shape Up he splits every project into an uphill and a downhill phase: uphill is "full of uncertainty, unknowns, and problem solving," while downhill is "marked by certainty, confidence, seeing everything, and knowing what to do." Every project contains both. The failure mode is managing the uphill half as though it were the downhill half — demanding estimates, dates and specifications from the part of the work whose entire purpose is to find out what the work is.

The second reason matters more: wherever people take this distinction seriously, they arrive at the same conclusion I'm arguing for here. Stanley McChrystal's Team of Teams is the most vivid case, because it comes from about the most command-and-control institution that exists. McChrystal's task force found that "complexity produces a fundamentally different situation from the complicated challenges of the past," and that "in spite of our increased abilities to track and measure, the world has become, in many ways, vastly less predictable." More measurement did not buy more foresight.

What they did about it is the part worth stealing. McChrystal's conclusion was that "individuals and teams closest to the problem, armed with unprecedented levels of insight from across the network, offer the best ability to decide and act decisively" — and that the leader's own role had to change to match: "the temptation to lead as a chess master, controlling each move of the organization, must give way to an approach as a gardener, enabling rather than directing." An organization that had every reason to double down on hierarchy concluded instead that decisions belonged lower and that its commander's job was to tend conditions. That's the same answer the complexity-leadership literature reaches from theory and DORA reaches from data.

When you apply conventional leadership to a complex problem, the fixed vision isn't merely suboptimal. It's actively harmful, because it forecloses the possibility space that most likely contains the answer. You've spent your authority narrowing the field of view precisely when it needed to widen.

Why the unpredictability is structural

It's tempting to treat this unpredictability as a measurement problem — a thing better forecasting or better estimation would fix. I love measurement, but I don't think it can be the full answer.

That instinct has a lineage. Our default picture of the manager as measure-taker traces back to Frederick Winslow Taylor, whose scientific management put a stopwatch on the shop floor, decomposed work into observable motions, and promised that sufficient measurement would yield "the one best way" to do a job. For the work Taylor studied, it largely did. The trouble is that the method assumes the task is knowable in advance and the same every time — which is exactly the assumption creative technical work violates. Taylorism doesn't fail on complex work because the measuring is sloppy. It fails because there is no stable "one best way" sitting there waiting to be measured.

In A World of Becoming (2011), William E. Connolly understands uncertainty, creativity, and by extension innovation, as fundamental to the human condition. The book shows that we live among multiple interacting systems — climate, biology, economics, geology, culture — each running on its own tempo, each with its own periods of stability and instability. Novelty, in his account, arises when these systems resonate: when force-fields moving at different speeds happen to align and amplify one another, producing outcomes that none of them contained on its own.

His name for this is emergent causality, and he offers it as an alternative to classical causality — the billiard-ball model where identifiable cause A produces predictable effect B. Complex systems, Connolly argues, defy classical causal explanation and prediction. You cannot know in advance what will come, and extrapolation from the recent past is unreliable. He pairs this with a rejection of linear, chronological time as an adequate description of how change actually arrives. Change arrives when temporalities converge, which is not a thing a calendar, or a roadmap, can represent. His subject, in the book's own framing, is a world whose "powers of creative evolution include and exceed the human estate" — creativity is not a thing we supply to an inert world, it is something the world is already doing, with or without our plan for it.

All of this, I belive, applies not just to the macro systems of our natural world, but also to the microcosm of an organization, and to a team within an organization. A plan is an efficient-causality claim: this input, applied over this interval, yields that outcome. For complicated work, that claim is roughly true and enormously useful. For genuinely creative technical work, the roadmap is asserting a kind of causation that doesn't exist on technology teams. This is why breakthroughs so reliably show up by accident in the wrong quarter, from the wrong team, as a side effect of something else. It's not that planning failed, it's how emergence works!

Connolly's own response is not despair but what he calls an ethos of radical interinvolvement — treating the world as a work-in-progress and a collective adventure rather than a system to be mastered. Translated into organizational terms, that's a fairly demanding ask of a leader: hold real commitments and real accountability while genuinely not knowing where the good thing will come from, and without resolving that discomfort by pretending to know.

Luck is not a strategy

Leaders running tech teams operate in conditions of fundamental uncertainty. That's not an argument for leaving people alone. Rather, leaders should work hard to engage their teams in ways that respect this fundamental uncertainty, and help them understand it too.

The teams that actually generate outsized returns don't wait for emergence to happen to them. They build a habit — a culture, a machine — that harvests it: run experiments cheaply enough that most of them can fail, read the results honestly, and pour resources into the few that show leverage. The rarity of breakthroughs is a fact about the world. The rate at which an organization converts breakthroughs into value is a fact about the organization, and that's where leaders make impact.

Anthropic's Claude Code is a well-documented instance of the pattern, and it's instructive because at no point does an executive appear in the causal chain. It started in September 2024 as a personal experiment by an engineer, Boris Cherny, two months into the job: a command-line toy that used Claude to identify what music he was listening to. Then there was a suggestion from a product manager on the team to give the tool filesystem access. Then, the conditions within the organization allowed this experiment to gain momentum. A dogfooding build went out internally in November. Roughly 20% of engineering used it on day one, 50% by day five. That internal adoption curve — not a strategic review — is what made the case for shipping it. The early team worked with "no formal processes inside the team: it was all super fluid."

Every element of that story is a condition a manager had to set, or at least not prevent. An engineer had the slack to build a music-identifying experiment. A colleague was close enough to the work to make the suggestion that mattered. Internally, the company aligned around running an experiment, and following the evidence.

It's worth being precise about what leadership did here, because it looks like absence and isn't. Someone decided not to ask why an engineer two months into the job was spending time on a command-line toy that identified music. Someone let a thread that appeared out of nowhere — on no roadmap, in no quarterly plan, attached to no OKR — keep getting pulled. That restraint is a decision, and a harder one than it sounds, because every organization has machinery for noticing unbudgeted effort and naming it drift.

Set that against what most of us actually do. We build a roadmap, conditions change two months later, and we hold the team to it anyway — out of commitment, or consistency, or an unwillingness to look like we're giving up. We call this discipline. What it teaches the team is that a thread appearing out of nowhere is a threat to the plan rather than the most valuable thing that could happen to it. Connolly's point lands squarely here: the roadmap was an efficient-causality claim, made under conditions that no longer exist. Holding to it after the ground has moved isn't commitment. It's a category error wearing the vocabulary of virtue.

So the responsibility runs the other way. When conditions change, a leader's job is to throw the roadmap out — visibly, and early enough that the team learns the plan was always a hypothesis rather than a promise extracted from them. That is what "conditions, not direction" actually costs. Anyone can say they want emergent innovation. The test is what you do the first time it shows up on a Tuesday, from someone nobody asked, in a quarter you had already committed.

The evidence: what generative culture actually predicts

Leadership that is oriented toward creating more leaders is also suggested by software delivery research. Ron Westrum's typology sorts organizational cultures by how information flows through them, into three types:

  • Pathological — power-oriented. Low cooperation, messengers are punished, responsibilities are shirked, failure leads to scapegoating, and novelty is crushed.
  • Bureaucratic — rule-oriented. Modest cooperation, messengers are neglected, responsibilities are narrow, failure leads to justice, and novelty creates problems.
  • Generative — performance-oriented. High cooperation, messengers are trained, risks are shared, bridging between groups is encouraged, failure leads to inquiry, and novelty is valued.

These organization types can be read as descriptions of leadership behavior rather than ambient culture. Every item is something leaders directly shape - choose to nurture or discourage.

The DORA research program has been testing this at scale for over a decade — 36,000+ professionals in the 2023 report alone — and finds that a high-trust, generative culture predicts both software delivery performance and organizational performance. That report put a number on it: teams with generative cultures, where people feel included and feel a sense of belonging, showed roughly 30% higher organizational performance. The same report found a 40% organizational performance edge for teams that focus on the user, and 25% higher team performance where internal documentation is high quality.

DORA also translates the culture finding into six things leaders can actually do:

  1. Build for high cooperation — cross-functional teams with representation from each function in the delivery process.
  2. Train messengers — hold blameless postmortems. Removing blame is how you remove fear.
  3. Share risk — developers share responsibility for their code in production, rather than throwing it over a wall.
  4. Encourage bridging — break down silos through co-location, inclusion in planning, and informal relationships.
  5. Choose inquiry over blame — treat failures as opportunities to improve the system.
  6. Implement novelty — give people freedom to explore new ideas, and dedicate actual time for experimentation.

What this means in practice

If the framing holds, the implied behaviors are fairly specific and, usefully, testable:

  • Minimize top-down specification of how work gets done, even while direction on priorities, outcomes, and constraints may remain top-down. Allow people to self-organize and invent their own processes.
  • Treat unblocking as the primary leadership activity. Removing organizational friction, protecting focus time, and resolving cross-team dependencies, rather than review and approval gates.
  • Expect innovation to look sporadic and unschedulable rather than plannable on a roadmap.
  • Make experiments cheap enough to lose. Every reduction in the cost of experiments raises the number of draws you get.
  • Instrument adoption, and let it overrule opinion. Data about experiments is collected, visible, and permitted to win an argument against positional authority.
  • Celebrate throwing out what doesn't work. If throwing away working code reads as wasted budget, teams will defend obsolete work.
  • Protect the person who brings the unexpected thing. Westrum's "messengers are trained" is the highest-leverage item on the list, because a single punished messenger teaches a room of people to stop reporting.

The tension worth naming

Organizations need predictable delivery. Customers have contracts, partners have integration dates, and the finance function needs to know what it's buying. A leadership posture built around unschedulable emergence sits in genuine tension with all of that.

I don't think the tension dissolves. I think it gets allocated. Some portion of the portfolio is complicated work that should be planned, committed, and executed conventionally — and conventional leadership is genuinely better at it. Some portion is complex work where the honest commitment is to a rate of experimentation and a quality of learning, not to an outcome on a date. Most of the dysfunction I've seen comes from applying the wrong regime to the wrong portion, and trying to plan the unplannable.

Sources