
Engineering management is dying - ljw1001
http://deathrayresearch.tumblr.com/post/26759934886/engineering-management-is-dying
======
kabdib
My best managers couldn't do the engineering work I do. Likewise, I can't do
their work (I've tried management, it sucked for me, I won't try it again).

My current boss [and one of the best I've had, btw] puts it thusly: "You solve
problems with designs and lines of code. I solve problems by putting the right
people in the right places." It's an over-simplification of both sides, but it
contains a lot of the truth.

Trouble starts when managers (who should be doing people-level stuff) get
their mitts into technical stuff, especially when they start "laying down the
law" without proper background. That's when they grow pointy hair on their
heads, that's when the "send me weekly status report email" requests start,
these days it's usually when the "Agile" drums start beating, and it's when I
start looking for a new position.

------
CCs
In a software company with under 50 employees you can get away with almost
anything.

With over 50 employees the only model that ever worked is the one described by
<http://manager-tools.com/> :

\- Between 8 to 12 direct reports/manager, never more than 12.

\- Weekly 1-on-1 with EVERY direct report, never missed.

There's a way to flatten the structure somewhat with Team Leads managing up to
6 people: part development, part people management. Even then the Engineering
Manager has to be hands-on.

This is how people work and it will not change anytime soon. Everybody needs
weekly check-in with the company (represented by the manager) to stay in
course. And everybody needs to know "who's the boss", even it it's not an
official title or formal authority (think about Linus).

Citing Google as a good example is not too inspired. With all the billion $s
they can't come up with one more product - it's still a single trick pony.
There's Search/AdWords, everything else is pretty much failure in comparison.
Maps is somewhat profitable, but it was bought from somebody else and it's
pocket change next to Search. Everybody profits from Android, except Google.
And then there's Google+, Wave, Health, Video, Buzz, Catalog, Froogle, Orkut,
...

So before trying out a Google-style manager-less chaos, make sure you have a
couple billion $ in your bank account first.

And yes, when somebody is not calling the shots on who gets hired in his/her
team, that's not a manager. They get the task (deliver the results) without
getting the tools (pick your team). How that would ever work?

~~~
kscaldef

        This is how people work and it will not change anytime soon. Everybody needs weekly check-in with the company (represented by the manager) to stay in course.
    

I call bullshit. I have over a decade of experience in this industry and have
only had regular 1-on-1s with my managers over the last year. Despite this,
I've always been a highly valued contributor to the companies I've worked for.
If anything, the last year has been the worst / most-dysfunctional of my
career (although, this is probably not related to having 1-on-1s, but rather
unrelated organization chaos). I have always talked regularly (i.e. daily)
with my manager, but formal 1-on-1s were never part of the equation.

~~~
CCs
"We see each other every day" does not qualify.

1-on-1 is a very specific, regular and dedicated meeting. This is where you
check-in, coach, encourage new ideas, listen to pain points.

It's number 1 requirement even at Google:
[http://solutionfocusedchange.blogspot.com/2011/03/googles-
pr...](http://solutionfocusedchange.blogspot.com/2011/03/googles-project-
oxygen-eight-good.html)

I suggest listening a couple Manager-Tools.com podcasts about 1-on-1. You need
more than one person's experience, even if it's for a decade.

------
sgt101
I'm genuinely surprised that the word accountant or the world lawyer haven't
been mentioned in this discussion. From my perspective the issue isn't that
engineering management has issues, it's just that mostly the management that
is done is done by people with MBA's and law degrees rather than Ph.D's and
Engineering degrees.

The structures of modern companies arise from this - lawyers and accountants
have no interest in the groups they manage, because they see them as generic
interchangeable machines, rather than levers that they are developing to
create and make things. They seek to optimize them, rather than nurture them,
and then they seek to leave and do it again. A true engineer would want to
build something of value and then use it and use it again.

Most engineers opt out, the good fight is not fought, so - management is as it
is.

------
samd
Good riddance. There is nothing essential to the role managers fill that
couldn't be done by someone without authority over you. That doesn't
necessarily mean removing all managers, it just means not making them your
boss.

Valve is proof that a flat structure can not just work, but lead to massive
financial, critical, and popular success. It's also probably one of the only
companies that I would be fulfilled working at that wasn't my own. There's no
one to hold you back. I think the startup-minded hackers on this site can
relate to that.

~~~
Daniel_Newby
> There is nothing essential to the role managers fill that couldn't be done
> by someone without authority over you.

Bosses can break ties without anybody being too pissed off that their pet idea
lost the contest. Bosses can see the approaching ravine and order peolle to
build a bridge before the rest of the team gets there.

Valve is a poor example. Mr. Market only cares that their products are fun or
interesting. Valve products don't have to conform to MIL-STD-2341 section 243
subsection 12, and be validated according to ANSI 228.3.

~~~
codeonfire
Why is there a contest? If someone has an idea let them branch the code and
implement it. The company can then decide which of the two branches to use and
the developers will work harder to win. The real problem is this system is not
compatible with the jobs of non-engineering managers. What are they supposed
to do in a free market system where developers are making decisions? For their
jobs to be viable, an authoritarian system has to be set up. One developer has
to be told 'don't do that, we're going with Bob's way.' That's not an
environment for innovation. All this accomplishes is now a highly paid
developer has no reason to work hard at all, and they sure as hell don't give
a shit about Bob's stupid ideas.

As for bosses building a bridge, its ALWAYS going to be "why the hell didn't
you engineers know about or implement MIL-STD-2341" not "here's your MIL-
STD-2341 reference books and a few contacts for you to get started."

~~~
Daniel_Newby
> If someone has an idea let them branch the code and implement it.

 _Branch the code and implement it_? What if idea #1 is to add CRM and idea #2
is add interactive business scenario projection?

Many ideas are too big to implement just for the hell of it. And voting for it
is no good, because most of the voters have no idea what the hell they are
voting for. Somebody has to take responsibility for doing the deep analysis
and making the decision. That's called management.

------
Zenst
Engineering managment fall into 10 differnt types of managment. Those that
know binary and those that do not.

Sadly it is extremly rare to find a manager who cant do 1/10th of your job and
is actualy any good.

If you advanced up the ranks then you know what to expect, when to expect it
and how to deal with your staff, you learn how to deal with HR and the other
boring stuff. If you are a manager and have never done the job of the people
who you are managing then you know HR and the boring stuff realy well, but can
so easily fail to support your staff fully. It's not realy even a fine
balance, understanding what your staff do is extreemly important and at least
to some degree a manager should know how to at least do aspects of there
staffs job, to not know is a situation were you let your staff down or alows
them to abuse you by saying it will take longer than it actualy does take. You
then have those staff who are good at doing there work on email as apposed to
actualy doing the work.

So is Engineering managment dieing - has been for many years now but not for
the reasons you outlined. I suspect that during the late 80's some marketing
types migrated to IT managment and the rest is history.

------
blu3jack
I think there's something else interesting here in the relationship between
engineering managers and project managers. The author writes: "It's been
undone by a continuing erosion of responsibility accorded to managers."

We have introduced specialists of various sorts, with varying titles: project
manager, program manager, product manager, technical project manager. The
introduction of non-managerial technical-track engineering leadership roles
for those smart engineers who either can't or won't be good managers has
further splintered off the value-add of the engineering manager.

In between team leads and C-staff there are N levels of people who's job has
been highly eroded and who struggle hard to add value to their teams.

I am really interested to see where this is going.

~~~
codeonfire
I don't think those roles are diminishing the value of engineering managers,
although I think they are useless as engineering leaders. I think engineering
managers are diminishing the role of engineering managers.

Many, many engineering managers are the people who got into technology with
the goal of being a manager. As such, they did the minimum amount of actual
engineering they could get away with, say 1-2 years. They are motivated only
by the fact that engineering management is one of the highest paid professions
out there. Linkedin shows some extraordinary insight into this phenomenon as
anyone with a few connections can review thousands of resumes. There are
managers, directors, VPs, and CTOs who have almost zero actual experience in
the technical field they are supposed to be managing. For whatever extremely
messed up reason, the tech industry actually supports this.

So you get a whole industry of engineering managers who are not and never were
engineers. It's no surprise that their role is the same as a project manager.
That's all they can do. They can't steer the technical focus of the group,
lead the team towards innovative ideas, or anything that even requires basic
technical knowledge. If there's anything eroding the responsibilities of
engineering management its the constant dumbing down of the job by the non-
technical money chasers trying to get into the job.

------
sutro
Thanks, author, for the drip of your contribution to the ocean of everything-
has-to-die-for-linkbait.

[http://technologizer.com/2010/08/18/the-tragic-death-of-
prac...](http://technologizer.com/2010/08/18/the-tragic-death-of-practically-
everything/)

------
happywolf
Not sure how many people here have managed people before, or at least have
first hand experience in a company that has 1) too many managers, 2) too few
managers.

