Microsoft vs. Google: Part 1 Grassroots Innovation

This is the first in a series of posts comparing aspects of the culture of Microsoft and Google from the viewpoint of the author who spent time at both. Today's topic is their approaches to grassroots innovation.  

Anyone who has worked at both companies can't help but to compare their culture, review models, working habits and so forth. When Google was still small, it was an impossible comparison to make, but now that they've shed any claim to startup credentials the gap between the two is narrower than ever. Yet still some interesting distinctions can be drawn. Certainly Google has an advantage in birth order as it has had a chance to study its older tech sibling, mimicking the things it liked and jettisoning those it did not, but in a number of cases, Microsoft has turned the tables on Google and innovation is one area where Microsoft may very well have a more fertile environment and a more workable model.

Microsoft and Google have, in turn, been the most admired and seen as the most innovative tech company in the world. Both companies’ ability to continue to innovate has also come into question. Call it the innovator’s dilemma if you like, but innovating yourself to the top of an industry automatically makes continued innovation harder. Successful companies become beholden to the products that made them successful. There is feature iteration, maintenance, operations, support... Being successful signs you up to a profitable business rhythm where innovation plays, frankly, an optional role.

To their credit, neither company treats innovation as optional and both have systems in place for both top-down and grassroots efforts. Both have official research divisions full of accomplished scientists. Both have ties into academia. Both have dedicated teams who think about the future day and night. Both have successes they can point to. However, both companies are obviously aware that innovation isn't something that always happens so purposefully. Their grassroots efforts at innovation clearly show they believe (correctly) that creativity isn't governed by a person’s title or the org in which they sit. Creative people can literally be anyone and are often those without advanced degrees (Gates, Jobs, Zuckerberg …) and without an entrepreneurial track record (many top innovators have been one hit wonders). However, they take a very different approach to encouraging the masses to innovate. The bottom line: with 20% time Google lowered the bar for innovators and thereby watered down the value of the results; with its Garage, Microsoft raised the bar and created a more sustainable model.

Google popularized grassroots innovation with its famous idea of 20% time. Any engineer could take a day a week to work on an idea that has nothing to do with his or her day job. No structure to slow you down. No forms to file or permission to obtain … just go do it. Gmail, now a strategically important web property, had its genesis as a 20% project. It evolved into prominence despite the absence of executive-level strategic thinking over the importance of web mail. That’s the magic of grassroots innovation, it gives creative employees the potential to make a big impact on their company's success.

Calling it 20% time clearly exposed Google’s tolerances to how much of an engineer’s time innovation could consume. It set boundaries. Further, since 20% projects don't officially factor into an employee’s performance review (which determines bonus) the work you do there can have a negative impact on your pay. Still, for every employee who fretted about being compared to engineers focusing 100% on their day job, many more sought out 20% projects because 20% was so entrenched in Google's culture. The fanfare around 20% time meant that not participating implied a lack of creativity. There was stigma associated with it.

Internal websites advertising 20% projects popped up as enterprising Googlers recruited others to join their little "startups." Since anyone could do anything with their 20% time, Google was literally awash in pet projects and harebrained ideas proving that you cannot create innovators. Innovation is hard to plan. Surely there were killer projects among the crowd but who could tell? The signal was lost in the noise. A manager with a 50 person org was probably supporting 30 or more 20% projects he or she knew little about. What started out as a way to foster innovation at Google turned into chaos.

And, as with any well-meaning policy, there were those who took advantage of it. In my 3 years at Google I met any number of engineers whose 20% was basically staying at home a day a week and taking naps. Or, as one put it: “a method and apparatus for improving productivity for 80% time.”

In retrospect Google's 20% time suffered from two fatal flaws. There was simultaneously too much fanfare and not enough exposure. On the fanfare front, Google over promoted their culture of innovation to prospective employees. Recruiters prattled on about 20% time as an official company benefit along the lines of medical insurance. Engineers felt compelled to take part whether or not they had actual innovative ideas. On the exposure front, there was simply no down side to failing at your 20% project. There was no official mechanism for oversight. Whatever you did for your 20% was your business. Failure happened quietly and without much attention. Unfortunately, success also happened quietly and without much attention. Google often discovered cool 20% projects when the engineers doing them quit the company to pursue their idea as an actual start-up.

At best, 20% time is a slippery slope. At worst it's a really bad way to organize innovators.

Enter Microsoft, or rather, its engineers.The Microsoft Garage is a bonafide grassroots effort. No executive sponsored it. Steve Ballmer didn't say "sure, take a day a week and innovate." In fact, no one even bothered asking him. Executives giving such permission is the opposite of grassroots. Instead, Microsoft modeled its Garage on the concept of "hacker space," (c-base in Berlin is a good example) a place for coders to gather, work and interact that has all the tools they would ever need.

The shared space part is important. It puts innovators in close proximity of each other. It takes them away from their desk and the distraction of teammates. it gives them the tools they need to tinker, machines, cloud accounts and storage, dev environments and so forth. Garage founders began by squatting in empty offices before finally earning space in one of Microsoft's original buildings with, you guessed it, actual garage doors. Just like a start-up, the Garage movement had to prove it could be successful before it got space of its own.

The Garage attracted people with colorful posters around campus urging them to "stay late and code!" The curious sought it out. The innovative stayed to code. Concepts were vetted, groups were formed, expertise was shared. Community was built by getting gurus to give Garage Talks. Experts on various tools shared their experience. Garage hackers got good at TFS, Azure, the Bing stack and so on. As I search around the company for talent for my team, I scan resumes looking for Garage experience. It means something to me, these folks not only know how to innovate, they have mastered an important set of skills.

The Garage dispensed with the fanfare that doomed 20%. Advertisements were ominous. "Stay late" specifically excluded the 9 to 5ers. "Code" made it plain what was important. If you want to sit around and postulate, go somewhere else. Code is spoken in the Garage.

For those who can't stay late, "Garage Weeks" are held occasionally for enterprising engineers who want to spend time in the Garage as their temporary day job.

The lack of exposure was the next problem the Garage tackled. Like trees falling in an unoccupied forest, innovation that stays in the data center or on your desktop doesn't get heard. Garage founders solved this by holding a science fair. That's right, a science fair, just like your kid's elementary school. But unlike your third grader, the judges here don't hand out ribbons for "participant." The Garage science fair has teeth.

The science fair time-bounds a Garage project. It creates real pressure, an urgency to get something done. It also provides a chance to get feedback from people who understand the industry and where it is headed. Feedback is not sugar coated. Think "sales pitch to a VC" and you are getting close. You need to be sure of your idea. You need to do your homework and perform due diligence. You need to be able to convincingly explain things like business value and customer need. During the Online Services Garage science fair, I saw presenters told bluntly that they had solved an already solved problem. Others were questioned hard about the underlying code and challenged to defend their design decisions. It’s not just about the flashy demo; it’s about really thinking your idea through the way an actual startup founder would.

Partner-level judges roam the fair judging the demos based on business worthiness, creativity, design and so forth … criteria set out in advance. The two primary award categories are for business value and thought leadership, this says a lot about the Garage. It's not about pet projects, it is about doing something that has value. The judges often arrange introductions for the innovators to internal teams that might provide good collaboration. If your Garage project is truly innovative, the science fair could be your ticket to sponsorship by a product team.

Winners of the judging round stay at their booths for a tour by the division president who selects the overall winners. Good Garage projects are guaranteed an audience of influential people with strategic insight into company direction. Nothing hits the spot like hearing a Microsoft president make a comment along the lines, of “what would it take to make this ship worthy?”

After all, what happens in the Garage should not stay in the garage.