How Google Sold Its Engineers on Management | Hacker News Reader

How Google Sold Its Engineers on Management

hbr.org

69 pointsggonweb53 comments

I'm secretly wondering if Google actually pays for these articles. I spent almost 8 years at Google and decided it was time to go after a rather inconsequential change of four lines of code (excluding tests) took a design document, a few rounds of formal reviews and a number of more or less official meetings with the team manager and two tech leads - more than two weeks overall without any conclusion in sight.

"Four lines of code" tells us nothing. How many users did that change impact? And was it likely to be noticed by end users and in need of justification? Is it likely to lose Google revenue if it went south?

For example, it might take just "four lines of code" to change the Chrome's SSL padlock into a smiley face, but that would be a significant change, that would require hundreds of training docs' to be updated, and potentially re-training of end users.

I'm sure OP understands that four lines of code can be important. I think it was just different from what they were used to at the early stages of the company, where there was perhaps less oversight of engineers. Oversight is necessary at a company the size of today's Google, but it's also possible to be over-encumbered by bureaucracy.

Just based on human-hours per line of code alone, that level of oversight isn't possible to maintain over that large of a codebase, so it seems impossible for that to be the regular case.

More likely it's highly dependent on where that code is, your exact manager chain, etc. It could just as easily be that you picked the week a new manager started or a new process was put in place that turned out to be terrible and was so rolled back.

> More likely it's highly dependent on where that code is, your exact manager chain, etc. It could just as easily be that you picked the week a new manager started or a new process was put in place that turned out to be terrible and was so rolled back.

Absolutely. There are many good and valid reasons. The net result though is the same in terms of the impact to GP's personal productivity. People tolerate bureaucracy to different degrees, and it's a personal balance for everyone.

One line of code, six months of process. But it was code in the module that computed stress on the space shuttle's interconnects between the orbiter and its tanks during launch.

The six months of process was the minimum and all I wanted to change was a goto, eliminating a dead code branch. I can't even imagine if I had tried to make deeper changes.

Having said that, there have been times when I wished Google had a process that would keep some of their odder mistakes from happening. Most recently the android calendar client changes. No month view, really?

The amount of review you mentioned could be excessive or just the minimum because the entire product was sensitive or high risk. With no context it's hard for us to judge.

What product area did you work in? Google is certainly a big company and different people might have different experiences, but when I worked there (on image search) I didn't see that sort of culture anywhere around me. It sounds like other people didn't think those lines were inconsequential.

I worked in one of the infrastructure SRE teams. These four lines exposed via an RPC a certain state of the system that its internal customers often needed to know but were unable to find out on their own without specialist knowledge so they ended up filing tickets. Those four lines of code simply embedded that knowledge. I'd imagine a good analogy would be marking a private method public in an API. So in that sense those four lines were not cosmetic and they may warrant some discussion and a mgmt-level decision. But I was completely unprepared for what followed.

I suppose what I'm trying to say is that the problem was obvious, the solution was obvious and whether that was the right solution to the problem could be discussed but did not require that level of decorum and could have been handled without engineers' constant involvement.

One solution to the tech manager problem is to force managers to rotate back into individual contributor roles every other year (or director to manager, VP to director, etc). That way you remove all the people that are just there to collect money and build power structures that are detrimental to the company. This of course won't go over too well with managers. I've read accounts of Zappos managers physically crying because they are forced to give up their power for "Holacracy." Similarly I read accounts of Microsoft managers physically crying in the workplace when they were forced into IC roles during the recent restructuring. These are not the people you need in your organization. If they don't see the value in IC roles, then soon your organization won't have any good IC's and your corporation becomes irrelevant.

Not a bad idea, but it has some other issues that come with it. One being a lack of continuity on longer term projects; switching several managers midway through a project can have some pretty negative effects. The other might be with people feeling that there isn't much permanence in their job, or feeling that there is no real potential for promotion or career growth in the company if they're going to switch roles every so often.

On the first point, managers where I have been rotate around more frequently than a year. They reorg every six months or so. Secondly, if a team sized software project goes on more than a year, it is in jeopardy, so most team sized projects don't have more than a year of planning. Switching roles once per year should be the minimum.

