"x-percent-time" is the benefit some companies provide their employees, in which an individual is allowed, usually on a weekly basis, to spend that amount of time doing something else other than their usual backlog work.
During my time at SoundCloud, the company had a 20% time rule for engineers. In short, it meant that every engineer was allowed to work one day per week on whatever they wanted.
The use of the word "whatever" in the previous sentence was carefully thought out. When I joined the company, there was a very short document with a handful of examples of what were good examples of how to spend that time, and that was all.
In this article, I am going to describe the problems we had with the process, and what we did to get it to good shape.
When asking around about it, I remember many engineers mentioning that this was one of the reasons they stayed in the company. We learned that this benefit, when applied correctly, can be a big retention factor.
Every other possible benefit really does depend on how you organise it, and what activities engineers engage on during this time. It can be learning, actually producing useful prototypes, give time for the teams to think outside of the box, etc.
The following were the most common problems we found with the already-in-place process.
The goal here is to share possibly common pitfalls, regardless of how your context is configured.
Some people used it every week, however most people didn’t use it at all.
We didn’t spend enough time to understand all the underlying reasons for this, however a few were more apparent:
Given the free format, most people worked on "random" things that, most times, didn’t have a tangible output. "I’m going to play with this new technology", "I’m going to read more about this library".
No tracking of the work was done in terms of cards in the backlog, or a demo to the team, etc.
While this is not inherently bad, it does challenge the usefulness of the time spent.
This lack of accountability led to a few issues in which it became painfully obvious that, in some cases, people were taking their 20% to escape work for a day once in a while. In these cases, people would usually work from home, despite the company not having this culture at the time.
Since this benefit was given to all engineers, teams felt powerless to try and fix it.
Since people took their days randomly throughout the week, and many times telling their teams the night before, there wasn’t much collaboration on projects across teams coming out of it. It happened from time to time, but too sparsely to count.
On many occasions, mostly from old-timers, someone would go rogue and fix or implement features on systems that were taken care of by another team, without communicating before starting the work.
That ended badly in one of two ways:
Spikes and prototypes sometimes were deemed good and that they should go to production.
How to do it? Which team is going to change priorities to make it production ready and ship it?
Surprisingly, this was one of the top complaints from teams
An engineer wouldn’t agree with the team’s prioritisation of the backlog for a given sprint, so would use their 20% time to "cheat", and work on something that had been deprioritised, instead of making their point and committing as a team.
As you might have concluded, many of these problems could, most likely, have been prevented by a more mature leadership team. This lack of maturity paired with a strong-willed engineering culture, which is a good thing, led to these problems persisting for a few years.
When the engineering management team started to grow at SoundCloud (a tale for another time), the issues described previously started to become a recurring topic. Also, during engineering retrospectives, engineers themselves became more vocal about the problems.
Eventually we got to focus our attention on fixing it.
The hottest topic was what should be allowed during the 20% time.
After many interviews and meetings, we reached the conclusion that pursuing an "allow-list" of topics was an unfruitful endeavour. With over a hundred engineers in dozens of teams, contexts were too different, it wouldn’t work.
Instead, following the overall leadership style of Richard Durnwall at the time, we decided on a very small set of rules that mainly promoted in-team decision making.
The rules were as follows:
This aimed to address accountability, cross-team collaboration, and it also helped to increase awareness to the other departments, since everyone knew that Friday was 20%-time day.
Since all teams organised their work in two-week sprints, and those were all synchronised throughout the company, this rule made sense.
The goal was also to increase accountability, as the cards had to move through the pipeline, and eventually be marked as done.
This one was very contentious, and my introduction to how hard it is to do mass-communication over documents. I remember spending an afternoon having conversations with the authors of many of the fifty-something comments on the one-page document’s sidebar.
The goal of this rule was to give an opportunity to any team member to challenge an activity. In the end, naturally, no one ever used it (we asked), but it just stated clearly that 20% time was also about the team, that backlog priorities shouldn’t be cheated, that one shouldn’t work on something that would create work to another group.
It also gave the opportunity for team members to collaborate on something.
The previous unofficial, but widely used name, for 20% was "Hacker Time". We felt that this wasn’t incredibly inclusive given all the possibilities of usage of this time.
Also in hopes of increasing awareness and thus, engagement, we renamed it to something not very good, but that stuck to this day: Self-Allocated Time, or SAT for short.
Not the most eloquent idea, but it did the trick.
The most important one was that no process will save you from lacking management skills.
And the other one was to trust teams to make decisions that affect their context, but provide guidelines.
I would also strongly recommend against using this time to pay off technical debt. This kind of work must be accounted for using your team’s normal planning methods.
At the time, when we were working on changing Hacker Time, one person was vocal about abolishing it all together.
Their argument was that whatever is done in 20% time should actually be organised as normal work or a particular activity.
Leaning new tech? Should have workshops and such.
Prototypes? Should be organised as normal work.
Spiking out new approaches? Also planned as normal.
While I do agree that they were absolutely correct, my counter-argument at the time was that we were not mature enough as an organisation to have that time planned out correctly for every activity and team.
20% time was a kind of safety net for activities that should be organised, but were not. At the same time providing engineers with more autonomy.
Disclaimer: I left the company in 2017, a little over two years ago now.
When new engineers joined the company, most would use their first few weeks of SAT to learn Scala, the programming language used in most product teams at the time.
Other than this, most would use it to play with and learn new technologies, spike out new technical approaches, or pay some old ownerless technical debt.
When I joined SoundCloud, Hacker Time had already been in place for a few years. I couldn’t really imagine the engineering team without this benefit, and they do it to this day.
If you are to try it out, definitely do it as an experiment, with a start and end date.
You will have to convince other stakeholders that this is useful in some way. Agree with them what is the expected output of the experiment, and try it out.
Go back