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?
We founded it-agile seven years ago. This is a good reason to reflect on what we have achieved regarding management and organization within it-agile. Some of the things listed below were already in place seven years ago, others are just a few days old.
We believe that our employees are it-agile with the implication that the best employees would make the best it-agile. And we do not just aim for satisfied customers, we want to delight our customers. To express these believes we have a defined purpose:
“Create fulfilling jobs for our employees to delight customers.”
We achieve this purpose by:
- Transparency and openness: Nearly every information is visible for every employee including the wages, travel expenses and time sheets of every colleague (the CEOs are just colleagues also). On a company level the economic data etc. are accessible for everyone.
- Peer groups: Employees have self selected peer groups that work with the employee on personal improvements and suggest promotions.
- Pull principle: We have implemented the pull principle for coaching and development. Customer requests are visible for the whole company and employees pull these. So employees may choose to prefer jobs in their local area and decide on themselves if they are capable of doing the job.
- Meetings at it-agile are optional. Every employee decides for himself if he attends.
- As long as the results are achieved everybody can work when and where he wants. (Of course this has to be coordinated with colleagues and customers since most of the results can’t be achieved without colleagues and customers.)
- Every employee has 30 days of slack were he can do whatever he wants: go to conferences, work on a self selected project, read books, go to trainings, … Of course it is transparent within it-agile what everybody did.
- Employees don’t apply for holidays. They decide on themselves when they take their 30 days of holiday.
- Overtime: There is no pressure for working overtimes. Sometimes employees decide themselves to work overtime to achieve important results. The overtime is collected in a work hour account. Employees decide when to withdraw time from that account.
- Expenses: Employees decide how they travel and what equipment they need for their work. They don’t ask for permission. They just buy what they need.
- Profit sharing: About 2/3 of the company profits are distributed to the employees (in principle every employee gets the same percentage).
- Company ownership: About 2/3 of the company is owned by the employees. This implies ultimate empowerment: The employees can change ANYTHING. They could even fire the CEOs or change the purpose of the company completely.
Is it successful?
We have more employees, we have higher revenues and we have higher margins today than we had in the beginning. You never can be sure if the described principles created this growth or if it just was good luck. But I think we were and are successful.
Will it travel?
In general the described concepts shouldn’t be taken as a blueprint for another organization (although there are similarities with other companies like SemCo). I think we wouldn’t have been able to start with out current state even if we had known it. I think that we observed a kind of co-evolution during the last seven years. We made a small modification to the organization of the company. That enabled a small progress of company culture. This progress in company culture then enabled the next small modification of our company structure and rules. And so on…
Will it scale?
We started it-agile with 10 people. Now we are 35. In my point of view the things we did enhanced empowerment and autonomy which are important building blocks for our growth. The changes we made enabled growth. I think for further growth we have to intensify empowerment and autonomy even more.
Since there is no big boss at it-agile you never know what will happen next. There are some very interesting and challenging discussions in the moment.
BTW 1: We are hiring agile coaches and developers. (Notice; Sometimes people seem to think they wouldn’t match our expectations and therefore don’t apply for a job at it-agile. There is only one way to find out: Let’s talk!)
BTW 2: We offer consulting to managers who want to transform their company/business unit in an agile way towards more empowerment and autonomy.