Why does hack time fail?

How and why does hack time fail despite involved developers and management buy-in?

Google are doing it, so it must be a great idea: hack time!

In an innovative and enlightened company, everyone will be on board quickly. Reasoning along the line of, there needs to be some level of slack so people will have space to think and come up with new ideas, which will help current clients and will lead to new clients in the future. The constant display of thirst for new knowledge will also attract new employees and ultimately lead to a real engineering culture.

In a display of glamour and grace, the CEO will hold an all hands meeting and lay out the plan. Everyone gets 10% of their time and can do anything they like with it. Consider this a gift! A short discussion follows, does the time spent need to be client related? Tech related? An agreement is reached, we’ll figure it out along the way.

And off you go. At first, everyone is still very busy with their planned work, but that shall soon pass. Until, after a month or three, you check the hours booked on hack time and find that it’s a very low number. Even the people that were expected to be the front runners, the ambassadors of this R&D space, are not booking any significant time.

What went wrong?

Well, let’s take a look at these front runners. These are the people already doing the research, and instead of seeing this as cost, they appreciate it for what it is: a value driver. Even for failed experiments. Good experimentation brings the project further, so the time is invoicable and booked on a client.

The people not doing the research will have no idea what to do with the gift. Don’t get me wrong, this is not a statement of valueing some personality types over others. Roger’s bell curve can apply to team members as well as to companies.

Technology adoption lifecycle graph It depends on the project or client which personality types will be best on a team.

How do we get people that do not grab the opportunity to participate in hack time? I think it’s a matter of setting the correct goals. Hack time does not necessarily need to lead to a specific tangible product. Hack time can in itself be a goal; people will be working on getting better at what they do. Expect people to fail, encourage them to fail. Only this can lead to success.

Ask yourself, which problem am I trying to solve? Should employees participate more? Should they improve their skills? How does hack time solve these problems? Are your employees aware of the problems you are trying to solve with hack time?