Applying Intel’s Tick-Tock model to software development

The ‘tick-tock model’ was an approach used by Intel to alternate between improvement and innovation every 12–18 months. Intel focused on shrinking and improving an existing chip microarchitecture in the ‘tick’, and in the ‘tock’ they develop an entirely new one. This approach had been very successful in helping Intel innovate on new architectures while setting aside dedicated time for improvement and response to user demand.

In their own words:

Following this model, Intel commits to — and has successfully delivered — continued innovations in manufacturing process technology and processor microarchitecture in alternating “tick” and “tock” cycles.

Software companies have a tendency to go from new feature to new feature, rarely revisiting old ones. It’s understandable why — building new features is sexy. SaaS is a competitive landscape where products are often evaluated with a feature checklist. New features provide constant fuel for the marketing fire, and show momentum to customers and investors. An entirely new thing is easier to sell than improvements to existing things. Yet shipping feature after feature with no break inevitably leads to complex products, low code quality, design debt, and burnout.

A key problem is that a design polish or engineering health phase is rarely baked into the roadmap. Features ship in their MVP state and stay there for life. Designers are frustrated about all the small details and usability improvements that were cut from the MVP, and problems that were discovered after the initial feature launch are rarely prioritized above the next big feature. Developers complain about never getting a chance to refactor code or work on process improvements (like reducing build times), which eventually piles up and causes developer happiness to plummet. Counter-intuitively, going so fast actually ends up making you go slow, and speed is everything when it comes to a competitive advantage in software.

It’s important to step back from feature development to take stock, look at the product holistically, iterate on what you shipped based on user feedback, spend time on engineering health, and polish the design. This finessing is what separates good products from great ones. At Dovetail, we want to build a great product, not just a good one. So inspired by Intel, we’ve applied the tick-tock model with a few changes:

• The time scale is completely different. Intel alternates cycles every 12–18 months. For us, it’s every couple of weeks, but there’s no fixed schedule. Rather than interrupting feature development to start a tick cycle, we’ll alternate when we feel the time is right.

• In our tick, we spend time on small improvements across the board: design, code health, performance, developer happiness. In our tock we build big new features like concurrent editing and our Zapier integration.

• Intel’s objectives are much clearer than ours. We’re still experimenting with our product, so we’ll often ship a feature, see how it’s received, then come back to it. We do this more with core experiences like the navigation within a project and back-and-forth between the list and a note.

Agile is about iteration and constant improvement. But a lot of the time people interpret agile as “we’re going to ship this feature, then this feature, then this feature, look how fast & agile we are!”

Staying truly agile (quickly responding to feedback, iterating, and constantly improving) is not something you get for free. The tick-tock model represents an explicit investment in agility while balancing new feature development. The tick cycle gives us a chance to set the product (and code) up for long term success, keeps us fast, and gives us a chance to respond to feedback before moving on to the next big feature in the next tock.