On the second point, no real potential for career growth are precisely what drives good IC's out of the company. You feel managers shouldn't have to do IC roles because it's bad for their career? It's also then bad for IC careers. This is the typical manager viewpoint, they don't want to do IC work because it's beneath them and their only goal is to get promoted, get more power, and make more money but not make the company more successful. These are the money and power motivated people that you don't want.

Survivorship bias. The history of Google's non-attempt to replace managers is almost comically bad. They announced in an all-hands meeting that going forward, all engineers would report directly to Larry Page and all project managers (present at the meeting) were out of a job. In other words, Google thought that managers were effectively useless, fired them publicly in front of the whole company, and didn't try to replace them with any manner of alternative.[1]

Long story short, it's not difficult to "sell" managers when the alternative is anarchy.

I think managers are toxic in an engineering organization, and a disincentive toward expertise; Rational intelligent engineers would be foolish not to abandon their expertise for a more rewarding (financially, politically, effort-wise) management track. That said, I consider it even more foolish to have nothing in their place. Managers serve a variety of roles that will be filled, implicitly or explicitly in any tribe/organization. Further, they resolve the matter of hierarchy and eliminate political position jockeying (while exacerbating other forms of politics).

If you pay attention, you'll see that modern software organizations are straining on the verge of breaking with current management styles. No viable alternative has reached mainstream (except maybe holocracy), but in the coming decade, one will.

In my company, we're replacing the classic management hierarchy with something closer to a federated republic where the various roles of management are broken into separate roles for separate individuals, with the goal of placing engineers on top with multiple peer-based support roles. Something close to this will be the software organizational hierarchy of the future.

[1] http://www.slate.com/blogs/business_insider/2014/04/25/googl...

I'd really love to chat or if you have some topics I can research. My current company is currently moving to Scaled Agile Framework which displaces Engineering Managers from Tech Leads to a bit of a meta role along the lines of career/team coaches (but not quite Scrum Masters which is a separate role...).

If we can solve staffing and performance reviews in the framework then the role can likely go away.

No offense intended, but I'm curious in whether you think there is actual expressive value in using those terms? I'm actually about 85% sure that your comment isn't a parody of buzzwords.

Spotify has an interesting management structure of loosely-coupled "feature squads" and "guilds":

https://labs.spotify.com/2014/03/27/spotify-engineering-cult...

I wonder if these management classes Google implemented are online somewhere. It would be nice to be able to view them.

The rule of thumb for manager:report ratios that's considered the ideal (at least according to McKinsey) is 1:4-6.

...............#........Ratio

VP.............100......10

Director.......1000.....5

Manager........5000.....6.18

Other..........30900

That's basically what Google is sitting at. It isn't all that exceptional. Probably the main difference is that there's less sales title inflation vs. some other tech companies.

You can indent by one space to get a monospaced non-linebroken comment:

               #  Ratio
 VP          100  10
 Director   1000  5
 Manager    5000  6.18
 Other     30900

McKinsey, Schmikinsey. The military has known this for hundreds of years. 3 privates + a corporal is a section. 3 sections + an officer is a platoon. 3 platoons + a HQ is a company. 3 companies + HQ is a battalion. 3 battalions + HQ is a brigade. 3 brigades + HQ is a division. 3 divisions + HQ is a corps. 3 corps + HQ is an army.

> 3 privates + a corporal is a section.

Fire team. 3 of those plus a sergeant is a squad. 3 of those plus a more senior NCO is a section.

(And at most of those levels "3" is really more like a range between 2-5.)

Thanks, I was thinking as I wrote that, that seems very small for a platoon of Infantry, but it's about right for tanks.

Anyway, my point is that McKinsey are selling "knowledge" that they didn't create...

I am a manager, who also serves as a tech lead, for the record I'm at Microsoft.

My job has a number of facets. One is to help provide mentoring to junior engineers. I have seen entry level engineers who never had any mentoring at all, and they end up stagnating. I have seen, in some cases, the same engineer, moved onto a team with a strong technical lead who believes in a lot of 1 on 1 mentoring, and watched that engineer undergo dramatic growth.

I also know a number of engineers who never got that sort of technical mentoring, and I watched as their career stagnated.

So that is the first part of my job.