~~~
trimbo
How about the companies that have too many "managers" and not enough managers.
I've experienced that as well.

~~~
happywolf
I guess those are usually called 'stakeholders' instead of 'managers'. Yes,
they will try to assert their own little asses over you to show they are
somebody. Painful, but it is part of work life. [shrug]

------
big_data
The salient point is flatter organizations along with the feedback loops that
surround developers has changed the role an engineering manager plays. Drucker
was correct (as usual) about the knowledge worker's primacy in the modern
organization.

------
tysont
Besides working with engineers to define the technical direction of our
products, my job as an software development manager includes things like:
sourcing/hiring, long range planning (including owning P&L for my team),
customer engagement, and helping to grow the careers of my engineers (among a
million other things). I'm not really clear on how agile or outsourcing make
any of these things irrelevant. If the point of the article is that "non
technical engineering management is dying" then I think I mostly agree, but
the title is misleading.

------
ljw1001
Someone made an excellent point on the blog site that one of the key drivers
for a trend towards fewer engineering managers is that engineering management
is getting simpler with, in his words:

"the rapid the maturation of "infrastructure as code" tools and methodologies,
all the *aaS magic that's out in the world right now, the "App Store"
ecosystems, etc. With a small team, you can do seriously global-scale things.
"

You can get lot more done now with fewer people and less complexity, which
means less management needed.

