Giving Employees A Bit Of Freedom

Google famously has a policy advocating that employees devote 20% of their time at work to unofficial projects- ideas that aren’t worth formally proposing or that still need some ironing out, but that the software developer thinks have big potential. Responsible for several now critical Google apps, Gmail among them, 20% time is often cited as a major benefit to working at Google. Whether or not the policy exists in the same form at Google today, as a software developer, I can tell you that the concept is still extremely appealing.

First, parts of development can be tedious and repetitive – sometimes you simply have to type in a lot of initial data, refactor a messy block of code (to refactor is to reorganize code into smaller, better composable chunks, which are known as factors), or clean up documentation. A good engineer tries to minimize these chores (‘a good developer is a lazy developer’), but they still exist. The idea of taking a break from the toil to pursue a project entirely of your own volition, something fun and experimental, is obviously attractive. Knowing that you can take a break when you need to and indulge your creative side helps to work through the necessary (but less glamorous) tasks.

Further, sometimes you just have a good idea that you need to get out – maybe you read something that morning, or heard a talk, or discussed a new idea with a friend or colleague. Some ideas meshed together and suddenly you have a fantastic feature all your users will love. The only problem is that it’s not on the roadmap, and it’s a little hard to explain because it’s only half-baked. In fact, sometimes the only way to demonstrate a great idea is to build it, or at least a prototype, and let it speak for itself. There is always the chance that it will reveal itself to be unworkable, but this way you can cut off a less productive direction early on.

Finally, a good developer loves to learn new things (this isn’t necessarily specific to developers). Occasionally you just need to take some time and experiment with a new technology even if you don’t see a pressing need for it. You never know what you’ll need to build tomorrow. New technologies are fairly frequent in the software world, and it’s important to keep abreast of developments; a lot of people are probably working on problems similar to yours, and they might have new ideas that you can borrow.

Google’s policy is probably a little extreme for many companies – one day a week is a lot of time in a fast growing, agile company with a short development cycle. The precise amount of time and formality with which it is upheld is not really important. What matters is that engineers feel free, every now and then, to set aside what they’re working on and try something totally new.

Here in the CultureIQ office we don’t have any sort of formal policy, but we’re all excited by a cool new idea. There are absolutely times where we need to focus for relatively long stretches, that is part of being a growing business. But there’s always time to discuss something new, and if there isn’t time to pursue it right now, I know that I’ll be able to take some time to explore it during a calmer stretch.

Up to this point I have spoken almost exclusively of software developers / engineers, that being what I know best. The concept applies in general, however, not just for us code monkeys. The real point of 20% (or less) time is to let employees know ‘Yes, you do have good ideas, and I, your boss, trust you to occasionally and responsibly explore them’.

Everyone feels better when they feel trusted. And happier, more engaged employees are the core of high performing organizations. Or so I’ve heard.

AuthorDanny Pinghero

Danny is a developer at CultureIQ and sometimes a data scientist. He likes his programming languages dynamic, his data colorful, and his JS semicolons optional. Want to talk about Star Wars? He’s your guy.