Stefan Roock

All About Agile and Lean

August 20, 2013

What to expect from slack time

Several well known companies have slack time models of different shapes and sizes. 3M and Google are famous for their 20% model (engineers work 20% of thair time – e.g. every friday – on a self-chosen project). My former colleague Bernd Schiffer wrote a small blog post series about slack.

Recently an InfoQ article re-opened the discussion with interesting insights into Googles 20% slack model. It seems that at Google most employees don’t use their slack (self-chosen or management prohibited it).

That made me think of two slack models I have experienced first-hand – one at it-agile (every employee had 30 days slack per year) and one at a client (every developer had a contingent of something about 12 days per year using the Goldcard model). In my point of view both models failed to deliver what was expected: business relevant innovation. And I think I know the reason.

Imagine the typical developer working according to the prioritization of a Product Owner. Now we grant the developer 10 days per year slack time. He can use the day for whatever he wants to do. The developer thinks: „What should I do with my slack time? Hm. I can do, whatever I want. Let’s see, there is this new cool programming language. I will have a look at it.“

The effect is a technological focus of the slack time. In such a setting you can expect that developers know more new technologies. And that is fine if this has a relevant impact on your business.

But most of my clients primarily need business innovation. While knowing the newest technologies is important for a lot of business innovations it is not enough. You need to know customers‘ problems and needs as well.

Google has an advantage here: Google develops products for consumers like me and you. Therefore the engineers might be potential customers of Google products and a now their own problems and needs. Ergo: developers were able to develop e.g. Google Chrome or GMail in their slack time.

But in most companies the developers aren’t potential customers of their own products. I think that a slack model has to have certain constraints to generate business innovation. One might be that the slack time has to be with and at clients (perhaps something like the sunglass iPad development at Nordstrom may be the result).

What di you think? What are your experiences with slack time models?

Published by

stefanroock

8 Antworten zu „What to expect from slack time”.

Markus Andrezak

August 20, 2013 at 1:58 pm

20% time has never brought the great break throughs at google. It is simply romanticized. Since google is focusing more on the customer, innovation is done in think tanks and design labs. 20% slack is a small way for small grained feature wise innovation . Breakthrough innovation needs way other environments than that. And it is not done in a sprint or on a Kanban.

20% time is basically opium for the masses 😉 a romantic idea of empowerment.

Cheers

Markus
Alex

August 20, 2013 at 5:38 pm

As Reinertsen mention in this interview:
„When you ask people at google what they most do in 15% time. They mostly do the work which is behind schedule.“

http://channel9.msdn.com/posts/YOW-2012-Don-Reinertsen-The-Zen-of-Product-Development?utm_content=buffer5bb41&utm_source=buffer&utm_medium=facebook&utm_campaign=Buffer

But still slack time can generate innovation… but should not be the only tool.
stefanroock

August 21, 2013 at 7:14 am

Maybe it depends on the definition of „breakthrough innovation“ but I don’t think that 20% models failed to deliver innovation. I think 3M had relevant innovations generated by the 20% model. Google Chrome is just another browser but I think GMail was a breakthrough in web based email clients. And W. L. Gore & Associates has a 10% slack time model that generated e.g. the Elixir Guitar strings (according to „Group Genius“ by Keith Sawyer). I think 20% slack time models can lead to innovation but maybe you need some more constraints to stimulate business relevant innovation. And of course there are other successful models out there as well.
Markus Andrezak

August 21, 2013 at 12:18 pm

20 % may deliver something or not. That’s not my point. If you want to stay in business and want to enter the innovation space, 20% is a nice gateway drug. But to really be competitive, real depth and problem finding and entropy is necessary. Heck, it is jnown today how to achieve depth. But 20% time only solves the problem of giving space and time. Not purpose, not depth, not going outside. You can pretty much waste the 20%.

If you look into the real stories behind google, even the reported google maps was rather acquired than invented. So there doesn’t remain a whole lot of innovation for thousands of employees‘ 20% work time. As typical, there’s a tool that gets famous and everyone thinks it’s cool w/o much thinking.

There so much known about how to get to deep innovation nowadays that its basically a shame it gets simplified to ‚20% is a good start‘ and ‚google gets enterprisey‘ after getting rid of it and actually finding better ways.

Just a random article that expresses things much better than I could: http://qz.com/116884/five-reasons-why-the-death-of-googles-20-time-might-be-good-news-for-innovators/

So basically, I think 20% is a decent gateway drug to start understanding innovation. No more, no less.

And actually, we might be in line, as all I say is ‚good thing but publicly overrated‘.

Cheers

Markus
lisacrispin

August 21, 2013 at 7:48 pm

I learned from this post: http://learningagileandlean.wordpress.com/2012/05/10/the-elusive-20-time/ from Alexei Zheglov that it’s more about capacity utilization and flow than 20% time.

I’ve encountered far too many teams that fail because they continually over-commit to too much work for a given period of time, even self-organizing teams. They’re overly optimistic, they want to please their stakeholders, so they sign up for way too much work. Then they disappoint their customers by either not delivering at all, or delivering code that isn’t really ready. They accumulate more and more technical debt, until they grind to a halt.

So if the 20% rule helps prevent that, it’s a good thing.

On my last team, we spent two or three weeks every six months where we delivered nothing for the business. The time was used to do things that managed our technical debt, such as big refactorings of automated tests that couldn’t be fit into a short iteration. This was also a chance to try out new tools or learn something new.

We also budgeted time within normal iterations to do things like learn different parts of the business domain. This helped us help the business, finding things which could be automated to help speed up a process or prevent mistakes. Or just make sure we delivered what they wanted.

The team I’m on now doesn’t have an official slack time policy, but we take time to try new things and find good solutions. We’re a small team so we have to make sure to devote time to architecture issues, devops activities, customer support, testing and so on. I do sometimes wish I had some official slack time I could devote to learning something that’s not directly related to the task at hand.
Sven Peters

August 25, 2013 at 6:48 am

At Atlassian we could celebrate some successes with 20% time. We brought some fixes into our products that people like this recent one from our VP of engeneering http://blogs.atlassian.com/2013/07/introducing-group-sharing-get-everyone-in-one-fell-swoop/
It’s true that we are in a unique position using our tools ourselves.
That said, we also have a lot of discussions internally using our 20% time…. we found out that it’s basically a 6% time. Some teams are doing Innovation weeks which works pretty well! http://blogs.atlassian.com/2012/09/innovation-week-20-time-in-a-box/ …or finnovation weeks how the bitbucket call them http://blog.bitbucket.org/2013/04/02/finnovation-brings-you-a-heap-of-new-features/)
But for some people at Atlassian still 20% time is working pretty good.
Sergey Shishkin

August 29, 2013 at 11:24 am

I agree with Lisa that if slack yields innovation, it’s simply because of under-utilization.

As for the struggle of slack time not focused on the business, some sort of pyramid of needs may explain that. I think that developers need to saturate their need of technology passion first, before they start to think about business problems. In other words, slack time is something you want to get rid of, not to strive for.
Warum ich zuerst skeptisch war und dann doch teilgenommen habe. | Stefan Roock

Mai 3, 2016 at 2:07 pm

[…] zu dem Thema auch meinen Blogpost zum Konzept der Slack-Time, in dessen Kommentaren Markus Andrezak das Konzept als “Opium für die Massen” […]