Lessons from Google by Petra Cross

On Monday 30th of April, Ostrava hosted joint Google User Group (GUG) and Java User Group (JUG) event with Petra Cross from Google. Petra is Czechoslovak IT celebrity because she is the first (Czecho-)Slovak developer in Silicon Valley ;)

The topic of her session was about the way of software development in Google, but she talked also about other important aspects that are not so tightly connected to way of working, e.g. culture, organizational structure, targets, measuring performance. Although Petra talked about known Agile concepts of Google’s way of working, it was more cultural insight provided by one Googler (this is how they call themselves). In this post, I want to especially emphasize some points related to their organization and team autonomy because they are the key drivers of Google’s efficiency, value delivery, prestige and Google teams’ motivation.

The key aspects to be discussed further are following:

  • Flat organizational structure in Google (only 4 levels from specialists to CEO)
  • Small feature-driven product teams (about 4-6 people in one team, typically more teams per product)
  • Team defines their development process respecting just 2 corporate rules (code reviews and frequent releases)
  • Instant knowledge sharing and learning driven by people
  • Google’s vision translated and communicated on daily basis by leaders

Let’s discuss each of these aspects.

Flat Company Structure and Small Team Size

Traditional hierarchic organizations need a lot of levels of management, restrictions and control because of following Taylor’s scientific management assumptions known and used mostly in 19th and 20th century (followed and promoted by Henri Ford):

  • People are bad and lazy and therefore they need direct control and external motivation.
  • People do not know how to proceed with their tasks; they need to be told how to do it.

And both tasks are management tasks. But Google follows modern research (means 50 years already) and knows that:

  • people are good by default, but context forms their behavior;
  • people are internally motivated to work if they can do what they are good at, do it with people they want and if they know the purpose.

Thus Google continually focus on creating the right open environment where people have autonomy to do what they perceive is needed instead of hierarchically controlled one when people wait weeks for decisions done somewhere above. If your emotions started to rise when reading this section, I would recommend you to read some of the following summaries of current research. Some evidence and context is covered in my short intro to Human IT (in Czech language) or in great book Freedom Inc. by Carney and Getz.

Google flat organizational structure thus supports such environment and looks quite flat:

  1. CEO and his small board
  2. Area managers (I forgot how they call them exactly)
  3. Product Owners
  4. Feature-driven Product/project teams with TechLead

That’s all, nothing more. Small teams with autonomy (control) and responsibility, not any single manager (or team of managers on different levels) managing them. If you want to have flexible organization quickly reacting to changes in the market you need to have self-managing teams making decisions in real time in their environment. Several levels of managers approving even simple change (e.g. in way of working) forbids this needed flexibility. Of course, team need to understand and follow the corporate vision. And this is the task of leaders (no managers anymore) to explain the vision on daily basis in the context of team work. This requires a lot of coaching: repeating the vision and asking a lot of questions, no more restrictions killing people motivation, innovativeness and creativity. The evidence of this fact is that Petra started her presentation by vision explanation. Do you know other developers from any company that start their presentations about some fancy technical stuff with vision explanation? I don’t.

You may ask important question: “But how the team knows what is needed by the customer and what market requires?” Knowing Google vision together with Product Owner (PO) role is the answer. PO discusses all the stories with TechLead and stores them in so called icebox. Team then decides what will go to backlog based on priorities stated by PO. Icebox is important, because it was proven that many functions are just perceived as important and are never needed or used. It is the same with our home icebox. It stores some stuff that is used later or even never used and thrown away. Of course PO pushes the dates and wants to develop everything now, but TechLead knows team velocity. Velocity tells the team what can they manage and what not. Thanks to that, development in Google is quite predictable and also PO knows what to expect and when.

In addition to product teams Google also forms project teams for shorter project periods (weeks to month) to manage work that needs to be done in the near future. People can choose to become part of these interim teams by themselves, no internal resourcing organization exists in Google.

