Saturday, December 22, 2007

Life by committee, or management Google-style

At Microsoft, the job of a manager is perfectly well defined.

A dev lead is responsible for productivity of the elementary organization unit - the development team. He or she owns a feature or a group of features in the product, and is primarily responsible for success of these features in the market.

To do their job well, dev leads have various tools at their disposal. For example, they write their employee's reviews, have weekly 1:1 meetings with the people who work for them, and are primary contributors to team hiring efforts.

A dev manager is responsible for health of his or her development organization. He finds and appoints dev leads, makes sure that individual contributors are successful, ultimately owns all performance and underperformance issues, and is primarily responsible for the success of the product's implementation in the market.

A dev manager also has plenty of tools in his or her arsenal. They write reviews for their leads. They decide who gets hired on the team. And they mediate the agreement between the leads on respective merits of individual developers when it comes to stack ranking on the reivews.

Test and PM leads and managers own identical roles in their disciplines.

A product unit manager is responsible for smooth interoperation of all disciplines involved in bringing the product to market. He or she is also the primary point of contact for intergroup cooperation issues, and is an advocate for the product company-wise.

General manager owns the product lineup, and is responsible for building the leadership team, setting the overall division strategy and investments.

And so it goes...

After 7 months at Google, I am happy to report that I have no idea what exactly is the role of a lower to mid-level manager at here.

I totally get what Engineering VPs and above do - their role does not seem to be any different from Microsoft. Below them there are engineering directors, who seem to own a lot of nitty-gritties of basic Google site operations (like finding buildings to rent), and most of the low-level (at MSFT PUM level) investment decisions.

Right below them there are line managers. Line manager is a person to which most engineers report. There is slight variation in their jobs - some of them (very few) have fewer employees (~10) but are active engineers, many are not really engineers at all, but have lots of employees (30-60).

The role of a line manager is a big mystery to me. Before moving to my new job in GEO projects, I met my manager in Gmail maybe twice (before I started looking for a new job, that is) in 5 months.

The question is, if a manager's face time with an employee is less than an hour a month, how can this manager do the manager thing? As it turns out, (s)he doesn't, at least not in Microsoft sense of the word.

Let's start with building the team. At Microsoft the team would start with a dev manager, who would interview the people and decide, along with another very senior interviewer called "an AA" (As Appropriate - a person whose job is to decide whether the interviewee has a career at Microsoft at large, as opposed to a single team).

At Google, hiring decisions are made by a committee of mid-career to senior developers called Hiring Committee. HC makes hiring decision "for Google", irrespective of any particular team where the person might work. HC members do not actually interview people - they review the written feedback from the interview loop. The interview loop is different from Microsoft as well - the people interview "for Google", not for any particular team, and they come from a bunch of different teams at the company. In fact, the person is not placed with any particular team before he or she is hired. The placement is decided by an Allocation Committee, structured similarly to HC, except with larger proportion of Eng Directors.

As a side note, this means that when an engineer interviews with Google, by and large he or she does not know on which team he or she will end up working. This is usually not a problem because changing jobs at Google is very easy. Excited by something else? Just finish your committments to the current team, and go to the next project.

Which means that managers don't do much of the team building. But surely, they do performance reviews? Not really...

At Google, performance is fully peer-based. Which means that your perf review is written mostly by people who work with you. You nominate them yourself, although your manager can add to that pool. The manager's role is only aggregate the feedback, and deliver it. Manager's personal opinion about your work is also on your review, but is worth maybe 10-15% of the total.

The results of the perf review written by your peers go to another committee, who do the salary review. This committe typically consists of engineers that do not know you (and for a smaller office like Seattle/Kirkland, are likely to be outside your office; likewise, SEA/KIR perf committees get mostly people from Mountain View), but are a level or two higher.

Finally, the promotions are handled by a committee as well. The employee is the one who decides whether to ask for promotion, puts together a promotion package, and sends it to a promo committee, which functions very much like perf review.

So Google's manager tools are very limited. He or she doesn't decide who gets hired; doesn't directly influence people's growth, and does not influence the technology (since most managers are not practicing engineers). What do they do? Who knows...


Eldar said...

> A dev lead ... owns a feature or a group of features in the product

I wish you followed the same principle selecting your own leads...

> A dev manager ... ultimately owns all performance and underperformance issues

I know one guy, who disagree with you. You know him too.

> And so it goes...

I think you draw a little idealistic picture, something they teach in management training classes for clueless new MS hires. In reality, ... oh, well... Maybe I'll right about it some other time.

About Google schema, I love it. Sounds like a godsend. Unless you have beautified it somewhat just like you did with MS schema.

Sergey Solyanik said...

Well, these are job definitions. Yes, it's an ideal world, and so they are not followed perfectly (and some times not at all).

It's the same at Microsoft and at Google - Google schema for example means that underperformers stay on board much longer than they should (it's a oft-cited complaint here, I am too new to really tell from my own experience).