Another part is to provide technical direction. I have smart people working for me, problems tend to have more than a single good solution. Put these two facts together and there is, on occasion, some disagreement about how a problem should be solved. At that point I step in and make a decision so that something can be done. Design by consensus does not work. I have seen "democratic" teams spend over two months debating the merits of various solutions that both had about equal, but different, benefits and drawbacks.

At some point, someone just has to make a decision.

I also am responsible for things like enforcing a coding standard (yes it is arbitrary, but I have long term responsibility for the code), reminding developers to write their unit tests, and worrying about our branching structure.

Next up, I am here to be the voice of my team. I represent my team in meetings, presenting the technical aspects of our plan, coordinate our APIs with other teams, and provide technical input to other teams' discussions.

I work with UX, PM, Marketing, and upper management to ensure the product's overall success. When technology adoption decisions need to be made, I am the one going around campus meeting with other tech leads to understand what they have to offer. When external companies present respond to an RFP I am the one going over their proposal, emailing them back asking for additional benchmarks or to clarify their measurements.

And finally I am the one that shit rolls to. If my guys make a decision, I am the one that goes in front of management and takes responsibility. No one yells at my developers, no one talks down to them, no one hurls insults at them. If one of my engineers makes a mistake, I am the one who stands up in front of our GM, and the first thing out of my mouth is "it is my team, I take responsibility for this happening."

When things get to hot at a meeting, I'll get a text message requesting my presence. I tell each one of my employees, "I am the one who is getting paid money to be yelled[0] at, if someone is mad, you direct them to me."

I really don't understand how a manager with 50+ reports can manage all of this. The guidelines I've seen is that at more than 7 or 8 reports you just don't have time for anything but the most basic of career management advice help.

Managers are supposed to meet 1:1 with employees for an hour each week, any less than that and things start to feel sort of distant, I know from first hand experience when I don't meet with my manager for several weeks! Combine this with the technical and non-technical roles that managers have to fulfill, and I do not see how 50 DRs could ever work.

I have seen "democratic" teams spend over two months debating the merits of various solutions that both had about equal, but different, benefits and drawbacks.

Can't just these "democratic" teams solve these problems by a vote measure?

> Can't just these "democratic" teams solve these problems by a vote measure?

That'd be nice, but without some sort of formal decision making process, discussions end up going on forever.

Speaker of the House is a role that exists for a good reason.

I am a manager, who also serves as a tech lead, for the record I'm at Microsoft.

Ex-MSFTee and Google SDE here - At Microsoft my manager served both as a manager in a traditional sense, as well as a tech lead. At Google, my manager and tech lead (TL) have always been distinct roles filled by different people. My manager, though an experienced dev himself, leaves all the various aspects of daily technical leadership to his TLs and focuses on just people and project management. From a line management perspective, both my TL and I report to the same manager.

My experience is that this organization allows managers to manageably have a lot more DRs than my managers at MSFT could. Another benefit is that the TL role is a natural fit for people who do want to step into a clear role that allows them to increase their impact and leadership as senior engineers but are not interested in traditional people/career management work.

Are there multiple tech leads per one people manager? I can't imagine someone who can act as a tech lead for a team of 50 engineers and still manage to write code. I have a reservation with tech leads who stop writing code as in my experience they'll stagnate (the time frame is maybe 2,3 years).

A manager manages people mostly by process: a lot of things they look at can be quantified as metrics. So it's alright to have 50 reports (one hour on each a week seems reasonable). A tech lead needs to be able to get to details while still need to have an overview of everything. And then there is the need to keep up with the industry and that means a few hours of paper reading at least every week.

50 reports (one hour on each a week seems reasonable)

What else is that manager expected to do?

Are there multiple tech leads per one people manager?

Correct. My manager has 4 TLs reporting to him. My TL has a team of 7 not including himself, which is actually on the higher extreme. My previous TL had a team of 4 which is more typical. For career/HR-y management aspects I interact 1:1 with my manager for those, as does my TL. TLs will naturally offer career guidance/mentorship informally by virtue of technical seniority (where applicable) as well as feedback to managers and promo committees that will feed into conversations regarding the technical readiness for promotion for someone on their team.

I have a reservation with tech leads who stop writing code as in my experience they'll stagnate (the time frame is maybe 2,3 years).

TLs at Google stay quite technical (and mine certainly does) and write code as a routine matter of course.

