R&D: Innovating Without Betting the Company

Why a Company That Only Executes Slowly Dies

A well-run roadmap is a machine for optimizing the known. Every item on it exists because a customer asked, a metric sagged, or a competitor moved. That machine is essential — it's most of what engineering does, and it should be. But it has a structural blind spot: the roadmap can only harvest opportunities somebody already identified. It cannot discover the opportunity that doesn't have a ticket yet.

Companies that only execute compound their current advantage until the ground shifts under it. The shift never announces itself as a roadmap item. It shows up as a weird new technology, an odd customer behavior, a startup doing something that looks like a toy. By the time it's obvious enough to make the roadmap, the companies that explored early have a two-year head start. This is the standard arc of the disrupted incumbent: not killed by bad execution, but by flawless execution of a plan that stopped mattering.

R&D is the deliberate counterweight. It is the fraction of your engineering capacity pointed at questions instead of tickets: what's becoming possible, what are customers going to want before they know it, which of our assumptions is quietly expiring. The output of R&D is not features. It is validated knowledge that funds the next roadmap.

And the balance between the two machines — execution and exploration — is owned by exactly one person: the CTO. Product will always pull toward the committed roadmap, because that's their job. Sales will always pull toward the deal on the table, because that's theirs. If the CTO doesn't explicitly defend exploration capacity, it gets reallocated to whatever is loudest this quarter, every quarter, forever. Nobody else in the building is paid to care about the year after next.

R&D and the God Product

This board keeps coming back to the God Product — the grand, multi-year vision that everything you ship is supposed to be a step toward. R&D is the vision's reality-testing arm, in two directions.

• Downward, it tests assumptions. Every grand vision rests on a stack of load-bearing beliefs: this data will be good enough, this workflow can be automated, customers will trust a system to do this. Roadmap work quietly assumes these are true. R&D is where you cheaply find out — before you've built three quarters of product on top of a belief that was false.
• Upward, it discovers primitives. The God Product almost always needs capabilities that don't exist in your stack yet — a matching engine, a real-time layer, an evaluation harness. Exploration is how you find out which primitives are feasible, which are cheap, and which will take a year of groundwork you'd better start now.

Put bluntly: without R&D, the God Product is a pitch deck. Exploration is what converts it, assumption by assumption, into an engineering plan.

The Innovation Portfolio

The classic mistake is treating innovation as a mood — you explore when things feel calm and stop when things feel busy. Things never feel calm. The fix is to treat exploration like a portfolio allocation: an explicit percentage, defended like any other budget line, rebalanced deliberately rather than by whoever shouted last.

70 / 20 / 10

The best-known allocation, popularized by Google and by Bansi Nagji and Geoff Tuff's innovation research, splits investment three ways:

The companion time-framing is McKinsey's Three Horizons: Horizon 1 is the current business you defend and extend, Horizon 2 is the emerging opportunities you're scaling, Horizon 3 is the options you're creating for the future. Different axis, same discipline — money and attention explicitly split across now, next, and later.

The Honest Critique

Be honest about the limits of both frameworks, because a sophisticated interviewer will be. The Horizons model was born in an era when "Horizon 3" meant a decade out. In software — especially in the AI era — the horizons compress and blur: a transformational technology can become table stakes in eighteen months, and yesterday's Horizon 3 moonshot is suddenly a Horizon 1 emergency. Treating the ratios or the timelines as gospel is cargo-culting.

What survives the critique is the underlying discipline: explicit allocation beats implicit allocation, every time. The exact numbers matter far less than the fact that you chose them, wrote them down, and can see when reality drifts from the plan. A company with a declared 85/10/5 split it actually honors is in vastly better shape than one nodding at 70/20/10 while actually running 100/0/0 — which is what every company runs by default under delivery pressure.

The Small-Company Version

At Hireboard's scale you don't have a research division; you have a handful of engineers and a roadmap that already doesn't fit. Two rules make the portfolio real anyway:

• Even one engineer-day a week beats zero. The failure mode isn't a small allocation — it's a null one. A single deliberate, protected day of exploration per week compounds into dozens of answered questions a year. Zero compounds into a company that's surprised by everything.
• Concentrate transformational bets — don't peanut-butter them. Spreading 10% across five simultaneous moonshots gives each one too little oxygen to reach a real answer, so you pay full price for the distraction and get zero knowledge back. One transformational bet at a time, pursued until its kill criteria fire or it earns promotion, then the next.

The R&D Toolkit, Cheapest First

R&D spending has a golden rule: buy knowledge with the cheapest instrument that can deliver it. The toolkit below is ordered by cost. Start at the top and only move down when the cheaper tool can't answer the question.

1. Timeboxed Spikes

A spike is the atom of R&D. It has exactly three parts: a question ("can our matching latency survive 10x candidate volume?"), a timebox (a day, two days, a week — declared up front), and a written answer shared with the team when the timebox expires. The deliverable is knowledge, not code. Spike code is scaffolding — it exists to produce the answer and has no life expectancy beyond it.

