Sunday, August 14, 2011

20% of blue sky

Motivating software developers in a scientific research environment... 
...and getting benefit from it

Having managed individuals and teams of bioinformaticians (i.e. developers creating software tools for life scientists) and observed practices around me in other fields (and literature), I try to address the question of how to create an environment where people feel good, work at their best, produce good software and get fun from it.

There is much more to say (and so many books to read) about how to build such an environment but I will present here some views on one particular aspect, the 20% “free” time, that can easily be implemented, and the kind of benefit the company can get.

After exploring the concept in the industry, we’ll try to make a proposal on how can (and “why should”) a research center (academic or private) implement the 20% rule for the tool maker developers.

Who do we try to motivate here?
I will not look at “extrinsic” motivation, such as salary, bonuses or raises, but we will focus on intrinsic motivation.

More precisely, I will try to focus on how to motivate talented programmers, the one you want to recruit and to keep on board. It’s hard to define (but easy to spot) what is talent: a mix of pure energy, analytical skills (to apprehend new problems or technologies), efficiency to design and write code, fast learning aptitude, imagination, no fear to dive in the unknown, curiosity, natural sense of priority etc.

If there is certainly order of magnitude in efficiency between some developers, one can also observe big change in productivity if the same developer is in a good or a bad environment.

What does a developer want to be (professionally) happy? If we observe good developers, a very common pattern is: they are passionate, they are ready to work hard and to commit themselves on painful tasks, but they want to have some fun in their job, some excitement. I would even go further by stating that he/she want to have time to work on their side projects, whatever they are.
Ok, this not the unique reason to be happy, but it is certainly a necessary one.

A first solution: offering part-time
Well, that’s the dream for many developers, but not possible for many companies.

When I interview a developer who wants to work part-time, the deal is quite simple: “I offer you to work 80% but the amount of work I’ll ask you (not the number of worked hours) will be same as for a 100%”.

The most common situations I faced have been with people where their free time was used for some technology oriented side projects. We will try to address in the next section how such side projects benefit to the worker health, equilibrium, efficiency and happiness, and how it is integrated in certain companies

20% “free” time in industry: coupling motivation with innovation
Some big companies have stated a rule of 15-20% free time for their engineers. 3M and Google (Bernard Girard The Google Way, chapter 5; are certainly the most famous. Their first goal is to offer to their engineers some space to grow their own project, that will be internally reviewed and maybe elected for the next company innovation.

This first goal was a success: famous products coming from these personal projects are countless (post-it, orkut etc.).

Much more benefits than only innovation seeds
Experience have shown that there is much more value created from this free time:

  • it is a very good recruiting argument;
  • increases company loyalty and lowers turn-over;
  • one day a week, the developer can release the pressure of working totally embedded with the team on a big project and experiences freedom;
  • offers a possibility to gain respect from peers, which is a very high value in the developer scale;
  • employee push up the pressure on their four “duty” days to be ready for the free one.

A proposal: why and how the 20% rule for software developers in a research environment
After exposing the previous points to a laboratory head and trying to gently spread the idea that it could be a good idea to implement the 20% rule for the bioinformaticians, they are often two answers:
  1. we are already late on the schedule, do not ask for one day off per week! 
  2. why should I offer that to my bioinformatician and not my scientists? 

For the first point, experience clearly show that driving the troop to exhaustion in software is the easiest path to poor deliverable. Without a high personal commitment, you can expect nothing good to be produced by developers.

To answer the second point, and neglecting the fact that it is harder nowadays to keep on board a decent software developer than a decent biologist, we can say that the scientists are on the front line for the research and that usually the bioinformatician produces tools for the scientist (well, it not that black/white as the software can also have it algorithmic research component). Glory, conferences, articles will usually go to the scientist and only indirectly to the tool maker. This matter of fact is often totally normal and accepted but we should therefore realize there is a difference in the underlying motivations.

However, putting aside this subjective answer, there are more objective reasons to let a free space around the developers.

20% rule here? what for?
Beside the argument exposed in the previous subsection “Much more benefit than only innovation seeds”, there are objective reasons to allow room for this time:
  • technology (libraries, frameworks, programming languages...) is moving so fast that time is needed to keep on track and sort out the best of what is currently available. There is often no other solution than trying. 
  • Sharing knowledge with peers is important for the global education and personal reputation. 
  • Pure innovation: letting for example a developer play with data and a visualization frameworks can lead to original discussion with the wet lab scientist. 

What topics should be addressed here during this 20% time slice?
It is common sense to state that “free” time should be used for project compatible with the research center interest (if a developer is working for an institute focusing on breast cancer, it is not totally obvious at the first glance how a contribution to a new plugin in google map will be profitable for the institute).

The project a developer wish to work on should be very simply defined up front (a couple of lines are enough) and agreed with the manager. Following google rule, a public weekly report of five sentences is enough to keep track of what is going on.

A few suggestions of topics that could be addressed:
  • any project that is clearly aimed at discovering a technology that could benefit the organisation (waow! what a large scope for a first suggestion); 
  • contribution to an open-source initiative used in the main projects; 
  • prototype on an idea following a chat with a biologist at the cafeteria; 
  • etc.etc. 

These personal projects should be presented to the colleagues on a regular basis (experience shows that informal presentation of such projects can hardly be refrained...)


No comments:

Post a Comment