Continuous Innovation Rituals are the small, shared practices that help a company keep experimenting with its products, processes, and people. In October 2012, I gave the keynote at ScotSoft in Edinburgh on continuous innovation. It drew on my time as an engineering leader at IMVU, the company behind The Lean Startup. I had joined after Eric Ries moved on, with responsibility for process, among other things. Much of what we practiced there still holds. Some of it has since evolved into frameworks across this site. This page revisits that talk and follows each idea to where it lives today.
A few details belong to 2012 and are labeled that way. The rituals behind them have aged far better than the numbers.
Table of Contents
Show all sections
- Edinburgh, 1985 and 2012
- Beginner’s Mind: Follow No Mantra Religiously
- Hiring Is Only the Beginning
- Happiness, Passion, and Engagement
- Experiments Over Opinions
- Validating With the Right Data
- Deploying Every 7 Minutes
- 5 Whys: Turning Losses Into Wins
- Letting Go
- How These Ideas Evolved
- The Original 2012 Deck
- See Also
Edinburgh, 1985 and 2012
My first trip to Edinburgh came in 1985. I flew in from Munich to help sell the Bank of Scotland on a new product from Softlab’s second pivot. What unfolded was not quite according to script. The bank was not at all excited about adopting innovation. After all, eight previous systems supported 180 of their IT staff. Even so, they adopted it.
Twenty-seven years later, I returned to Edinburgh to speak about continuous innovation. The lesson from that first visit stayed with me. Innovation rarely fails for lack of ideas. More often, it stalls on the very real reasons people have to resist change.
Beginner’s Mind: Follow No Mantra Religiously
The talk opened with a question: what is the one mantra to follow religiously? My answer was to follow no mantra religiously. The path to enlightenment lies not in the footsteps of another. Instead, I suggested Beginner’s Mind, the Zen idea of shoshin.
Beginner’s Mind applies well beyond engineering. In 2012, I invited leaders to apply it to product direction, company direction, development processes, and resource management. It applies equally to marketing strategy, technology choices, analytics, and understanding customers.
Today, this idea lives on in The Path to Enlightenment and in The Dark Side of Agile, which explores what happens when any framework is applied rigidly.
Hiring Is Only the Beginning
In 2012, I argued that curiosity and passion matter more than any single skill. Thomas Friedman framed it as CQ plus PQ being greater than IQ. Skills go out of date quickly. Attitude, curiosity, and passion keep growing.
Yet hiring was only the start. At IMVU, we dedicated a mentor to every new engineer. That mentor sat next to them for six weeks, spinning them up with a boot camp guide. Each new engineer pushed a change to production on day one.
These practices have since grown into Hiring Rituals, Onboarding Rituals, and New Hires.
Happiness, Passion, and Engagement
What makes for the most productive and innovative employee? My 2012 answer was happiness, built on passion and engagement. Managers work for the engineers, enabling them to be productive. We sell rather than tell, winning hearts and minds.
- Let people pick their team and project.
- Let them hack, experiment, and choose their tools.
- Let them help decide when work is done.
- Keep teams small, agile, and fun.
My thinking has since gained nuance. Serving people well sometimes means challenging them, not simply giving them what they want. That nuance lives in Servant Leadership Downsides.
Experiments Over Opinions
IMVU treated almost everything as an experiment, including its own processes. At one point, five teams ran five different processes. Continually running process experiments helped us avoid falling into dysfunctional routines.
Minimal Viable Products came in very different sizes. An experiment might change a heavily used system, such as landing pages with millions of monthly hits. It might add a feature set, build a new subsystem, or explore a paradigm shift, such as an iPhone app.
Experiments were not the only way to learn. We also drew on user sessions, customer advocates, field observation, surveys, using our own product, and mavens who knew the market well. Each has trade-offs. Experiments let people vote by doing, while surveys capture what people say rather than do.
These ideas later evolved into Minimal Viable Process Change and Atomic Rituals. The customer advocate also has a modern cousin in the Patron Advocate role of DACIP.
Validating With the Right Data
Data can mislead even when it is accurate. In one 2012 experiment, a new feature’s use rose about 6% over the two weeks before.
Segmenting the same data told a different story. One subgroup rose about 48%, while another fell about 68%. The modest average concealed two strong and opposite effects.
That lesson now lives in Trust but Clarify Data and in the Validate step of the THRIVE Loop.
Deploying Every 7 Minutes
In 2012, I compared release rhythms. Waterfall teams often released every 6 to 12 months. Agile teams released every 1 to 3 weeks, and continuous deployment meant releasing every day. At IMVU, we deployed about every 7 minutes.
Speed was only safe because of the rituals around it. Each change first had to pass a large suite of automated tests. Only then did it roll out to a small share of servers. If the metrics held, it reached every server. If not, the system rolled it back.
We called this monitoring an immune system. Because each change was small, problems were easy to find. In one case, fewer than 30 lines of code needed investigating.
Small, frequent loops are also the heart of Talent Code Applied, where short repetitions and fast feedback build skill.
5 Whys: Turning Losses Into Wins
Every outage became a chance to learn. In one example from the talk, a server ground to a halt. Why? A database query took far too long. Why? It was an un-indexed query on a large table.
Why did the engineer not catch it? Local tests ran fine against a small test database. Why did no one warn him? It was his first database change as a new hire, and his mentor had left for the day. The root cause was not a careless engineer. It was a gap in our onboarding ritual, and that was something we could fix.
That was the familiar root-cause 5 Whys. My page Start with 5-Whys later took the familiar 5 Whys in an entirely different direction, toward purpose.
Letting Go
Innovation also means letting go. Loss aversion and the sunk cost fallacy make it hard to stop projects we have already invested in. Yet continuing only because of past costs rarely serves the future.
Prioritization works the same way. Deciding what sits at the top of a list is hard. Often, though, deciding what falls off the bottom matters more.
These questions now live in The Tao of Forecasting, which explores the forecasts behind our choices.
How These Ideas Evolved
Many ideas from 2012 became the roots of later pages. Each has kept evolving, as every page here does.
| 2012 talk | Where it lives today |
|---|---|
| Beginner’s Mind, follow no mantra religiously | The Path to Enlightenment, The Dark Side of Agile |
| Mentors and the onboarding boot camp | Onboarding Rituals, New Hires |
| Process experiments | Minimal Viable Process Change, Atomic Rituals |
| Customer advocates | DACIP |
| Validating with the right data | Trust but Clarify Data, THRIVE |
| Small, frequent deployments | Talent Code Applied |
| 5 Whys | Start with 5-Whys |
| Letting go and prioritization | The Tao of Forecasting |
The Original 2012 Deck
Here are all 34 slides from the October 2012 talk. Some examples, such as job forecasts and other companies’ release figures, reflect that moment in time.
See Also
Atomic Rituals
Atomic Rituals explores how teams and organizations change their shared habits in small increments. It builds on the same insight behind IMVU’s process experiments. Rituals define a group’s identity and culture. Small, atomic changes are far easier for a group to adopt than sweeping ones. Readers interested in Continuous Innovation Rituals will find a fuller framework there.
Start with 5-Whys
Start with 5-Whys takes the familiar 5 Whys in an entirely different direction. Rather than stopping at the cause of one failure, it keeps asking why. Followed far enough, the Whys converge on a core why, the reason anything matters to a person or organization. It serves individuals and organizations alike.
The Lean Startup
Eric Ries’s The Lean Startup shares the principles that grew out of his time at IMVU. It introduced many readers to the build, measure, learn loop and to Minimal Viable Products. The book also explores validated learning and continuous deployment. It offers useful background for the practices described on this page.