How is the pay for manager vs tech lead? In my company managers get paid much better and have more levels to move up to whereas a tech lead typically has maxed out his potential for promotions.

> I also know a number of engineers who never got that sort of technical mentoring, and I watched as their career stagnated.

I think i am currently going on this direction. Assuming i don't have access to such thoughtful companies as yours (my country's sofware industry is underdeveloped), do you know how could i get that kind of technical mentoring needed for my career?

Do a project of your own. Pick some problem you see around you and solve it to the stage that you deliver the final product. It could be as simple (or complicated) as a website for people to play Sudoku (if that's your thing). You'll learn a lot about software: how to pick the right data structures, how do you persist said data structures, how do you set up user login, how do you draw a 9x9 grid in HTML, etc. There is a lot of details that you can only learn by doing. You'll also train yourself to think as an owner of a problem, rather than a drone who gets told what to do.

Technical wise, if you want to get deep into a sub field (deep learning seems to be the buzzword these days, no pun intended), then pick some open source projects in that domain and try to contribute to it.

There's codebuddies.org, which hosts free study sessions on Google Hangouts for a variety of programming topics.

Discussion from a while back, when it was last posted: https://news.ycombinator.com/item?id=6762222

i wish my current employer would adopt such ideas, i think we have more 'managers' then actual workers anymore.

What you guys need, first of all, is a meeting to decide to have a meeting to discuss this issue. If 2 meetings, aren't enough, be sure to schedule more, involving more and more people.

Then, you need to hire a "manager manager" - this would be a manager that manages the other managers. Put them in radically different time-zones, and make sure that they're from completely different cultures and back-grounds.

Require the devs to communicate to all managers, and make sure that the new manager is also not aligned on the actual goals with the other two, creating conflicting goals.

I'm exaggerating the situation at my company. Or am I?

no exaggeration.... ours is exactly the same. we are gonna need to schedule a meeting, to discuss the scheduling of the next meeting.

Has anyone "written the book" on this yet? It seems like a good article that with more explanation would be a great guide to management for those of us who never get to work at Google (or similar).

Google in 2013 had 37,000 employees and 100 VPs (as per this article).

Yahoo, in comparison, around the same timeframe had 16,000 employees and almost 300 VPs.

Guess which one has grown, and which one has stagnated?

Correlation / causation, etc.

Goldman Sachs is 1/3 VPs.

It's the same string of characters, but it's not the same position. I think tech VPs are more comparable.

Most VPs at Goldman don't manage any direct reports.

Certain functions in a bank (any bank) require sign-off from a person who is an officer of the bank. That is usually equivalent having the words "Vice President" in their title.

The result is that, to get anything done, a large fraction of the staff are VPs, and many VPs do not have any direct reports.

^managers_dont_matter, is not really the same as managers_cant_easily_do_harm, nor the same as managers > ^managers.

So Google is a relatively "Flatt" organization.

I hope it's managers get paid less than the skilled engineers. Engineering takes way more talent and skill than management does.

You've never managed engineers before have you.

Yes, it sounds like managing you would be a breeze /sarcasm

Good management takes a lot of skill, and if you happen to be in a position to contribute to the strategic and tactical vision of the company, even more so. I, for one, would love to have more input business level (working on it).

I wouldn't necessarily say that... A friend of mine is a project manager for a very large manufacturing company, and manages about 7x the number of projects that most of his peers manage with a higher success rate. I've worked with great management teams, and some horrible ones.

That work does provide value... though the salary variance between software developers from high to low is greater than managers... And I would say that few managers are worth as much as a good engineer.

Good managers are like bald eagles - few and far between. Incompetent, micro-managers who have no business being in that position and there because of "seniority" or because they're too incompetent to code - yes, 100% agree.

But there are good managers. I've been lucky enough to have them, yes.

"Good managers are like bald eagles - few and far between"

Hmm, I suppose that depends on where you live- where I am, there are literally hundreds of bald eagles that nest here annually. I see scads of them regularly and can easily find them during the nesting season whenever I want to do some bald eagle watching.

I've done both and you are wrong. Managing other skilled engineers mean you need to be skilled at both engineering and at managing people. I expect those on my team to come to me with either questions about career advancement or about how to solve an hard issue, if I can't help I've failed as a manager.

Reply on news.ycombinator.com