"Best Practices" for a software research and development team?

Question

I have seen numerous articles and questions here on SO regarding best practices for software development in general. I am however after more specific best practices or guidelines focussing more on the research area for and R&D team.

For example, i have read that Google allows their developers to work on personal projects for one day per week to help drive new ideas and keep the developers familiar with multiple technologies etc.

Assuming a team is already in place (so ignoring hiring guidelines for now), my question is, what guidelines or best practices are known to drive an R&D team to be more likely to come up with new ideas and ways of utilising new technologies?

Answer 1

Not necessarily a proven technique, but very clearly outline before a project starts whether or not it has product or external-visibility potential. One of the attractions of Google is that most stuff comes out as a beta or as a lab or whatever. On the other hand, in places like IBM research they often build throwaway prototypes. Knowing these things in advance determines the quality of code and prevents subsequent disappointments.

Answer 2

Your question sounds like an industry R&D team rather than a university research team, and it has been 12 years since I worked in industrial research, so take these suggestions with a grain of salt:

• Bring a continual flow of new people in. Once a week you should have somebody from outside come and speak for an hour on a technical topic. Provide food, and make an effort to get good speakers. Bring in people from your sister development organization and from completely outside your company or university. When you bring people in, ask them who is doing the most interesting work related to your project or area of expertise. This process will help build knowledge and skills into your group and will eventually get you connected to the world experts in whatever you are doing. (If your own group is not large enough to sustain a speaker series, partner with another group.)

• Have you own people speak at least once or twice a year. If you are an R&D team and you are successful, you will eventually be asking for more resources or asking a development team to adopt your work. The more people you have who can speak articulately about the work, the greater your chance of success.

• Have short, frequent meetings whose primary goal is to keep the whole team connected. When I was running a group of 6 to 8 people building a compiler, we met twice a week for 45 to 90 minutes. Everybody, including me, talked about what have you done since the last meeting, what do you hope to achieve by the next meeting, and what is the next step you will take today. These meetings served three purposes:

  1. Kept everybody on the team aware of the big picture.

  2. Enabled the junior people to learn from the senior people.

  3. Got people unstuck quickly, before they went off the rails.

It's a great privilege to be in R&D and to have some say in setting your own direction. I wish you and your team the best of luck!

Answer 3

Clear goals are useful. Are you trying to create new products, better products or a revolutionary new idea? Are you trying to win patents? Does it need obvious commercial potential or just something that would get attention in a publication? Thats what I'd ask if I had someone paying me to do R&D.

Answer 4

Creativity seems to flow in natural ways and not so much when forced. It seems natural to want to improve the supporting systems around the team.

Being able to explore new technology while also being somewhat productive is a win-win. Therefore, one thing that seems to have been very effective for generating new ideas is to work on infrastructure type projects. By infrastructure I mean those projects that directly relate to team/company systems:

• New integration points into source control systems
• Exploration on how to make build times faster
• Integration into bug tracking software
• Exploration into crazy statistics/metrics and how to visualize these in interesting ways.
• Etc.

One can get very creative thinking of how to make the team better through improving/modifying/extending the software around it. With this natural approach, innovation naturally occurs. Once the brain starts thinking like this it's amazing what can take place.