Why Storyblocks Implements 80/20 Time

Many if not most software engineers have heard about Google’s famed 80/20 time that gives engineers the flexibility to work on side projects with 20% of their time, a move that Google hoped would increase innovation when it introduced the concept in 2007. And it did! Leading to innovations like Gmail. For the last couple years Storyblocks has employed a similar concept. Our engineers are given the flexibility to spend around 20% of their sprint capacity to improve our processes and tools, refactor legacy code, experiment with new technologies, learn new skills, etc., all targeted at “Leveling Up” our skills, team, tools, processes, company and ultimately the bottom line.

In the middle of 2017 we had to pause the initiative for about six months to deliver a major project. Many easily predictable downsides resulted: more bugs, increased technical debt, slower CI processes, higher stress, and more. As we rolled it back out after delivering the project, I sent the an email to the Product and Engineering teams with talking points on why we implement it here at Storyblocks.

All,

I’ve had a few people from outside of the Product and Engineering organizations approach me to ask about “Level Up Time”. I’ve also heard that it’s come up a few times in sprint planning sessions as well as other more casual settings. Since there seem to be a number of people across the company that have questions, I wanted to empower our teams with a common set of talking points in case you’re in a situation where you need to explain the concept.

1. “Level Up Time” is our standard way of operating. It used to be branded as “Engineering Task Forces” (ETF), “Breathing Room”, and” 80/20". It’s still the same concept, just a new label. We paused this early in 2017 for the Brand launch build so we could get it out the door in time, and we were clear with leadership that we’d return to the standard operating procedure post-launch.
2. “Level Up Time” is necessary for any engineering team, including ours, to continue delivering features reliably and efficiently. Best-in-class engineering leaders recommend that an engineering team needs to own 20–40% of its capacity to ensure the team can continue delivering. As it says in The DevOps Handbook (written by the engineer who coined the term “DevOps”), “When organizations do not pay their ‘20% tax’, technical debt will increase to the point where an organization inevitably spends all of its cycles paying down technical debt. At some point, the services become so fragile that feature delivery grinds to a halt because all the engineers are working on reliability issues or working around problems.” We saw the implications of pausing these efforts many times over the last six months as we focused on the Brand effort: our CI / testing processes bogged down and cost us hundreds of points; we still don’t have smoke tests or telemetry that could have helped us prevent / quickly fix a large number of bugs / incidents that occurred; several large sections of our code are fragile or very difficult to modify (e.g., search); etc.
3. “Level Up Time” is the logical extension of our culture of Autonomy, Mastery, and Purpose. It’s also a logical extension of our new squad-based model that seeks to push decision-making as close to the front lines as possible. Our engineers understand the problems that hold us back the best so we should trust them to help take us to the next level.
4. You should do it too! “Level Up Time” isn’t an engineering-only concept. We should all continually seek to improve our skills, tools, team, squad, company, etc. Exact time allocation of course varies depending on context.

Let me know if you have any questions or want to add to this list of talking points. The more the merrier!

Thanks,

Jonathan