------
ExpiredLink
> the widespread acceptance of Agile

somewhere in a parallel universe.

~~~
blu3jack
I think the author understands the depth of this acceptance of Agile when he
writes:

'Today they’re surrounded a vast army of scrum-masters and evangelists,
recycling (competently, mostly) the same insights, and an even larger crowd
performing half-assed renditions of steps learned by rote: “Yeah, we do agile.
We have a standup every day.” Many of these renditions have the
professionalism, but not the passion, of a small-town talent show.'

Which may be my favorite bit in the article.

------
webjunkie
"200-person projects headed by an Engineer"

If you have 200-person projects and still call them projects, you're doing it
wrong.

------
michaelochurch
I disagree that it's "dying". People management is important, and although bad
managers deserve all the scorn heaped upon them, we actually would do better
if there were _more_ managers.

The "flat" organizational model seems like a good thing, until you realize
that what it actually means is that there's a high managerial branching
factor-- sometimes 25 or higher-- which spreads managers way too thin. The
problem is that this is unstable. Any manager with 25 reports is not going to
be able to be fair. A subset of these reports (let's say 4-5) is going to win
the boss's favor. They become _de facto_ bosses off the other 20, but are also
direct competitors with them. Now you have all the disadvantages of a 5-tree
(instead of 25) but none of the advantages.

Most "flat" organizations aren't egalitarian-- just lazy when it comes to
figuring out a structure. Instead, they've traded official organizational
hierarchy for unofficial, unstable arrangements that are actually more
problematic. In a stable arrangement, your boss is your boss and you are not
his competition. In an unstable and informal environment, these "de facto"
bosses are also direct competition. That never works well.

People management is still necessary, and _good_ people management is
extremely valuable (and, sadly, somewhat rare in many organizations). At one
time, I thought otherwise, and that it was the engineers only who actually
mattered to the health of an organization, but I was wrong.

What has proven ineffective and wrong is the world in which people managers
were given _prima facie_ higher status, creating organizations in which the
only way to progress is to move into a management role. That proved not to
work, and it does seem to be on its way out.

~~~
einhverfr
First my business is looking at a flat model. We have a very specific approach
in mind.

> _The "flat" organizational model seems like a good thing, until you realize
> that what it actually means is that there's a high managerial branching
> factor-- sometimes 25 or higher-- which spreads managers way too thin._

In most cases the goal is to get rid of management altogether, and distribute
management _functions_ to the teams themselves. You are assuming a direct
command and control structure, a flat organization that works is something a
little different. I will talk about this below.

> _Most "flat" organizations aren't egalitarian-- just lazy when it comes to
> figuring out a structure._

100% correct there, but wrong when you say:

> _Instead, they've traded official organizational hierarchy for unofficial,
> unstable arrangements that are actually more problematic. In a stable
> arrangement, your boss is your boss and you are not his competition. In an
> unstable and informal environment, these "de facto" bosses are also direct
> competition. That never works well._

Again, this entirely suggests an idea of command and control rather than
something else.....

> _People management is still necessary, and good people management is
> extremely valuable (and, sadly, somewhat rare in many organizations). At one
> time, I thought otherwise, and that it was the engineers only who actually
> mattered to the health of an organization, but I was wrong._

The problem is though that managers inherently filter communication and this
leads to high costs as well. Again, if you want to make sure that specific
things get done with appropriate accountability then you want to have this
structure, but it isn't the only option.

You are probably wondering by now what the alternative is. The alternative is
to have a company based on openness, collaboration, communication,
collegiality, and entrepreneurship. This sort of culture is very hard to build
and maintain. It means that the executives have to cultivate a well-earned
reputation of listening to the folks on the job floor, mentoring them, and
only taking action when necessary.

We aren't talking egalitarian here. Rather leadership is distributed and
people can lead --- or follow --- based on their ability to convince other
people that given approaches are good for the company.

The way we run the LedgerSMB (<http://www.ledgersmb.org>) development
community is as follows:

1) There is a core committee of three of us, though one is pretty in-active
and may not last so much longer. we have the power to ban people, but mostly
we just help out folks, do development, and so forth. We are the primary
developers in addition to managing the community.

2) Everyone else can contribute but is expected to collaborate on their
contributions with the rest of the community. Then they can find a committer
to commit. Committers are expected to mentor non-committers.

