3M's Post-it Note and several of Google's products have something in common: they came from time employees weren't assigned to spend on them. Both companies built slack into the week on purpose, 3M's 15% time and Google's 20% time, on the bet that giving smart people room to explore pays for itself. The results, and the caveats, are worth understanding before you copy it.
Key Takeaways
- 3M's 15% time (since 1948) let employees pursue their own projects, and produced the Post-it Note (Side Project Time).
- Google's 20% time (from its 2004 IPO letter) was inspired by 3M and yielded real products (Side Project Time).
- The catch: at Google, only about 10% of employees actually took the full allocation (reporting).
- Slack works when it's protected and paired with real resources, rather than merely declared.
The Idea
The concept is structured slack: deliberately unassigned time for people to explore. 3M pioneered it in 1948 with "15% time," asking employees to spend up to 15% of their paid hours on projects of their own choosing (Side Project Time). The famous payoff was the Post-it Note, which came out of exactly that unassigned exploration. Google adopted the idea in its 2004 IPO letter, where Page and Brin promised engineers 20% of their time for side projects, explicitly citing 3M as inspiration. Several Google products, including Google Suggest, the autocomplete you use every day, trace back to 20% projects.
The bet behind slack is counterintuitive: a team booked to 100% on assigned work has no room to discover the thing nobody thought to assign. Some of the highest-value ideas come from people following a hunch on time that wasn't allocated to it.
The Honest Caveats, Built In
Here's where most "we should do 20% time" plans go wrong, and the reporting is honest about it. At Google, former executive Marissa Mayer noted that only about 10% of employees actually used the full 20%, because core workloads demanded what people called "120% time" (the cautionary tale). Slack that isn't protected gets eaten by the day job. And the 20% policy worked partly because Google had world-class infrastructure, shared codebases, and massive distribution; the same free time without those resources produces hobby projects, not billion-dollar products. Slack is necessary but not sufficient.
| Slack that works | Slack that fails |
|---|---|
| Protected, real time | Eaten by the day job |
| Backed by real resources | Just free time, no support |
| A structured cadence | A vague "when you can" |
A Structured Alternative
If open-ended 20% time is hard to protect, a structured version is easier to sustain. Atlassian's ShipIt runs quarterly: a single dedicated day, with funding, where anyone builds whatever they want (Atlassian on ShipIt). It's concrete, protected (nobody can claim they were "too busy" for a scheduled day), and it has shipped real features into Jira and Confluence. Atlassian credits it with keeping startup energy alive past 5,000 employees. A dependable one-day-a-quarter beats a theoretical one-day-a-week that never happens.
A Concrete Version
A startup declares "everyone gets Fridays for side projects." For a month it works, then a big deadline hits, Fridays quietly get reclaimed "just this once," and within a quarter the policy is dead, because it was never protected. A second company instead runs a real quarterly hack day: it's on the calendar, leadership shows up, and small budgets are available. It survives, because it's a protected commitment rather than a hope. One of those hack-day projects becomes a shipped feature; none of the unprotected Fridays did.
The Honest Counterpoint
Structured slack is not a fit for every stage or team, and a five-person startup fighting for survival probably shouldn't formalize 20% time yet, when every hour matters and there's no infrastructure to amplify a side project. The lesson generalizes down, though: a team with zero slack, booked to 100% forever, has no room to improve its own tools, pay down debt, or chase a good idea, which ties back to why 100% utilization backfires. Even a little protected, purposeful slack beats none. Scale the formality to your stage.
What This Means for Teams
Slack is where improvement and invention come from, and protecting it is a leadership choice, the same instinct behind leaving capacity for the unexpected and treating developer experience as a real investment. Whether it's Google-style 20% time or a quarterly hack day, the principle holds: people booked solid can only execute; people with a little room can discover. See available engineers.
Frequently Asked Questions
What is innovation or "20% time"?
Structured slack: deliberately unassigned time for employees to explore their own projects. 3M's 15% time (since 1948) produced the Post-it Note; Google's 20% time (from 2004) yielded products like Google Suggest.
Does 20% time actually work?
It can, but with caveats. At Google only about 10% of employees used the full allocation, because core work demanded more, and it worked partly because Google had world-class resources to amplify side projects.
What's an easier alternative?
A structured, protected cadence like Atlassian's quarterly ShipIt hack day: one dedicated day with funding, on the calendar. A dependable day-a-quarter beats a theoretical day-a-week that keeps getting reclaimed.
Should a small startup do 20% time?
Probably not the full formal version early on. But even a little protected slack to improve tools, pay down debt, or chase an idea beats being booked to 100% forever with no room to improve.
The Bottom Line
The Post-it Note and several Google products came from time nobody was told to spend on them. Structured slack, whether 3M's 15%, Google's 20%, or a quarterly hack day, is how mature companies keep inventing, but only when the time is genuinely protected and backed by real resources. Booked-solid teams execute; teams with a little room discover.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
