The Lean Nature of Google's Development Practices

First, a bit of disclaimer, I'm not privy to the details of Google development practices. I'm gathering this information from multiple public sources such as the a set of notes recorded by Evelyn Rodriguez on the subject, Joe Beda's blog and an Newsweek article written by CEO Eric Schmidt.

For the uninitiated, Lean Production is a set of princples and tools first conceptualized by Toyota in the 1980s (a.k.a. Just-In-Time, Kanban system) to support its auto manufacturing business. Mary and Tom Poppendieck subsequently leveraged the ideas and defined a set of seven lean principles for software development:

1. Eliminate Waste - Spend time only on what adds real customer value.
2. Amplify Learning - When you have tough problems, increase feedback.
3. Empower the Team - Let the people who add value use their full potential.
4. Deliver as Fast as Possible - Deliver value to customers as soon as they ask for it.
5. See the Whole - Beware of the temptation to optimize parts at the expense of the whole.
6. Build Integrity In - Don't try to tack on integrity after the fact - build it in.
7. Decide as Late as Possible - Keep your options open as long as practical, but no longer.

The question I would like to pose is "how close does Google's development practices match Lean software development?". In addition, what does Google do that goes beyond Lean Software Development? So let me then go through each lean principle and see what Google has to say about it.

Eliminate Waste - Google teams are small, agile engineering teams 3-person units, that don't have departments and is co-located and sit next to each other and also with Project Manager. Documentation is very sparse and only what is needed is a Product Requirements Document. Here we see that Google strives to elimate waste by reducing paperwork, the need to wait for things to happen and the motion required to find an answer. That is when you "pack them in", you make communication eaiser, there is "no telephone tag, no e-mail delay, no waiting for a reply" says Schmidt. Schmidt adds that "sitting next to a knowledgeable employee was an incredibly effective educational experience". Schmidt subsrcibes to Druker's "strip away everything that gets in their way."

Amplify Learning - Google applies both statistical analysis and feedback on the iterative delivery of their products. The attempt is to make good products better over time. Information sharing in Google is the norm, according to Joe Beda:

"The intranet in Google is super transparent. Teams are actively encouraged to share the most intimate details of their projects with the rest of the company. This happens through tech talks, design docs, lunch table conversations, etc. There is, by and large, only one code base at Google.

Schmidt gives some light on how Google development enables synchronization:

Make coordination easy. Because all members of a team are within a few feet of one another, it is relatively easy to coordinate projects. In addition to physical proximity, each Googler e-mails a snippet once a week to his work group describing what he has done in the last week. This gives everyone an easy way to track what everyone else is up to, making it much easier to monitor progress and synchronize work flow.

Empower the Team - Every member of the team is empowered in that they can spend up to 20 percent of their time on a project of their choice. The company maintains "an ideas mailing list: a companywide suggestion box where people can post ideas ranging from parking procedures to the next killer app." The ideas mailing list also provides "the ability for everyone to comment on and rate ideas, permitting the best ideas to percolate to the top". In addition there is a brainstorming session every week. They maintain collaborative workspaces (ex. Wiki) on the web with editable pages for further exploartion of new ideas.

It is distinctly unique in Google practice that decision making is done via consensus. According to Schmidt:

Modern corporate mythology has the unique decision maker as hero. We adhere to the view that the 'many are smarter than the few,' and solicit a broad base of views before reaching any decision. At Google, the role of the manager is that of an aggregator of viewpoints, not the dictator of decisions. Building a consensus sometimes takes longer, but always produces a more committed team and better decisions.

Deliver as Fast as Possible - The prefer delivering a good solution quickly rather the best solution ater. It is not atypical for Google to release services in Beta to quickly test out feedback from users.

See the Whole - According to Joe Beda:

When two teams are doing similar things, people start with the assumption that they must have their reasons and that the situation will be worked out in time. There isn't a huge push to over optimize and have only one solution for each problem. This means that there isn't an adversarial relationship between teams that can lead to long standing animosities and information hiding.

Google uses data to drive decision making. Schmidt writes:

At Google, almost every decision is based on quantitative analysis. We've built systems to manage information, not only on the Internet at large, but also internally. We have dozens of analysts who plow through the data, analyze performance metrics and plot trends to keep us as up to date as possible. We have a raft of online "dashboards" for every business we work in that provide up-to-the-minute snapshots of where we are.

Build Integrity In - Google's process is based on User-centered design. It is focused on quality and asks: "What does user really care about?". Through experimentation via public sites they can assess if users respond well. In fact, Larry Page has an interesting philosophy "There is “no such thing as a successful failure; if it is useful to people, later we can make revenue from it in a logical way." In short there is an emphasis on providing true value to a user first, and sometime along the line a monetization team comes along to figure out the details.

Decide as Late as Possible - Eric Schmidt describes Google's process as "a late binding decision-making process". The fact that for Google projects, the issue of monetization is addressed extremely late in the game starkly differentiates itself from just about everyone else. This late binding strategy and its $100+ market cap should just give just about everyone else in the industry the shivers.

Google's software development process from the perspective of Lean Software development principles show nothing that is out of the ordinary. What is not ordinary is the massive scale that they are applying these principles. What Google apparently seems to understand that monetizing the internet is in the realm of "Unforseen Uncertainty". Just as Google has leverage a massive number of low-cost off the shelf servers to power their search engine, they are equally leveraging a massive number of lean software development efforts in support of their search for monetization opportunities.

Web 2.0 companies like Flickr have shown how little it takes to build a business, Google replicates this effort to who knows how many yet-to-be-announced concurrent efforts. The late binding strategy to monetization is what makes the process truly unique. Unlike the venture funds which base their funding on potential monetary gain, google bases their funding on a collective decision that does not necesarilly involve profit in the equation. This puts the venture community in a conundrum. Web 2.0 business are at a scale that do not need venture funding. Google is investing heavily in such efforts that appear to have no-monetary upside. These are clearly blind spots that one can't afford the risk of not seeing.

Eric Schmidt summarizes it best when he said:

Our goal is to get more at bats per unit of time and effort than anyone else in the world.