Short exercise: compare Google’s situation with yours:

  1. How many management levels is between you and your CEO (if working for corporation)? My experience is about 7 levels of management in typical corporation! You can imagine how quickly information flows and its correctness and possible misunderstandings. Have you ever played Chinese whispering? Yes, it is sometimes the same. It is maybe one of the reasons why ordinary people do not understand or do not care about corporate vision and strategy. Nobody translates it to their language, what it means for them in their daily life, thus they simply misunderstand it or do not understand it at all.
  2. How frequently is your manager (leader in better case) explaining you vision in your speech? Never? Monthly? Weekly? Daily? How often is (s)he asking questions to understand your situation and obstacles? Does (s)he even have time for it?

My example answer:

  1. 4 levels between me and our CEO in case of our team.
  2. Daily, minimum weekly in weekly retrospective. We have also team retrospectives quarterly where we clarify corporate and our vision together with our direction.

Software Development Process defined by team

I was surprised by Petra’s statement that every Google team has its own development process. That’s clear for me, different products, people, technology and experience need different process, but still we hear from every corner that this would be mess and anarchy. We need few processes (for projects, products, customization, etc.) mandatory for all teams, doesn’t matter if team of young talents or team of senior engineers. Same detailed descriptions for all. Do you know what this does with people and their activity, proposals, creativity? ;). Detailed procedures don’t let any room for mistake but also for creativity and heavily affects people motivation. Any room is actually not true, we are people and as such make mistakes in manual repeating tasks without automated support. Anyway, Petra continued with the description how different process in each team can work and mentioned the key. There are just two mandatory rules(!) each team with their development process need to follow:

  1. Mandatory code reviews in any form (e.g. special event, pair work, standalone review by senior).
  2. Frequent releases to one common product branch in repository.

Only these two rules need to be followed, the rest is up to the team and their knowledge, skills, experience, set up but also considering technology possibilities and limitations. Of course, team members know the best what they need, they do the job!

Frequent releases force people to make things simple and commit only done, tested and reviewed work. This work must be covered by automated tests that must pass on daily basis. Regular and frequent releases also help team to avoid issue of merging many branches before release date. I was also a bit surprised by the fact that not every Google team does follow Test-Driven Development (TDD). But maybe it is not needed because of mandatory code reviews and automated unit and functional testing. Anyway Google teams are quite Agile and automated even without TDD.

Exercise two:

  1. Can you/do you follow the same approach? Can you define just few basic rules to be followed and incorporated to teams SWD process by team itself? Can we trust software engineers they know how to develop the software? Or shall we tell them? ;)
  2. Check just for yourself how Google shares stand in comparison to yours. Should not you copy good patterns from successful companies?

Instant knowledge sharing

One very interesting thing that attracted my attention was the way Google developers share knowledge and improve their skills. To my understanding Petra mentioned no functional lines and line managers artificially utilizing and improving developers’ skills in Google. The key team knowledge sharing and skills improvement is the way team develops and works with Requirements backlog. Developers take the first story on top of backlog, not the one (s)he knows, not the one (s)he likes, but the one on the top. If this person doesn’t know this area in the details or at all, (s)he asks instantly the person that knows this area more and pair work for some time. This is how Google teams avoid knowledge islands in the product code base known just by one person in the team. Be honest and ask yourself: “Did it ever happen in your team, that there was some requirement waiting for one specific person coming back from business trip or holiday?” Learning by doing is the most efficient way of learning. Researchers say you remember about 70% of such experience. Compare it with training lessons from which you remember only about 10-20%. I do not know how they organize and manage for instance trainings and certifications for their developers (if any) when they do not have functional lines. So the question is: “Do you need functional lines? Isn’t this better way of sharing and utilizing the competence?” Aren’t there more efficient ways how to share and utilize knowledge?

Another mechanism how senior developers in Google share is well known concept of 20% of time dedicated to their own projects they believe. Googlers spend their 20% (sometimes known as free Fridays) not only in R&D type of projects but usually also on coaching their colleagues, knowledge sharing, coaching people outside the company or travelling to conferences. This is very natural way to share the knowledge, self-organized with no control and push.


Simplicity in form of flat organizational structure, just basic natural rules to follow in SWD process, team autonomy and daily support by servant leaders explaining vision of Google is the key factor to Google’s efficiency, value delivery, prestige and teams’ motivation. Can this be the way forward for your company as well? Or is it something else hindering you knowledge workers (developers, analysts, maintainers, specialists) to be flexible and deliver the value to the customer? Please share

Máte k tomu co říct?

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *