Ways research teams fail | Antithesis Bug Bash is coming to Copenhagen this fall!Learn more

August 18, 2026 | Serdar Benderli , Engineering Manager<br>Ways research teams fail

Serdar Benderli Engineering Manager

In this post

1. Direction failures<br>2. Execution failures<br>3. Knowledge failures<br>4. Organizational failures<br>5. Structural failures

The latest from antithesis

The latest

Monthly reliability and distributed systems news, curated for teams<br>building critical software.

Please enable JavaScript in your browser to load and submit this form.

Thanks — you're subscribed.

Something went wrong. Please try again.

I lead the research team at Antithesis. What follows is my mental model of how research teams fail: a taxonomy of failure modes. I’ve observed many firsthand, read or heard about others, and caused a few myself. Having a systematic way to think about them has been helpful for putting practices in place to mitigate them, though this post is only about the failure modes themselves.<br>I wanted to share them because I think they’re general enough to apply to any research team inside a broader organization, and specific enough that you can design responses of your own.

1. Direction failures

Working on the wrong things.

Customer disconnect: Optimizing for measurements, or pursuing intellectual curiosities without knowing or caring about actual customer needs, producing work no-one cares about or finds useful.

Customer overfitting: The opposite failure. Solving one customer’s problem so specifically that the solution doesn’t generalize across the business. The work ships, but only one customer benefits.

Tunnel vision: Framing a project by its solution space (“use AI to improve caching”) rather than by an outcome or benchmark (“improve performance on B”). A solution-space framing has no natural exit: if the approach doesn’t work, there’s no signal to stop, and the team can’t pivot to an adjacent win it stumbles into. Outcome-framed projects leave room for serendipity, where work on problem X reveals a shippable solution to related problem Y.

No kill-switch: Without explicit kill criteria, projects out-live their usefulness but continue to drain time and energy due to sunk-cost fallacy.

Moonshot drift: Projects expand in scope and ambition towards interesting rather than useful, and time horizons creep outwards. Horizons for work that was mid-term becomes long-term, then indefinite, and the team loses connection with the product.

Portfolio concentration: All active projects share the same underlying assumptions, and when that assumption turns out to be wrong, all efforts fail at once. Even if projects individually are not risky, the portfolio as a whole is.

2. Execution failures

Working on the right things, badly.

No measurement discipline: Progress can only be described qualitatively, in vibes, rather than numbers. Without a fixed baseline and a benchmark, improvements, trade-offs, and regressions cannot be verified or compared across configurations, and opinions replace evidence.

Measurements as gospel: The counterpoint. Measurements are proxies for customer success, but not customer success itself. A team that forgets this fact optimizes the metric instead of the underlying thing the metric was meant to capture, and ships work that moves numbers without moving the business.

Blurry phases: Projects don’t reach a clear conclusion. Phases of a project blend into each other without explicit gates. Findings don’t crystallize into artifacts that would otherwise serve as gate-keepers. Team is always “almost done” but never actually done with a project.

Unshipped work: Research produces knowledge, prototypes, and findings that never become product capabilities. A common pattern is chasing the perfect solution past the point where an imperfect version is already shippable, with the next improvement always close enough to justify holding back. Other times the work is simply never handed off. Either way, the value never compounds because the work never reaches the product.

Failure to support: Research hands artifacts off and disengages. Without ongoing engagement after the handoff, those who inherit the work are left to figure out something the team knows more about than they do, and the relationship between research and the rest of the company erodes one handoff at a time. Since the team understands these capabilities better than anyone, they should remain their steward.

3. Knowledge failures

Knowledge that doesn’t compound.

Institutional amnesia: Findings, decisions, and hard-won insights live in people’s minds rather than in permanent artifacts. When people leave or move to another project, the knowledge leaves with them.

Rediscovering dead-ends: Negative results and failures are especially likely to go undocumented, because nobody wants to write up something that didn’t work. So we re-explore them and pay the cost again.

Inert knowledge: Even when findings are written down, the corpus isn’t...