Working Up

by Dwayne Phillips

Giving employees free time may bring great new ideas and products. Not giving employees free time may cause them to “try things” while working on projects. The projects often suffer.

I have met many engineers, programmers, administrators, and others who have great imagination. Ideas come to them (I used to be one of them, sometimes I stray back into that fold) and they try those ideas. Sometimes, some of those brilliant ideas work right now in the system we are building. Often, however, that isn’t the case. Poor odds don’t deter these imaginative people. Close oversight is necessary – well maybe not necessary as there are other choices.

Google is famous for their 20% free time. Though not the only company to have such as policy, “free time” is not accurate. The employees work hard during that 20% trying to create new products – whole, complete, usable, and (hopefully) profitable systems.

There is another type of Free Time policy (see footnote). In this form, the person is allowed to try anything for 10% or 20% of their time. The difference here is that the result of their time doesn’t have to be a complete product or system. Instead, it can be a subroutine, a new algorithm, even just a new way to pretty print source code. This type of free time pays for itself on projects.

I’ve seen  projects set back severely because someone had an idea and wanted to try it. Since they could only spend time on projects, they tried the idea on a project and its product. They had been staring at a piece of code or a design for a circuit and had an idea. They “slipped it in” to see how it would work. No one else knew; no one else would find out; the little change was sure to work. Sometimes the little change did work, but most of the time it didn’t. Since no one else knew about the little change, it was difficult and costly to find and correct it. Project derailed.

The Free Time policy would have prevented this derailment. Consider an example where a programmer sees something in the code that he would like to try. With Free Time, the programmer can copy the code baseline over to the side and try his idea. Failures are on the side away from the product and outside the schedule and cost of the project. Successes can be demonstrated to the project team. The idea can be put into the product, but only following an established procedure of peer reviews, tests, and documentation.

Whatever the result, the programmer’s time is counted on his time sheet (or whatever form of accounting is used) as Free Time. The time isn’t charged to a project; the programmer doesn’t have to sneak around to use his imagination, and projects don’t suffer.

One other advantage of this type of Free Time is that the programmer doesn’t have to sell his idea. I have seen countless hours wasted by people gathering information, preparing presentations, trying to “get on someone’s calendar,” and selling, selling, selling. These “let me sell you on my idea to try” efforts waste the time of not only the programmer, but also of the people who have to either give or withhold permission.

I recommend you try this type of Free Time. I find no magic in the numbers 10% and 20%. There is good in almost any percentage of time or amount of hours. I do find magic in the basic concepts:

• experiments are done outside the product and project
• successes are integrated into the product and project using established procedures (NO SHORTCUTS FOR ANY REASON)
• no time is spent selling the idea to gain permission

Footnote: A form of this idea was related to me in private correspondence with consultant and author Jerry Weinberg (http://geraldmweinberg.com).