The Google Management Style

I recently found two interesting articles relating to Google’s management style. It starts with Steve Yegge talking about Good Agile, Bad Agile. Working along the agile development approach with some changes, this obviously interested me. In a sense he is right. On it’s own, without adaptation, without thinking, it is another fad that consultants will exploit. It is also true to many other things I have learnt about people management, so the general ideas underpinning agile software development are right.

After having worked at Google for some time he thinks he has understood the development process and I will take his word for it as the insights he give ring true.

They are not really using managers as such but mostly tech leads as they code themselves. In the end, I believe developers choose their tech leads themselves as different people have different skills and the “lead” part should be taken up by those with the most developed necessary skills of the moment. Management’s task is to facilitate that and get out of the way.

Another point is that you as a developer can switch projects and teams at any time. This of course requires a big company, as you need some amount of projects, and you need some system to make sure every project is filled. But more to that later. That you can spend 20% of your time on other projects is known and a good idea if you have the right people that will work on related projects any way as that inspires them.

They also have very few meetings, which again comes with clearly defined projects. “Make the search results appear faster” doesn’t require a lot of meetings other than with your collegues over a brainstorm.

The interesting thing is that there are no Gantt charts of date-task-owner spreadsheets. Nothing resembling project management as such. We are moving a similar way though. The thing is a Gantt chart doesn’t make you faster. Identification with the vision does.

You also don’t work insane hours (“unless you want to” with the “want to” being pushed a bit ;)) which again relates well to Joel’s point that 8 hours of creative work are all you get out of people. With 12 hours they are bound to do other stuff and you start getting higher turnover. If you do it all the time.

One important part that I didn’t know up till now is that a large part of Google relies on incentives. Your reward is in relation to how important management sees a project. The incentives are financial and in other forms. The “other” part comes from Google’s peer review culture, which I posted about recently. If you have good people and a peer review system, with financial rewards tied to peer reviews to a large extent, then the review of those peers, people you respect because you know they are good, will have a large incentive component. Check this:

_“I might have been mistaken, actually. Having your name and picture up on that big screen at End of Quarter may not be the biggest incentive. The thing that drives the right behavior at Google, more than anything else, more than all the other things combined, is gratitude. You can’t help but want to do your absolute best for Google; you feel like you owe it to them for taking such incredibly good care of you.”_

All this does though is to get people to work on the right projects. The best explanation is his first sentence on this:

_“At Google, projects launch because it’s the least-energy state for the system.”_

Ok, there are project managers, and product managers and all that. But they really only nudge. Teams sit together, lots of meeting rooms are there. Meetings happen in the middle of the day, and people come in early or late to keep the rest of the day to working.

But again the small pionts matter. Google takes _“things like unit testing, design documents and code reviews more seriously than any other company”._ That results in them having one code base, and switching teams and sharing code becomes easy.

The other thing is that Google is not date driven. Their drive is their desire to build something. Google wants things done as fast as possible. You need to create that urge.

Something I agree with is that index cards are not the optimal solution. We are actually using FogBugz here and it provides us with a good work cue, per project, per release. If you add time estimates it gets even more powerful but they tend to be a pain in a smaller organization. Don’t mistake this for trying to control people. It is just to have an idea of how much work is in front of you.

I also agree with him in that you can’t do too many sprints or too short sprints. You still need a bit of freedom. We are currently using two week sprints, but something have a break of a week in between or just cleaning sprints. What the sprints do help with is having a bit more structure above and beyond projects. Of course you can work on the next sprint tasks if you want, but everybody knows that there is a clear goal with the current sprint and that goal is something we all want to reach because we know why it is there. The date at the end is just to give us a clearer goal.

Then there is the part I fully agree with. You can do things, that are not really part of the sprint, but that will improve your productivity immensely in the remaining ones. I could make a sprint saying that this one does not have unit tests in it, or that the idea to move our javascript interaction to it’s own framework will cost us time … but that is short sighted, and this short bit might be super short.

Then Greg Linden talks a bit about all this incentive stuff. Gives it just this other bit of certainty.