
How Google Sold Its Engineers on Management - ggonweb
https://hbr.org/2013/12/how-google-sold-its-engineers-on-management/ar/1
======
fishnchips
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.

~~~
Someone1234
"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.

~~~
yid
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.

~~~
magicalist
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.

~~~
yid
> 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.

------
codeonfire
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.

~~~
s73v3r
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.

~~~
codeonfire
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.

------
eldude
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...](http://www.slate.com/blogs/business_insider/2014/04/25/google_s_larry_page_the_co_founder_s_untold_story.html)

~~~
tkahnoski
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.

~~~
esrauch
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.

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

------
milesskorpen
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.

~~~
gaius
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.

~~~
dragonwriter
> 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.)

~~~
gaius
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...

------
com2kid
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.

~~~
gramerc
_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.

~~~
boomzilla
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.

~~~
gramerc
_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.

------
captn3m0
Discussion from a while back, when it was last posted:
[https://news.ycombinator.com/item?id=6762222](https://news.ycombinator.com/item?id=6762222)

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

~~~
PopsiclePete
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?

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

------
AliCollins
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).

------
mlmonkey
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?

~~~
kryptiskt
Goldman Sachs is 1/3 VPs.

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

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

------
alexweberk
So Google is a relatively "Flatt" organization.

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

~~~
PopsiclePete
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.

~~~
ensignavenger
"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.

