"No word makes me sweat at night more than that word." Idan Gazit, who leads GitHub Next — GitHub's innovation lab inside Microsoft — was talking about the hand-off. The moment when a successful prototype leaves the lab and enters the main engineering organization for production development.
In his words: "This is where the bodies are married."
The Pattern That Kills Innovation
Here's how it typically goes. An innovation team builds something promising. Leadership sees the demo and gets excited. "We love it. Go, run fast, run far, go to market. Here's three engineering teams to help you."
"That's usually when the project dies," Idan said.
Why? Because the engineering teams coming in to take over the project come from a different world. They come from an engineering and product environment with established processes, established ways of doing things. They're going to impose a process and a mindset that maybe doesn't make sense for a new product category that hasn't been tried before.
"And then with the best of intentions, in the process of adoption — oops, the baby died."
Why This Happens
Idan was careful to note: nobody has bad intentions. The road to dead innovation is paved with good intentions. The problem is structural:
1. Context loss. In the early phases of a product, only you and your small team truly understand it. You know why certain decisions were made, which assumptions are fragile, which parts are held together with duct tape that shouldn't be ripped off yet. The people inheriting the project don't have that context.
2. Process mismatch. A prototype that's finding product-market fit needs different processes than a product that's scaling. Standard engineering practices — sprint planning, code review standards, security audits, accessibility requirements — are essential for production software. But applying them too early can kill the speed and experimentation that made the prototype successful.
3. Ownership diffusion. When one small team owns a prototype, accountability is clear. When three engineering teams take over, nobody feels the same level of ownership. The passionate weirdness that made the thing work gets smoothed out by committee.
How GitHub Next Navigates It
GitHub Next's approach is to maintain control through the critical early stages. They don't hand off a slide deck — they hand off a working thing with the team that built it.
Their innovation process works in expanding circles:
1. Thursday demo day. People show what they've built. The first signal: does this excite others in the room? If three people say "yeah, let's do that" — continue.
2. Extend, don't hand off. Give the project a few more weeks. Build the next stage. Try it on other people at GitHub.
3. Expand the circle. Try it on design partners outside GitHub. Get real-world data and feedback.
4. Build the evidence. Only go to leadership when you can say: "Here's a bet we should make, here's why we should make it, and here's a working prototype that proves it."
The key principle: the people who built the prototype should shepherd it as far into production as possible. The hand-off should be gradual, not a clean break.
The Hiring Philosophy That Prevents It
Idan's hiring approach is directly tied to this problem. He doesn't hire researchers who write papers — he hires makers who build things.
"At the end of the day, there's a lot of people with philosophers bearing Google Docs. And that doesn't not have value, but nothing speaks like a prototype."
Everyone on the team is what he calls a hybrid — someone who can do product thinking, engineering, and design. "Every soldier, a general." Each person is an independent operator who can credibly advance the state of the art on their own.
The key quality he looks for: "If I leave you alone for five minutes, do you make something?" If the answer is yes, that person can shepherd a project through the hand-off because they deeply understand every layer of what they built.
The Insurance Policy Approach
One more framing that stuck with me. Idan described GitHub Next's role as betting 1% of the business on insuring the other 99%. They're not trying to build the next big product — they're trying to figure out what might disrupt the existing business in 1-5 years and get ahead of it.
"Because our customers are not asking for this. They're asking for fixes to the stuff that's broken in our product today."
This reframes corporate innovation from "shiny new thing" to "existential risk mitigation." And the hand-off problem becomes not just a project management challenge, but a survival question: can the organization actually adopt its own innovations before a competitor does?
The Takeaway
If you're building something new inside an existing organization — or if you're the person receiving a hand-off from an innovation team — the lessons are clear:
- **Prototype with the people who will build it.** Or at minimum, keep the prototype team involved deeply through the production transition.
- Resist the urge to normalize too early. Standard processes exist for good reasons, but applying them at the wrong stage kills more innovations than bad ideas do.
- Transfer context, not just code. The most important thing to hand off isn't the repository — it's the reasoning behind every decision in it.
- Bet small, learn fast. GitHub Next doesn't staff projects for six months. They give things a few weeks, evaluate, and extend or kill based on evidence.
Innovation isn't hard because of a lack of ideas. It's hard because organizations struggle to adopt their own best ideas. The hand-off is where that struggle lives.