|
I never worked at Google, but I did work for a different, fairly well known consumer tech company doing a lot of work around "hack time". While there, they didn't have any such program, and I really wanted there to be one. So I helped implement a program for "hack time", which was pretty close to 20% time. I did surveys of over 100 engineers, put together a presentation for leadership, got directors of various eng departments on board, did a pilot program, then did post-surveys and presentations to gauge impact. We also spent time with managers to make sure they were on board, and made it clear to their direct reports that they were on board, and that it was OK to use hack time. The point is, we really tried to do this right, and get people to use the time, and assess if it was actually valuable. We did this for a quarter across a few different large eng teams. We eventually shut it down. My high level takeaways were the following... * Way more engineers *say* they're into doing hack projects than actually ended up doing them. We had huge initial survey response of people saying they wanted to do something, and only ended up having like 5-ish projects that were seen through. And there were probably 20ish projects that started at the beginning of the quarter. So large drop-off.
* BUT! That can be totally fine! Many people who actually used hack time were some of the best engineers at the company. Other ones were some of the newest at the company. You're really helping job satisfaction for those top engineers, and really helping mentorship and learning for the new engineers.
* I now believe it's better to have regular highly condensed hack weeks (or hack days if you're a small company), rather than a spread out "20% time". Even people who really liked hack time found it hard to actually take the time when deadlines were approaching. But when you just eliminate those things with a condensed period of hacking, then people can focus. You also tend to increase participation considerably through this method. (I know cause we did this method as well)
* Stop trying to create Gmail in your hack time! A lot of the most valuable stuff to come out of hacking was internal tools, refactors, and little things that improved daily quality of life around the company. (ie. someone made a batch upload tool for the customer support team that they *loved*!). Or small UX improvements for customers. Some people did try to create certain new products, but it's super rare that those make it into the main product Not saying it can't, or won't, or even that you shouldn't do it. But as a general rule, the best you can hope for there is you've de-risked a new feature, or gotten your manager excited about the possibility, and they'll slot in time to "do it for real" in the next quarter. Realistically, people tend to have more fun just making stuff that they actually can see the value of the next day. Or when they get to hear thank you emails immediately from a whole other team.
* You get a lot of other value from hack time besides break-through products. Specifically, you get people across teams mingling with each other. You get new and experienced engineers hanging out. You get a feeling of autonomy. People learn new tech or new parts of the company. For example, I made one of my most lasting relationships at that company by just randomly deciding to join his hack team for a hackathon project. I also got to use GraphQL and React for the first time on that project.
Overall, I think hack time/ 20% time / whatever you want to call it is very very valuable, and companies of all sizes should do it. But you have to do it right, and you have to go in with the right mindset about why you're doing it. Do it because it's fun. Do it because you help your company meet one another. Do it because you'll probably improve the daily quality of life in small tangible ways for a lot of people for your customers, or for other employees. Do it to give your engineers some autonomy. Don't do it in order to get your next Gmail. |