The written answer is non-negotiable, and it's the part teams skip. A spike that ends with "yeah, it basically works" muttered in standup has produced tribal knowledge in one head. A spike that ends with half a page — question, what we tried, what we learned, what we'd recommend — has produced an asset the whole company can search, cite, and build on. If it isn't written down, the spike didn't happen.

2. Prototypes

When the question is too big for a spike — "would recruiters actually use an AI-drafted outreach flow?" — you build a prototype. A prototype is built to learn, and it is destined for the bin. That destiny is a feature: because it will be thrown away, you're allowed to hardcode, skip auth, fake the backend, and ignore every edge case. That's what makes it ten times cheaper than the real thing, which is the entire point.

Which brings us to the cardinal sin of R&D, and it deserves to be said loudly: the cardinal sin is shipping the prototype. The demo goes well, a customer sees it, sales smells revenue, and suddenly the thing you built in nine days with no tests, no error handling, and a hardcoded auth token is in production with paying users on it. Every shortcut that made it cheap to build now makes it ruinous to operate. You will spend the next two years paying interest on a loan you never meant to take out — and the team that maintains it will know exactly whose demo did this to them.

3. Pilots with Friendly Clients

Some questions only real usage can answer — will this survive contact with actual recruiter workflows, actual data, actual Monday mornings? That's a pilot: a properly-built (not prototype!) slice of the idea, run with one or two friendly clients under explicit expectations. Explicit means written: this is an experiment, here's what we're testing, here's the review date, and it may be changed or killed at the end. A pilot without that framing isn't an experiment — it's an unannounced product launch to your most forgiving customer, and killing it later becomes a customer-relations incident instead of a calendar entry.

4. The Walking Skeleton

For architecture bets — a new pipeline, an event-driven rewrite, a multi-region story — the tool is the walking skeleton: the thinnest possible end-to-end implementation that touches every real layer of the system. No features, no polish, but a genuine request flowing through every genuine component in a production-like environment. It answers the question prototypes can't: not "can this work in isolation?" but "do these pieces actually connect, deploy, and survive together?" Architecture risk lives in the seams, and the skeleton is the cheapest way to test every seam at once.

Kill Criteria: Decide the Ending First

Every instrument above shares one requirement: declare the kill criteria before you start. Before the spike begins, write down what result would mean "stop" — latency above X, accuracy below Y, integration effort beyond Z weeks, fewer than N pilot users actually engaging.

The reason is human, not procedural. Once a bet is running, it has an owner, and the owner has hope, sunk time, and an identity stake in it. Asking "should we kill this?" mid-flight makes the answer a referendum on a colleague's judgment — so nobody asks, and the bet shambles on. Kill criteria declared in advance turn the ending into a decision that was already made, by a calmer version of the same people, before anyone had anything to defend. The criteria fire, the bet ends, nobody lost a fight — because there was no fight.

Innovation Tokens: Choose Boring Technology

Exploration in what you build is a portfolio decision. Exploration in what you build on — languages, databases, queues, frameworks — needs a much tighter leash, and the house doctrine here is Dan McKinley's "Choose Boring Technology." The core claim: a company can sustain roughly three innovation tokens — three deliberate uses of novel, unproven-to-you technology — at any one time. Each novel choice costs you in ways that don't show up in the demo: unknown failure modes, thin documentation, no in-house operational experience, 3 a.m. pages with no runbook and no Stack Overflow thread.

Boring technology — Postgres, Redis, the framework your team has shipped with for years — is boring precisely because its failure modes are famous. You know how it breaks, and so does every engineer you'll ever hire. That knowledge is an asset you throw away every time you pick something shiny.

The corollary that makes this a strategy rather than a prohibition: spend your tokens on your differentiators, never on plumbing. Hireboard's edge is in matching, evaluation, and hiring workflow intelligence — novel technology there can create moat. Nobody chooses us for our queue. The classic failure is the team that adopts a new database, a new queue, and a new framework in the same quarter — three tokens torched on infrastructure nobody pays us for, zero left for the product itself, and every incident now a multi-way mystery across three systems nobody deeply knows.

The Adoption Ladder

When a new technology does earn consideration, it climbs a ladder — one rung at a time, with an exit available at every rung:

The ladder's value is that every rung is a real decision point with cheap exits early and expensive exits late. Teams in trouble are almost always teams that jumped from rung one to rung five — from a conference talk to a production default — in a single enthusiastic quarter.

The LLM-Era Note

The AI wave doesn't repeal any of this — it compresses the clock. The same ladder applies; you just climb it faster and revisit it more often, because the technology under evaluation improves quarterly. Two failure modes now bracket every engineering org, and both are strategic errors:

• Ignoring the wave — treating LLMs as a fad while competitors compress workflows you charge money for. For a hiring platform, pretending AI won't reshape sourcing, screening, and matching isn't conservatism; it's negligence.
• Rewriting everything for it — bolting an agent onto every feature, adopting a new AI framework per quarter, and burning every token in the drawer on infrastructure that will be obsolete before it's stable.

