Engineering management is dying
deathrayresearch.tumblr.com
deathrayresearch.tumblr.com
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.
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?
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.
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...
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.
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.
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.
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.
If Valve is a poor example, what about WL Gore with their 9000 employees and $3 billion in annual revenue?
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."
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.
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.
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.
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.
http://technologizer.com/2010/08/18/the-tragic-death-of-prac...
After that I worked for a smaller software house I'd better not name, where I was responsible for 70 developers. I had no idea who was working on what because no one ever did what the status reports suggested. I resigned.
The frustration in both cases was that engineering management has been solved. It's been solved in the 80's. Any attempt these days to introduce principles I learnt from books like Wicked Problems, Righteous Solutions, Peopleware or Mythical Man Month got rejected, because most organisations these days have a chosen way of doing things that some manager thinks of as a personal fiefdom. Any attempt to stray from the defined approach is squashed, like, immediately.
"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.
somewhere in a parallel universe.
'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.
If you have 200-person projects and still call them projects, you're doing it wrong.
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.
it wasn't arguing that managers were not useful. it was saying they are decreasing in number.
For an example, Google has a supposedly "lightweight" system that, in practice, works quite poorly. A more traditional management structure, at a place like Google, would be an improvement. (I have no idea how Github and Valve work. Their structures might work extremely well.)
I think where Google screwed up is that it instituted a bicameral performance review system without understanding how to implement one. You can have a peer-review system or a manager-driven system. If you're doing things right, you have both and an OR-gate between them. People whose peers think they're doing great but whose managers don't recommend them can still advance, and vice versa. Conversely, to be demoted or fired, people have to fail both. The OR-gate system removes the career SPOFs that lead to degenerate behavior: managers can't exploit their position because people with strong peer support can still succeed at the company, and people don't avoid or shirk low-visibility but important projects
The problem with Google's system is that it has an AND-gate for promotions and an OR-game for demotions and firings, and that's a disaster. At Google, you need strong peer reviews (which largely comes down to visibility) to get promoted, but you also need to do well on a "calibration score" stack-ranking system (i.e. Jack Welch vomited, someone put a candle in it and called it a birthday cake) that is strictly manager-driven, extremely opaque, and often deeply unfair. (Google has historically had a problem of managers who abuse the calibration score opacity, giving low ratings to make it impossible for their reports to transfer.)
The downside of a manager-driven system is that managers can exploit the power, being career SPOFs. The downside of a peer review system is that people jockey for visibility and work that is important but not visible or "sexy" gets neglected. Google's AND-gate system delivers the negatives of both, but none of the advantages.
Google has some really great people, and in many ways, it's a really good company, but their abortion of a "Perf" (look, even the name is imbecilic) system is not one of their strong points.
I think one of Google's weaknesses is that there's an unspoken mentality that engineering is for smart people and everything else is for people who couldn't cut it. That might be why Google has excellent engineers but incompetent PMs and middle managers. If you think that engineering is what smart people do and PM work is for idiots, guess who ends up making product decisions?
Another of Google's weaknesses is that there are places where the engineering mentality doesn't apply, and Google doesn't seem to get that. Example 1: the Perf system has those nonsense calibration scores. They don't add anything; they just add another SPOF. It's data collection for the sake of data collection. But it turns out, in the real world, that data can be harmful. It can be used in ways that are really disgusting. (That's why Real Names is such an issue.) Google never got that. Example 2: the 3-word mission statements were a really bad idea. Same with downslotting. Engineers are supposed to fly with crazy ideas and give demos when things are still scrappy and rough. But in management, you really can't deploy an idea until you know whether it's good or not, because it's going to affect peoples' careers, and if you deploy a shitty idea it's hard to backtrack and take it all back. Downslotting never should have gotten through the door.
Google has some excellent engineers and many of them are people I'd love to work with again, but the place is losing its culture. Google+ and the executive attitude exhibited on Real Names established that.
I think one of Google's weaknesses is that there's an
unspoken mentality that engineering is for smart people
and everything else is for people who couldn't cut it.
That might be why Google has excellent engineers but
incompetent PMs and middle managers.
You spout theory. They work in practice. You were fired from Google within months of being hired, and continue to trash them in every single thread on even marginally related topics. They go from strength to strength, shipping extraordinarily complicated products like Google Drive and pushing the future with Google Glass and self-driving cars.
Start your own company and try your management strategies there. Until then, stop attacking a company and organization that is far greater than anything most people (including yourself) will ever build.
People management is necessary to mitigate the corrosive affects of the one or two bad people in the group. Valve's idea is to recruit only good people.
Communication problems don't require "bad people", though. Sometimes you have good people who just don't work well together, or who could be assets to the company but aren't communicating well. These things become common at scale. I actually find "performance" rhetoric to be insulting and imbecilic, so I think it's better to discuss impact... but if you have 100 good people, at least a couple are going to fall below an acceptable level of impact, even if they're capable people working hard and in good faith.
This is one of the problems with typical HR mediation practices. In most companies, HR is worthless. That comes from the implicit assumption that one party or the other is "bad people" and that they have to assign fault: if an employee gets a bad review, for example, they have to conclude either (a) that the manager gave an unfair review, making him look bad at this job, or (b) that the employee actually sucks. There's no alternative. This rarely works well, because unless there is a legal reason (e.g. a sexual harassment complication) that impels them to side with the employee, they'll side with the manager every time.
This is one of the biggest problems with performance reviews. They force the manager to take a definitive stance on each employee, and because to disagree with a review is openly to call that manager incompetent, people are afraid to do so even when, by rights, they should.
I get the strong impression from Valve's handbook that being a good person is defined as working well together. The idea that social incompetence is okay as long as a person can do good work may actually be harmful to company productivity, in their view. Of course, this could just be a conspiracy to put all the Aspergers out of work.
>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.
I think the challenge that most human organizations fail to overcome is how to prevent necessary conceptual and operational hierarchies from becoming a(n often counterproductive) social hierarchy. It's social hierarchy (and the abuses thereof) that make most companies such bad places to work.
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.
I'd like to push this further and claim that a manager in a company has two roles: one that fulfills the business needs of the company (keeping the machetes sharp), and the other to have vision and lead the people (climbing the tree). A good manager has to also be a good leader. The converse isn't always true, and I've seen many "good" managers (from a business sense) get resented by the people by the people they're supposed to manage.
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....
The larger issue though I think has to do with goals. It is one thing to be a 9000 employee business making things out of one kind of plastic (WL Gore) without management per se. It would be a very different thing to be a general IT development firm with 200 employees, fingers in 20 different markets and no management. People aren't coming together to do one thing. The field for problems is much increased.
The second point I would make is that of support.
The goal of a bossless organization is to have an organic organization where employees are well supported. The alternative is to have a command and control organization where employees are well ordered. Employee support is crucial.
Not to say there aren't problems. The primary ones that I have seen over and over in looking into this is:
1) How do you know if you need to hire? (We have an answer for this btw)
2) Keeping goals focused and the organization focused on the goals.
3) Ensuring quality and timely communication.
The third can be greatly assisted with technology, the other two need to be handled by real leadership.
Every organization has politics. The question is how you cultivate good vs bad politics.