Why You Need R&D And How To Get It For Less

If your development shop is to improve in technology and quality while outpacing the competition, you need some amount of research and development (R&D). This is especially crucial in shops seeking to expand their intellectual property portfolio.

However, the word on the street is that R&D is only for very large corporations such as IBM or Microsoft with billions to spare. I used to feel that way too, but I was pleasantly surprised to learn from the best in the business that there was a cheaper alternative.

It turns out that Google, as in so many other areas, has blazed that trail. Not by inventing the concept, but by proving that it could be done. The idea of giving developers a percentage of their bench time to pursue whatever idea they fancy had been floating around for a good long while but had been flatly rejected by others.

I recall a certain project manager who would say "we all want to have fun, but we got bills to pay." This appears to be the rationale in most development shops, especially if there are budgetary constraints. However, I would like to propose a way to get around this hurdle fairly painlessly.

The first step is to improve in the time management department. It is surprising how poorly time is managed many development shops. For example, although there are long days at crunch time, between patches and releases, time killing is pointlessly common or filled with meetings of dubious utility. Methodologies such as Agile have resolved this imbalance somewhat, but we need to go even further.

Developer bench time can be optimized painlessly if done gradually. I would suggest beginning with a 5% allocation for personal projects. This is the equivalent to two one-hour meetings in a 40-hour week, barely felt but significant enough to establish the practice and explain the principle.

The key is to make sure this is not seen by developers as a break or social time. In fact, I would suggest two rules to make sure what needs to happen, happens during this special time:
(1) No web surfing except for brief visits to coding sites
(2) Heads down coding throughout — no pressure on the quality or the amount though.

Do not expect much to happen the first couple of weeks except for some habituation. However, if this schedule is kept religiously and developers are asked to speak briefly about their "personal projects" during the warm-up for regularly scheduled meetings, expect to start seeing some incredible code being generated by week number three.

The beauty of this practice, is that you will start seeing improvement in the quality of the production code and even an increase in collaboration among the developers.

As you start reaping the benefits of this program and your team's productivity grows —by virtue of their becoming better developers and by virtue of some of their personal project code finding its way into released software— it will be easier to sell to management the idea of expanding personal project time to a healthy 20%.

But, be patient enough to do so gradually. It is okay if it takes two years to go from 5% to 20%. The practice will yield fruits as long as it is done properly.

So there you have it: a very simple way in which your shop can benefit from R&D without breaking the bank. You are welcome.