Why internal innovation labs fail, and the narrower structure that tends to work

The central idea

Innovation labs rarely fail at invention. They fail at transfer, because nothing in the structure obliges a receiving business unit to accept what the lab built.

The standard design separates the lab from the core: different location, different process, different hiring, protected budget. Every one of those choices is defensible on its own terms, and together they produce an organisation whose output the core cannot absorb. The lab's work arrives without the operational scaffolding a business unit needs — no on-call rota, no support model, no place in anyone's objectives — and the unit is asked to adopt it on top of a plan that was set before the lab existed.

What changed, and why it matters now

The pattern shows in the artefacts. Labs produce prototypes, demo days, and press coverage in abundance, and produce handover documents rarely. When a lab is asked how many of its projects are running in a business unit two years later, the answer is usually small and often unknown, because nobody instrumented the transfer. Meanwhile the receiving unit's leaders can generally name the reason instantly: it was not in their targets, it added a support burden they were not funded for, and no one senior enough required them to take it.

Build the operating model

Fund the receiving unit, not only the lab, and make transfer a condition of the lab's own budget rather than an aspiration in its charter.

The practical mechanism is a named receiving owner from the first week — before the work is built, not after — with an explicit allocation for the operational cost of adoption. That allocation is what makes acceptance rational. Without it, a unit head is being asked to absorb ongoing support cost against fixed targets, and declining is the correct decision from where they sit. Most lab failures reduce to asking people to behave irrationally within their own incentives and then describing the refusal as cultural resistance.

Measure what the decision produced

Measure the proportion of projects running in a business unit twelve months after handover, the support cost the unit absorbed, and the time from prototype to first production use.

Twelve-month survival in the core is the only measure that cannot be gamed by activity. Count projects still running under a business owner with real users, not those technically alive on a lab-maintained server. Time-to-first-production-use is the leading indicator: when it exceeds a year the lab has drifted into research, which may be legitimate but should be funded and judged as research rather than reported as innovation delivery.

Where execution breaks

The visible risk is innovation theatre. The structural one is a lab that optimises for the metrics it controls — projects started, demos run — because those are the only numbers it can move alone.

A related failure is talent asymmetry. Labs recruit for novelty and the core retains people who know how the business actually runs, so the two groups have no shared operating vocabulary. Rotation is the usual remedy and it is usually done in one direction, seconding core staff into the lab. The direction that matters more is the reverse: lab engineers spending a quarter inside the receiving unit, on its rota, discovering what its constraints actually are. That experience changes what gets built far more than any handover template.

What this looks like in practice

The structures that work tend to be narrower and less autonomous than the word lab implies. A small team, a mandate limited to two or three problem areas that a named unit has already said it owns, a receiving owner from day one, and a budget line inside that unit rather than beside it. It generates less news coverage. It also produces things that are still running in two years, which is the only output that compounds. The staffing follows from the mandate rather than the other way round. A lab with two named problem areas needs people who can work inside the constraints of the units that own them, which usually means hiring for operational experience alongside technical range. Labs staffed purely for novelty tend to produce work that is technically interesting and operationally unadoptable, and the mismatch is set at the point of hiring rather than discovered at handover. There is also a reporting line question that decides more than the org chart suggests. A lab reporting to a corporate centre optimises for narrative, because that is what its reader consumes; one reporting jointly to the units it serves optimises for adoption, because those readers have to live with the output. Neither arrangement is neutral, and the choice is usually made for convenience rather than as the strategic decision it turns out to be.

The strongest argument against this

The genuine argument for separation is that core business units cannot pursue work that threatens their own economics, and a lab embedded inside one will be quietly starved whenever its output competes with the existing product. Real disruption needs distance from the P&L it might damage, and every structural tie proposed here is also a mechanism by which the core can suppress inconvenient work.

That argument is correct for a specific and uncommon case: work that is genuinely substitutive for the current business. Most lab portfolios are not that. They are adjacent improvements described in disruptive language, and applying the separation model to them buys distance that nothing needs while paying the transfer cost that everything does. The test is whether a business unit would be worse off if the work succeeded. If the answer is no, the case for separation is weaker than it sounds.

A 30-day implementation sequence

Name a receiving owner and an adoption budget for every active project this quarter, and stop any project that cannot find one.

Weeks one and two, audit the portfolio and record for each project who would receive it and whether they know. Weeks three and four, meet each candidate owner and establish what adoption would cost them in support and staffing. Week five, fund those costs explicitly or close the project — the closures are the point of the exercise. Week six onward, run remaining work with the receiving owner in the weekly review, not in a quarterly showcase.

Report survival in the core, not activity in the lab

Maintain one table listing every project, its receiving owner, its transfer date, and its status twelve months later. Publish it internally without commentary. The table is uncomfortable for the first two cycles and then becomes the most useful governance artefact the function has, because it changes what people propose: work with no plausible owner stops being started once the absence of one is visible before funding rather than discovered after it.

Review the portfolio monthly against transfer readiness and annually against twelve-month survival. Resist quarterly demo days as the primary forum — they select for what shows well, which is the original failure. If a showcase is politically necessary, hold it, but make the survival table the document that decides next year's budget.

Editorial conclusion

The question worth asking of an innovation function is not what it built. It is what the rest of the organisation is still running because of it. Labs designed around that question tend to look smaller, less independent, and considerably less exciting than the ones that are remembered mainly for their demo days.