Contronyms
Last year I remarked that pilot projects are contronyms that become a corporate fait accompli the moment they’re given the name. Now that I’ve got a few more pilots under my belt, I have cause to revisit my thoughts!
Here’s some intuition for the argument. For one thing, pilots often require just as much investment as full-scale projects in many cost centres — you only save on scaling, and your sunk costs don’t know that your pilot is a pilot. Second, the non-pecuniary cost of spinning up a pilot project can be big enough that you might be politically exposed if it’s shuttered too quickly. In this sense, the pilot is not actually the instantiation of a new idea intended to sway an on-the-fence executive, but rather the result of their approval. So you should expect that many pilots will live on, at worst considered a qualified success.
But you might object that you’ve seen pilot projects fail before, and of course they do! So what’s going on here?
What ends up being load-bearing here is the word “pilot”, not the actual project it was intended to represent. This is due to a decrease in accountability that follows from the contronym observation: if your pilot ends up failing, it’s not because it was a bad idea. No, it comes to fail because it was a pilot — we just didn’t fund it properly, or the market conditions weren’t right, &c &c. In other words, we are making something like a promise,Footnote 1Illocutionary act (opens in new tab) (archived Jun 2026). perhaps a promise to displace accountability onto the project, when we call our work a “pilot”. This kind of scapegoat pilot conveniently decouples failure from the quality of the idea that spawned it. This renders the root cause of success illegible to the system. And as we’ll see, that illegibility can cut both ways.
But the main problem here, and one reason I suspect so many people are uncomfortable with this kind of spin, is that failure is supposed to be legible so that it generates information! As Reinertsen says in The Principles of Product Development Flow:
… most companies do a far better job of communicating their successes than their failures. They carefully document successes, but fail to document failures. This can cause them to repeat the same failures. Repeating the same failures is waste, because it generates no new information. Only new failures generate information.
New failures are legible failures. But reaping the upside of those failures is contingent on running your pilot the right way. How might we interact within such a system? I’d start by considering how optionality and accountability interact. Low-optionality, low-accountability projects aren’t terribly interesting for our purposes,They need to exist — you’ll always need someone answering the phones, so to speak — but they’re easy enough to operationalize without a pilot. and neither are the kind of high-optionality, high-accountability projects that lend themselves to founder-mode strategic plans.
More interesting are high-optionality, low-accountability situations, where there’s little need for a pilot’s political cushioning, although you might run one anyway as an experiment.More on this later. Likewise, low-optionality, high-accountability projects are must-win situations that require escape routes. Pilots can play that role, although they might take you in multiple directions.
Pilots as hedges
If you believe the contronym theory, the adverse outcomes of hedges should be easy to spot because they direct us toward lower accountability. There, the illegibility of failure blurs the distinction between learning that something doesn’t work and declining to try at all. So the curse of the hedged pilot is its inversion of experiment logic: it ensures that we learn as little as possible. It’s kind of like an anti-trial balloon: instead of leaking an idea to see if it has popular support, we launch a pilot to avoid the tough conversation about its validity.Some domain precision is required here, as you’ll be less likely to see this problem if your pilot costs real money or stakes your company’s reputation. In the realm of public choice though… Trial balloons may feel duplicitous for good reason, but at least they help test your Overton window. Pilots-as-hedges do the opposite and never manage to get off the ground.
It would be convenient if we could somehow induce organizations to index on the visibility of results. But if the point of a hedged pilot is its illegibility, then we should expect pushback.Footnote 2À la Peter Senge: the harder you push, the harder the system pushes back. On some level, the system is following the process for its own sake, not because it represents an objectively good or prosocial idea. It then becomes progressively more rational for individuals to select for illegibility and hedge their pilots, even as it harms the org’s ability to complete the causal loop and generate new information from its failures. This leads to a tragedy of the commons, where your entire organization’s legibility decreases monotonically as individual hedgers siphon off limited resources for personal gain. This all leads us to a liminal space where good experimentation is designed to fail often, but the experimental vehicle displaces failure entirely.
Pilots as experiments
But there’s also a way to increase your options without hedging. The obvious counter is the experimental pilot. Implementation details are pretty straightforward if you think about how a typical experiment or RCT is run. If we’d preregister our data analysis plan, we’ll also preregister our pilot’s evaluation criteria, failure conditions, and stopping rules. Likewise, we might borrow from power analysis by calculating the sample size required to detect whether our pilot had a practically significant effect. I’ve never seen pilots do this! They’ll often timebox their pilots based on calendar deadlines, not on whether the scope would produce a detectable and falsifiable signal by then. But it’s an easy fix. Finally, even if an experiment doesn’t generate enough evidence to discard the null hypothesis,Let’s ignore the problems with NHST long enough for my point to land. we’ve still learned something. Maybe we can’t publish it in an academic journal, but it’s probably suitable for an internal wiki.
This is all well and good, but if hedged pilots are the equilibrium of a tragedy of the commons, then you won’t get much buy-in for an experimental approach that would disrupt your peers’ local maximum. How do we move past this? One interesting thing about experiments is that they’re often blinded — we deliberately withhold information sharing to reduce bias. What I’m going to suggest is organizational heterodoxy, but what if we siloed pilots similarly?The comparison isn’t quite one-to-one here; blinding is about preventing bias in measurement, whereas silos arise due to decoupled ownership. But they both impose information boundaries that lead to thematically similar outcomes.
“Throwing it over the wall” is a known antipattern in DevOps. It’s now considered bad form to hand work over to another team without context, design details, or an attuned sense of why we’re solving a problem this way. But what if the wall is a feature for pilots, not a bug? You literally can’t deploy a pilot if you have to throw it over the wall to someone else! And this forces the kind of experiment-driven conversation I mentioned earlier: naturally you’ll start discussing with the downstream team, who will no doubt want to hammer out evaluation criteria and the like. In Team Topologies terms, you’d probably want to run your pilot within an enabling team because of their timeboxed interaction pattern. And this often beats the counterfactual; when a stream-aligned team runs a pilot, they also own production, which incentivizes the hedge. This means that you bypass the tragedy of the commons problem entirely, because you don’t need to dip into social capital reserves to implement within your division’s own enabling team.
Pilots as speech acts
Throwing projects over the wall is a structural org-chart-level move. But when teams start their discussions, they’re back in language territory, and that suggests a linguistic gloss on the approach, by way of felicity conditions (opens in new tab). In short, I cannot give you a watch merely by pronouncing “I bequeath you my JLC Reverso”, because several conditions must also hold beyond the utterance itself. For instance, I must actually own the watch I intend to bequeath.I’m really doing it to myself with this example.
You likely have a mental model for what I mean by an experiment, and all writing assumes that your model overlaps enough with mine for meaning to survive transmission. But if that were ever in doubt — for example if you began to suspect that a team’s “experiments” were in fact a pretext that served to hide self-dealing or personal enrichment — it would be doubly important to sketch the boundary conditions of the word experiment, to give examples of what an experiment is and isn’t, and so on. This is precisely the definitional game we can play with pilot projects to ensure they remain unhedged. If a watch can only be bequeathed while owned, then perhaps by analogy a project can only be a pilot if it is practically reversible. Those are both conditions of circumstance, but there are other relevant ones, such as the preparatory conditions — if your boss okays every project that lands in their inbox, then your request to approve a pilot project can hardly be said to be felicitous. When we are able to ask felicity-underpinning questions at the governance table, projects that can’t be undone or that would always have been approved cease to be pilots, which strips the word of its troublesome contronym property and sets the stage for system legibility.
You might object that an organization running on illegibility may not openly permit such questions in the first place. And that’s probably true! A good example of this prohibition is the board meeting. It’s tempting to read the discussion linearly as it’s recounted in the minutes, as if the meeting were the critical inflection point for a project. But the questions, the conversation, the points to register, these are all better read as the dénouement of prior discussion and agreement that the presenters necessarily can’t see.If this seems like too cynical a reading, consider that many mystery stories end exactly this way. When the detective reveals the killer, the real deductive work has usually already happened off-screen or off-page, making the revelation more of a ritualized performance than anything else. But when stacked with the wall-throwing approach, we can relocate the question from the governance meeting, where such questions are unaskable, to a handoff, where they’ll arise naturally. This still requires that the receiving team have authority to govern its own roadmap, but that’s a much smaller ask than rewriting the legibility conditions for an entire organization.
So yes, pilots are often contronyms, but only insofar as your org naturally selects for hedges. Throwing your projects over the wall and taking care to define them felicitously can cut through the inertia-hedge and make the word mean what it’s supposed to.