An idea to implement R&D in a software services startup

I have seen that working in a fledgling software services firm as a programmer entails a lot (in fact, all) of the time being spent working on meeting client specs and requirements on their software projects as well as shuffling between different projects. So much that little effort can be made to sit and research (and then work) on new and exciting technologies. For instance, HTML5 holds wonderful prospects on both web and mobile platforms but since it is still bleeding-edge (hence difficult to convince clients to use it) and relatively new (hence the lack of developers proficient in it), it's difficult to implement it on the projects.

My question is, does it make sense to allocate a few hours in a week (say, 2-3hrs on a particular day of the week) to let programmers/developers work on the tools and technologies that they are interested in with the aim of (what I see as) fulfilling the following:

1. The developers are happy since they get to learn about and research on cool stuff.
2. The company can (and ideally should) benefit from the research, say for instance, we learn that mongoDB databases are a better choice to implement on future projects than memcached-MySql.

Of course, there could be some rules put into place to ensure productivity and output such as pairing between programmers, giving a presentation of the research or a rudimentary demo application of the subject just researched. Not everything has to be bleeding-edge though. For example, one could weigh the benefits of using Groovy web framework over Spring (both of which are old technologies) and use the former in the next java-based web project.

The underlying question remains if its a good thing to implement this idea in a startup where finances are client-driven? How do you convey this message to the client (that for so-and-so time period, we won't be addressing your concerns)? The idea is to retain talent in the company and deliver "cutting-edge" software products using the best tools and technologies. Would you strongly disapprove of it? And if you concur, how would you feel is the best way to go about it?

This may be obvious (to echo @Jeff Oresik's comment), but why would you need to tell your clients that your developers spend 2-3 hours a week on R&D?

Assuming it's a small shop, you're probably handling a lot of overhead by yourself already (accounting, taxes, office concerns if you have one, etc.) If you met with your accountant on a Friday morning for 3 hours, do your clients really care to know that?

One other idea: treat the R&D projects exactly as you would a client project. That means making the R&D time billable (to you, however), which means developers submitting invoices, and an emphasis on tangible/useful results. You'd have to do this anyway for tax purposes, if applicable. Have developers come up with estimates for projects. This process means the R&D projects that are proposed are given more thought to how they will be useful, and with concrete goals and an end game.

Personally, that setup wouldn't stymie my creativity for R&D, but some might complain the "process" would. If you want it to be more like actual downtime, then explicitly make it so. Set a 37hr week policy, and increase developers' rates/pay to match what they were getting under 40hrs.

...if its a good thing to implement this idea in a startup where finances are client-driven?

I think it's an excellent idea (if implemented correctly). This is a great way to not only attract good quality programmers, but also to hold onto your existing employees. Employee morale and motivation is a huge factor in your company's success. 2-3 hours a week is not a whole lot (assuming a 40 hr week), and shouldn't impact your bottomline all that much.

How do you convey this message to the client (that for so-and-so time period, we won't be addressing your concerns)?

You don't. Your clients don't expect you to be working on their project 24/7. They know they are not your only client, and that your programmers must split their time among all the projects. Your clients don't expect you to tell them: "We will work on your project from 8:00am to 11:00am on Monday." The only thing you need to tell them is that "this project will take X amount of hours to complete, and will be completed by Nov 15, 2010." How it gets completed in that timeframe is not their concern.

how would you feel is the best way to go about it?

1. I would recommend that you don't make all of your programmers spend their 2-3 hours at the same time. They should schedule their research time at different times during the week, so that you are always working on a paying project at all times, versus stopping all work at any given time.
2. Also, don't schedule the time for them. Let them manage that themselves. If you tell Bob that his research time will only be on Thursdays from 9am to 11am, you can be sure that Bob will stop whatever it is that he is doing at 9am on Thursdays. If Bob is being really productive at that time and is on a roll, it would be bad to interrupt that. Let Bob fit in his research time during his downtime or when he needs a break from his programming tasks.
3. Make sure you include something in your employee contract about this. Any IP created during this time belongs to the company, not the employee.

There are many examples of company transition from a service company to a product company, 37signals being one of the most famous one.

Doing client work can be not very fulfilling -- you have to do what your client asks and usually this doesn't envolve playing with the latest cool piece of technology. That's understandable.

You want to talk with your peers what your ultimate goal is. If you want to build a product company that's fine. You can start with one or two guys, try different things and see if something gets traction. Just articulate clearly that time spent on "researching product ideas" is an investment -- it's time not spent on client work (non-billable) and you might never recover it.