I think 99 times and find nothing. I stop thinking, swim in silence, and the truth comes to me. - Albert Einstein
Why is it that, for some of us, our best ideas come when we’re in the shower?
Conversely, have you ever found it challenging to be creative and innovative, when you’re put on the spot? “Be creative to solve this problem in 3, 2, 1… Go!”
For many leaders, creating empty space for their teams is counter-intuitive. Won’t they just slack off? Won’t they just work on something that isn’t prioritised? Surely we’ve got… “Better things to do”.
In this article, I will give 3 examples of creating ‘space’ for teams that I hope will change your mind. I’m using Spotify as an example as they were incredible at not overflowing their teams with work and creating space for teams and individuals to make magic happen.
1. Slack in quarterly capacity planning
Ideally, quarterly planning ensures that teams sustainably plan work towards achieving the organisation's most important goals. One of my favourite ways to do this is with a simple bucket exercise. Your team only has a certain number of people for 12 weeks in a quarter. We slice the bucket into 1-week slots that can be filled with various types of work.
Baseline represents work that keeps the lights on and ensures we don't go backwards as a team and a product. This can be filled with paying down tech debt, maintenance, upgrading systems, individuals taking time off for vacations, etc. If you don’t first allocate baseline activities, they will eventually come back to bite you.
Next up you add in your strategic initiatives and any planned work for the team for the quarter, which is usually a mix of bigger company-aligned initiatives and smaller work from your roadmap or backlog.
But here’s something you can try: Allocate 10 - 15% of your team's time to slack.
Why? Here is an example of how I used slack as a Product Manager at Spotify back in the day, when working on the Desktop product. The first step was introducing the 15% slack time during quarterly planning.
Mid-way through the quarter, an engineer comes to me to tell me that the new MacBooks are introducing a touch bar and we could be the first music streaming product to make use of it, which in turn can generate positive press and positive customer sentiment. Is it the most important thing to prioritise right now? No. Will it help us maintain market leader perception, make our Macbook Pro customers happy and importantly, bring a lot of joy to our team? Yes. Is time of the essence in order to capitalise on this? You betcha, it’s a good thing we have the slack to do this. So, I gave the developer not only my blessing, but encouragement and support to see this little side-quest through to it’s completion.
This piece of work also led the engineer to discover improvements to how Spotify integrates with the keyboard media controls on Macs, which also improved the user experience with Airpods. Here’s an old article that came out once we pushed out these changes:
Had we not had slack in our planning, we simply would not have had time to do this piece of work, and we would not have reaped the benefits of doing it before our competitors, namely being featured in the press. Slack directly affects your speed to market.
2. Hack Days / Hack Weeks
Hack days are dedicated periods, usually lasting one to two days, during which developers are free to work on personal projects or experiment with new technologies. These events encourage creativity, innovation, and learning, as team members have the opportunity to explore ideas and solutions outside of their regular work scope. Hack days can lead to new product features, improvements to existing systems and workflows, or learning a new skill.
In my team at Spotify, we had experimented with 1 hack day every 2 weeks (sprint) and also 2 hack days a month consecutively, each with varying pros and cons. We also had a hack week once a year where individuals could work on anything. Some would hack the foosball table to keep score of their games, some decked out the staff lifts with city themes (e.g. Paris) but most pursued whatever idea that has been stirring around in their heads, or fixed a piece of tech debt that had been bothering them for ages.
If you want an example of where this paid off, look no further than Discover Weekly. The genesis of this idea came about from a Hack Week, then other forms of slack enabled that idea to be pursued further. Discover Weekly was not only one of the most successful feature launches that Spotify has ever released, but it fundamentally shaped Spotify’s product strategy for years to come and led to a massive increase in investment in machine learning, which in turn produced more ideas like Release Radar, Daily Mixes and much more. And on a fun side note, the CEO & Founder Daniel Ek initially hated the idea.
Another example is the improvement to the release process on Desktop. It was a hack day that resulted in one of my team members creating a prototype for an automated process for releasing the Desktop client with a click of a button. This prototype demonstrated the value of an easy release process and in turn led to this being properly prioritised the following quarter.
The fact that I have a patent from my time at Spotify is also due to a hack week project. One of my favourite hack week projects of all time was when a few employees went around the huge Spotify office in Stockholm, putting up signs with direction arrows to help people know where each meeting room was, which I’m certain improved overall productivity as fewer people were late due to not knowing where a particular meeting room is. Such a simple, yet powerful ‘hack’.
Suffice to say, the energy and creativity that emerge from these hack days / weeks live on far longer than the time spent pursuing their ideas. There are plenty of examples of features that started out during a hack week and eventually were hugely successful. Google’s Gmail & AdSense famously started out as ‘side projects’ during their 20% innovation time and now are some of the most important, revenue-generating, valuable products at Google.
3. Limiting WIP below the number of team members
If you’ve ever worked in hospitality, you might have heard the phrase “If you’ve got time to lean, you’ve got time to clean”. For some reason, most leaders I meet are terrified at the prospect of developers not having something to do. Yet, I guarantee you that you will struggle to find many developers that, when given ‘free time’, would simply slack off.
What they’ll usually do, is refactor their code, fix problems that have been bugging them, learn a new skill that could be helpful to the team’s mission or god forbid, help another team member out in the form of pair programming, which often leads to an improvement in knowledge sharing and thus overall productivity in the team.
A classic example from memory was a new junior team member that had joined my team. At the time, there was only 1 person in our team that had any real depth of knowledge of our automated end-to-end tests, but our new developer was keen to learn. She not only learnt how to create (and fix) our tests, but she then gave confidence and encouragement to the rest of the team to also learn, because if she could, they all could. This led to the entire team making sweeping changes that improved test automation practices, speed of development and ultimately developer happiness due to not having to fix flaky tests so often.
At the end of the day, as leaders, we can’t always know what every little thing is that our teams should work on. Whether that’s what the next big thing to innovate is, or down to the tiniest of detail in terms of fixing impediments to team productivity.
Creating space creates opportunity, opportunities that you may have never considered that might just make an enormous difference to your people, your product and ultimately your bottom line. Give it a try and when it feels uncomfortable, lean into the discomfort. You might just be surprised at what you find.