Robert Scoble: Google’s geek-friendly “Do what you want for 20% of your time” isn’t “real” research friendly:
“Googlers point to their 20% time as proof that they are investing in research. I say that’s bullhockey. Why? Most of the Googler’s I know are pulling 70 hour weeks. Saying you get 20% of a 70-hour week to spend on what you want is like telling me I get to spend Saturday doing what I want.”
Part of the problem here is definitional. Companies often lump product development under the R&D moniker, however, most research groups (with a capital ‘R’, such as Microsoft Research) are quite different. They often focus on long term projects that may not make economic sense right now. I’m guessing that most Google employees spend their “research” time working on projects with much more immediate concerns and current practicalities.
As an engineer it’s important to stay focused on near-term practicalities, however, it’s also quite valuable to keep your eye on the horizon–whether that be six months or six years (or more) ahead.
In fact, when I work on a project I often spend some of my time on “side” projects. Why? First off, because it often gives me a different perspective on things. Sometimes it gives me a better appreciation for the value of the current solutions. At other times it leads to new features or products. Either way it gives me a chance to learn.
You see, generally I learn best from doing. So these side projects–often worked on at night or on the weekends–are my hands-on learning time.
As an engineer, though, one key thing to keep in mind is that most of the time a company cannot leverage these extracurricular projects. No matter how good they are. This can be true for any sized company. I imagine Google employees run into this too.
What kind of projects do I pick to do on the side? Sometimes I start with projects that will augment the main product line. This gives me a chance to learn more about the current system. However, I also keep an eye out for projects that are being burdened by process. What do I mean? If there’s a strong need for something new, but it appears that it’s going to cost too much to do, sometimes things grind to a halt and the need goes unaddressed. One strategy around this is to look for different ways to solve the problem or maybe only try to solve a portion of the problem. Or maybe try to solve the problem in a completely different way–leveraging different technologies.
Here are some of the 20% projects I’ve worked on in the past.
I once worked on a workgroup-based financial application at a small company that was selling enough to pay the bills, but couldn’t make traction against its competitors. In addition, customers were increasingly demanding the product suite move up to the client-server world. It was going to take a substantial amount of work to pull this off though–so the change wasn’t made. Instead the product was updated incrementally. About this time the Internet was gaining traction. We talked about creating an browser-version of the app, however, none of the customers wanted it. The technology was too new and there were too many unknowns. So what did I do? I spent my off time working on a browser-based version. About the time I had it done a customer was willing to fund a client-server port. So while we did the port we made sure to support an Internet version of the product as well. In the end, the customer opted for the Internet version and the originally spec’d client-server product suite never saw the light of day. Not only that, the browser-based version became so successful that the founders of the company were able to sell their business, retire and pursue their life-long dreams.
Things don’t always go this well, however. At another company, they were struggling with managing a code-base which they had purchased from a third party. The app was showing its age and didn’t do what the sales force needed. The company was betting big on this products and was trying to expand the product and grow it competitively at the same time. They tried many different things. Adding developers. Adding testers. Adding more sales. Nothing gained traction–yet the sales force was indicating that there was strong customer interest. So I tried an off-hours project to see if I could help out. At first I started with small apps, which more often than not I’d find out later that others had done already, but yet they didn’t really solve the problems at hand. Sales still lagged. Then around one slow holiday season I decided to ratchet it up and give it my all. I started building a new system from the group up. I started fresh in C++. The legacy code was all Turbo Pascal. I built a system that was compatible with their current client-server system modernizing the UI as well as adding a CGI-proxy and a browser front end. It took a lot of work and involved some feature sacrifices, but after a couple months I had a running prototype. The result? No one in the company wanted to align with it. It was an unknown. Most people were very concerned about getting laid off and they didn’t want to take any chances. It was all quite understandable. When you work on off-process projects, you have to be willing to accept that others won’t want to use it. You have to be satisfied with all that you learn.
In another situation I consulted for a small startup that had been struggling. It had consumed about $10 million in a relatively short period and was trying to focus better as it re-organized. When I joined they were taking a project that they’d built for internal use and were going to commercialize it. Their technical problem was that their code base was very Windows centric. The sales force told them they needed a cross-platform solution to be competitive. Unfortunately, they couldn’t quite manage to port their system. Once they started spec’ing out the changes they’d need to make and all the testing that would be needed, the cost would be too great and it would take too long. So how did I use my out-of-process time to help out? At first I started building tools for testing. This gave me a chance to understand better what the system did and the various file formats and protocols. After a couple months of this, I began my off-time project in earnest. Over the next month or so I built up an engine that replicated theirs at a functional level–only it was cross-platform (although I kept Intel-byte ordering to avoid having to change any file formats or protocols). From this point I continued to build out the system. In the end, the company couldn’t commercially leverage what I built. There were several reasons. On the technical side, I had picked a series of technologies which their lead developers were not comfortable with and they decided to go with Java instead. That’s fine. I was a consultant and they were going to have to live with the technological choices for far longer than I would have.
Finally, I have worked on a couple projects where I had no energy beyond building the main task at hand. Sometimes this happens. The scope of the core project is so vast that there is no time or energy for off-process projects. Personally, I don’t find this as professionally rewarding, but it all depends on the case at hand. For short periods of time, it’s fine. However, the longer the 150% focus is, the more my brain starts pondering whether there isn’t a better way. In fact, quite often the tiredness brings on creativity and like a self-correcting system I begin to contemplate alternatives, new solutions, and, yes, side projects.
Like Robert Scoble says, these side projects aren’t Research efforts on par with those at PARC or Microsoft Research, however, as an engineer I find them quite valuable and rewarding.