I think this can work as a business management structure. You can have
executives who handle planning, organizational goals, etc. But they do this in
collaboration with others in the company in whatever position want to be
involved.

The big limiting factor though is this. If the executives can't get a well-
earned reputation for openness, the whole thing falls apart and you have to go
to a de facto or official command and control structure.

~~~
Spearchucker
Like michaelochurch, I think this is interesting and hope it works out. That
said, my immediate thought is "what does it take to become one of those core
committee members?"

Read into that what you will ;-)

The other part I think worth a cautionary mention is that you appear to use
the words management and leadership as though they are the same. They are not.
It's a cliché, but it describes the difference well -

If there's a team of people clearing a path through the jungle with machetes,
the manager's job is to make sure the machetes are sharp, the workers have
enough water, and generally that they keep clearing a path.

The _leader_ however, climbs a tree and looks around to make sure the jungle
is being cleared in the right place.

Lastly, you speak of accountability. And yet you do not mention authority. The
one cannot exist without the other. I've had accountability in every single
management role I've had and never the authority to run the team or project as
I saw fit. There's an imbalance there that has always spelt epic fail.

~~~
einhverfr
Well, in the community basically it is weighted towards early contributions
(duh) but typically it is people who countribute well to the project in all
levels. The core committee has never had more than six people in it, and
currently is down to three. There have been some political issues that have
come up with some nominees unfortunately so I won't say the process works
perfectly.

However those who contribute well tend to get commit privileges and those who
contribute to strategy beyond code have tended to become core members most of
the time.

Also regarding management and leadership.... Management is typically a command
and control structure for the leaders. If you have a flat model, leadership
becomes something different because you lack that command and control
structure, and so does management. Someone gets to make sure the machetes are
sharp. Maybe someone else is in charge of water....

But yeah good thoughts.

BTW, I don't think flat orgs work everywhere. The companies that seem to be
successful are those with a very narrow focus, like Github (building things
around Git) and WL Gore, which builds things out of one, very specialized,
form of plastic. Flat orgs scale up to any number of employees, but they don't
scale up to large numbers of goals. I can't imagine how you'd have a flat org
structure at Microsoft. Well I can, but it wouldn't be all that flat and it
certainly wouldn't be a single org....