The CTO's posture: evaluate seriously, adopt deliberately. Standing spike capacity pointed at AI capabilities — always be at rung two with whatever's newest — combined with real discipline about what reaches rung four. You want to be early with knowledge and deliberate with dependencies.

Measuring R&D Without Killing It

Here is the paradox that ruins most measurement attempts: R&D fails most of the time by design. If most of your bets succeed, you aren't exploring — you're executing safe work and calling it research. So the moment you measure R&D with delivery metrics — features shipped, bets that "paid off" — you teach the team to only propose sure things, and the exploration function quietly dies while its budget line lives on.

Measure learning velocity instead: questions definitively answered per quarter, and bets killed fast. A quarter where you cheaply learned that three promising directions are dead ends is a successful R&D quarter — three roads your roadmap will now never waste a team on. The kill count is a feature of the metric, not a bug: a healthy portfolio kills most of what it starts, quickly, and writes down why.

The Three Failure Modes

• The prestige playground. R&D disconnects from strategy and becomes where clever people do interesting work that never touches the business. The tell: nobody can say which God Product assumption a given bet is testing. Fascinating demos, zero promotions to roadmap, year after year.
• The euphemism backlog. "R&D time" becomes cover for the backlog's fun items — the refactor someone always wanted, the tooling pet project. It's execution wearing a lab coat: no question, no kill criteria, no new knowledge. Fine work, wrong budget — and it silently displaces the actual exploration.
• The zombie project. The bet that neither dies nor ships. Its kill criteria were never declared (or fired and were ignored), its owner still believes, and each quarter it absorbs just enough capacity to survive. Zombies are the most expensive failure mode, because they consume exploration budget while producing neither knowledge nor product — the seat at the table that a live question should be occupying.

The Quarterly R&D Review

The instrument that keeps the portfolio honest is a quarterly review, one hour, four questions — asked in this order:

• What did we learn? Answered questions, with the write-ups to prove it. This comes first because it's the actual product of R&D.
• What got promoted? Which validated bets earned a real place on the roadmap — the pipeline delivering.
• What did we kill, and how fast? Slow kills get a postmortem on the process, not the people.
• What do we bet next? New questions, tied explicitly to a God Product assumption or an emerging threat, with kill criteria attached before the meeting ends.

Run honestly, this review is also your zombie detector: any project that appears three quarters running with no answer, no promotion, and no kill is, by definition, undead — and the review is where it finally gets one of the two endings it's been avoiding.

Making Exploration Safe

Every mechanism in this module — portfolios, spikes, kill criteria, reviews — runs on one cultural input: engineers must believe that a well-run bet that fails is good for their standing, not a mark against it. If failure is punished, your people will only propose sure things, your "R&D" will become the euphemism backlog within two quarters, and no process document will stop it. Culture here isn't a soft add-on to the system; it is the system's power supply. Four practices do most of the work:

Hack Days Leadership Actually Attends

Hack days and hack weeks are the broadest, cheapest exploration instrument — every engineer, pointed at anything, for a bounded time. But their value tracks one variable almost perfectly: whether leadership shows up. When the CTO and CEO sit through demos, ask real questions, and visibly pull ideas into the pipeline, hack days are R&D. When leadership skips them, the team learns within two cycles that exploration is decorative — recess before real work resumes — and the best people stop bringing their best ideas. Attendance is the signal; everything else is logistics.

Spike Write-Ups Shared Publicly

Every spike's written answer goes to a public channel — the same overcommunication doctrine from the communication board, applied to research. Public write-ups compound three ways: the knowledge becomes searchable instead of tribal, the next engineer doesn't re-run last year's dead end, and — subtlest but most important — negative results get normalized. A steady public stream of "we tried it, here's why no" teaches everyone that answering a question in the negative is a contribution, not a confession. That norm is what makes the next practice possible.

Celebrate Well-Run Kills as Loudly as Ships

When a bet hits its kill criteria and dies on schedule, announce it with the same energy as a launch — because it is a save. The engineer who killed a bet in two weeks that would otherwise have consumed two quarters just saved you engineer-years; the only reason it doesn't feel that way is that the saved quarters are invisible. Make them visible: name the kill, name the reason, name the savings, thank the person who called it. Do the math out loud in the team channel. Engineers watch very carefully what actually gets celebrated — not what the values doc says — and they calibrate their risk appetite to the applause, not the poster.

Postmortem the Bets That Ran Too Long

The failure worth examining isn't the bet that failed — that's the system working. It's the bet that ran two quarters past its answer. Those get a blameless postmortem aimed at the mechanism: were kill criteria declared? Did they fire and get ignored? Was there social pressure not to call it? The output is a process fix, never a culprit — the same blameless discipline you'd apply to an outage, because a zombie project is an outage of the decision-making system.

Knowledge Check

Five scenarios. Answer as the CTO — the goal is the judgment call that protects both this quarter and the year after next.