The quarterly innovation sprint: what you’re leaving on the table

Every quarter at Rosetta Stone, the entire engineering organization flew in.

As a fully remote company, getting engineers in the same room was rare and deliberately timed. At the end of each quarter, as that cycle’s software moved into testing and validation, the team gathered at a hotel conference room for quarterly planning. Product owners were there to break down features for the next cycle. Engineers were there to help define and estimate the work ahead.

And for two weeks, they were there to build whatever they wanted.

Rosetta Stone called it an innovation sprint. Engineers paired with people outside their normal teams, worked on projects unrelated to their daily responsibilities, and built software they’d been wanting to build. The quarterly planning calendar created a natural seam — product was deep in vetting the next cycle, delivery was in validation, and the machines were largely running themselves. The sprint filled that seam.

Some of what got built shipped. Some didn’t. All of it mattered.

1. 2 weeksEach quarter, at the seam between planning and delivery.
2. 1 weekThe Fanatics trial, and the only round leadership approved.
3. 2 quartersHow long the return took to show up after each sprint.

What a conference room can surface.

One of my engineers was quiet in meetings. Not disengaged — just the kind of person who needed to be called on to speak, who defaulted to listening when the room was loud. I knew he was sharp. His peers knew it too. But in a distributed team, the loudest voices tend to fill the space.

During the quarterly planning sprint, something shifted. He’d found a project he cared about, found a partner on another team, and suddenly he was moving through the conference room with a purpose I hadn’t seen before. By the end of the sprint he’d built new connections, shipped a prototype, and walked into the next quarter visibly different. The sprint didn’t make him into someone he wasn’t. It gave him the conditions to be more fully who he already was.

Guardrail-free time with a purpose reveals people. That alone is worth the investment.

Why the timing mattered.

The Rosetta Stone model worked partly because of when it happened. The sprint wasn’t stolen from active delivery. It sat in the genuine transition between quarters — the weeks where the work is mostly validation and transition, not building. Product used the time to sharpen the next cycle. Engineering used it to explore.

That’s a different ask than “stop shipping for two weeks.” The sprint wasn’t a pause; it was a fill. The delivery machine kept running. The engineers just weren’t the ones running it at that moment.

This is worth noting to any leader who instinctively recoils at the idea: the question is not whether you can afford two weeks away from the roadmap. It’s whether you’ve structured your quarters so that two weeks at the seam are genuinely low-cost. Rosetta Stone had. The sprint was a symptom of good quarterly planning, not a risk to it.

Guardrails are the biggest mistake.

Engineers were explicitly encouraged to work outside their product area. The goal was cross-pollination, not incremental roadmap progress. Spending all day every day on a product gives you a particular kind of insight — you see usability problems, missing features, and rough edges that never make the backlog. Innovation sprints give engineers the room to do something about it.

This is also where bad versions of this idea fail. When companies run “innovation sprints” but require engineers to stay within their own product scope, they haven’t run an innovation sprint — they’ve added an unscheduled sprint to the roadmap and called it a reward. Engineers see through it immediately. The excitement dies with it, and so does the case for doing it again.

The reward is genuine freedom. If engineers are building what they’d have built anyway, it isn’t a reward.

One week at Fanatics.

Rosetta Stone had innovation sprints built into their culture before I arrived. They continued until the company was disbanded.

At Fanatics, a group of principal engineers and engineering managers — myself included — lobbied for something similar. We didn’t get two weeks. We got one.

The demos at the end of that week were mind-blowing.

This was before AI became a standard part of development. Engineers were working with conventional tools and conventional timelines, and still produced things that stopped the room. We immediately asked for a second round. Leadership declined — they saw the time as ground they could use to close the gap with competitors.

I understand the logic. Some markets genuinely punish deceleration. But here’s what I keep thinking about now: with AI compressing development timelines the way it has, what would that same team produce in a week today? The engineering talent is still there. The tools are an order of magnitude faster. The ceiling on what a focused, motivated team could build in five days is genuinely hard to imagine.

What it actually costs.

The fear is that while your engineers are building passion projects, your competitors are shipping. That fear is not irrational.

But it conflates two different kinds of output. The sprint doesn’t produce roadmap velocity. It produces something harder to measure and more durable: engineers who are energized, connected to colleagues they don’t normally work with, and reminded that they’re builders — not just ticket-closers.

Those engineers take fewer recruiter calls. They bring better ideas into planning meetings. They become the people who solve problems sideways because they’ve spent time thinking sideways. The return on the sprint shows up across the following two quarters, distributed across a hundred small moments that never make it into a retrospective.

Rosetta Stone understood this. The sprint wasn’t a reward for good behavior — it was a structural investment in the kind of engineering culture that makes good behavior the norm.

What it takes.

Not every organization will do this. It requires quarterly planning disciplined enough to create a real seam, product leadership willing to use that seam for deep work rather than rushing the next cycle, and executive trust that engineers left to build what they want will build things worth having.

Those conditions aren’t universal. But for organizations willing to create them: two weeks at the transition between quarters, real freedom from guardrails, engineers encouraged to partner outside their lane. Run it once. Watch what happens in the quarter after.

Then try telling your board you can’t afford to do it again.