Hacker News new | comments | ask | show | jobs | submit login
A Plan to Turn Engineers into Managers (firstround.com)
388 points by prawn on Aug 4, 2015 | hide | past | web | favorite | 191 comments

"Don’t manage only to advance your career. Many tech companies have parallel career paths to seniority for both technical and managerial high-performers."

Is this really true?

Many engineers do become managers only to advance their careers.

The "parallel" technical career path never seems to deliver equal amounts of power, or even money, as compared to managers on the same level.

Even when a rough parity exists on paper, for every "principal Engineer" or whatever, there are a couple of dozen Vice Presidents of Blah. Oddswise, to make the same amount of money, and more importantly, to get more lucrative job offers in the future, in most companies it pays to transition to management than stay technical. (which is fine, it is just the way the world works, just pointing out that the article may need some fixing)

>The "parallel" technical career path never seems to deliver equal amounts of power, or even money, as compared to managers on the same level.

This is true. There's a self-deprecating joke about CIO being an acronym for "Career Is Over" because the Chief Information Officers are never promoted to CEO. On the other hand, it's common for the board to promote COOs and CFOs to CEOs.

If tech people want to be CEOs, they have to be an entrepreneur (e.g. Bill Gates, Larry Page, etc). Also, at small startup companies, CTOs (Chief Technology Officers) sometimes get promoted to CEO. (The CTO is often one of the founders or early employees.)

That said, if a tech person has no aspirations for C-level responsibility, the "parallel" career track for technical employees may offer enough progression and pay increases. They're ok with the ceiling being lower for the technical ladder.

CIOs are almost always* "keep the lights on" people. It's thankless work, and very frustrating, especially in corporations that don't value technology as a differentiator. In those cases, a lot of CIOs are promoted from within the Finance or Sales organizations, not any technical org, and they spend the vast majority of their time balancing restrictive budgets and managing attrition [of under-appreciated staff].

* There are plenty of highly appreciated, creative CIOs, but they're a minority ... which is why all the media aimed at CIOs & IT leaders (e.g. cio.com, etc) has spent the last couple years spreading doom & gloom about the profession, saying things like "the age of the CIO is over -- it's all about the CDO now" or "CMO budgets now exceed CIO spend", etc. It's also why the majority of CIOs these days don't sit on the board or are even in the CEO's inner circle, and instead report to either the COO or CFO.

If you're a CIO in a large company, your life is more about managing budgets than doing anything technical.

If you're a CIO at a large company your life is about leadership, or you will become a CIO at a small company really fast.

In my experience, some are leaders. Most are just managers.

I don't remember the last time I saw a company with a "CIO". It seems to be a dying trend.

Interesting fact: CIOs are also known as Chief Investment Officers (mainly in finance) and play an integral role to the company, perhaps in importance second only to the CEO.

At many finance shops, the CIO can even outrank the CEO, in reality if not on paper. For instance, during his glory days at PIMCO, Bill Gross was CIO while others, such as Mohammed el-Erian filled the CEO role, even when Gross was basically calling the shots.

In my 30 years of experience, the "parallel" technical track is really only for super stars. As merely a very good developer, management pays better.

And by "superstar", it's usually a person that can communicate his ideas eloquently and knows how to effectively evangelize and self-promote. It has not much to do with the actual technical competency. So, the skillset required to become a "technical superstar" resembles more of a skillset required for good manager or marketing persona than actual engineering skill set, though some level is required.

It's actually a different skillset than management.

A good manager is able to act as the interface between multiple teams, for example collecting requirements and resolving impedence mismatches. A developer who has advanced along the technical path does need some social and people management skills, but the role is very different. For example, they can mentor junior developers, or they can work with their managers to ensure that technical problems at said interface are spotted before they become problematic.

True, most of the superstars are "architects" who can both come up with excellent technical plans and then socialize/communicate them. I have a had a few "put on head phones and pump out 5 developers worth of excellent code" types as well.

I'm continuing to wander slowly but surely into more architecture roles, and while the term has fully justifiably been badly wrecked by people doing "architecture" who think it involves drawing diagrams with lots of boxes and lines and never checking the architecture against the requirements, there is a legitimate architecture role that does exist and there are legitimate skills that are specialized to that role. I'm not sure it's something that can be taught very well, though. But as one for instance, I could clearly explain to you how the architecture conforms to Conway's Law and exactly why it's shaped the way it is, and not some other way.

(Conway's Law is huge for a high-level architect... in a lot of ways you do not so much "create" the architecture as discover how to correctly translate the pre-existing corporate structures into code in the most business-efficient manner. "Architects" in this position who think they're working with a blank slate crash and burn, and probably are the source of the disdain for the term. A real architect is in fact working in some of the most constrained design space there is. In some ways that actually sorta kinda makes the job easier; you can sort through and dismiss a lot of bad choices very quickly with Conway's Law. The biggest challenge is when you get constrained down to zero choices for some problem and have to work Conway's Law in the other direction, and figure out how to fix the corresponding structural failures in the organization itself. It's a lot easier to change code than people structures, but sometimes you have no choice....)

You can't be a software architect without extensive experience as a software engineer first, at least 10 years, more like 20. At a previous job, you could go straight into architecture as a graduate on the "fast track". The architecture group at that company went on to produce many epic 500-page documents that no-one ever read, and one day they were all laid off... And no-one noticed.

> I'm not sure it's something that can be taught very well, though

Why ever not? You can study and discuss existing architectures, their advantages and disadvantages, discuss case studies of existing code and new requirements and what architecture to implement them in etc.

Of course, you also need some decent programming experience to come up with architectures that work in practice, but that can be also acquired.

This kind of architecture is akin to surgery, and there aren't enough cadavers available for practice. (Zombies, on the other hand, maybe.)

The Conway's Law factors are also harder to treat "fairly" in a theoretical sense relative to some of the real team-related difficulties that exist in any large enough organization.

Yes, I've worked with Architects and "architects". Only the first type actually benefit the company :-)

That's what I have observed as freelancer in a lot of companies. People who rise high on the technical track have to be exceptional (and often get let go to save money) whereas managers can be average and have more staying power.

My advice to anybody who wants to have a long career and make good money is to go into management.

this may be different for companies where there is more respect for engineers.

I have seen very similar things as a freelancer as well. It just seems like management is a much easier path when looking for longevity, money and work/life balance.

> As merely a very good developer, management pays better.

There are also more management positions. The parallel track technical positions are significantly more rare, even in the companies that have them.

There is a top to technical positions, the rest is management. You have to choose where you will be happy.

That "parallel" track also only exists at tech companies. For non-tech companies that have in-house software development, there is only the opaque ceiling above "senior developer". The only way past it is to jump over to the management ladder.

I'm a VP at a mid-sized ($100mm revenue) startup. I report to the CTO, and am his probable successor.

I make slightly less than our highest paid engineer.

I would recommend finding a company with a true parallel track, rather than dedicating yourself to a job that you don't want, and thus likely won't ever be great at.

An honest question: Does the highest paid engineer know that (s)he makes slightly more than you? If so, does (s)he know of it in an official capacity or has (s)he sort-of figured it out?

Oftentimes, I've found that management operates from a position of informational advantage, while a person on a parallel technical track at the same level has access to a lot less information. Hence the question.

Where I worked, there were a few senjor devs who got the biggest pay-checks.

Funny thing is, they weren't the most influencial people, they just got a problem and solved it.

If the times were though, they sometimes even were "set free" because they company could operate without them, just don't do much new stuff anymore.

They don't have any formal way of knowing my salary, and I don't know what they think I make.

I'd share the details of the managerial bands if they were considering a switch, but to date they've been very clear that they're happy staying technical.

Is there any meaningful sense in which a tech-tracker has more official or unofficial access to information?

Sorry, it's late here and my brain is just unable to parse your sentence. Are you asking if it matters if the information is gained officially or unofficially?

I'm asking if managerial information is a strict superset of engineer information. Control of admin passwords to software seems useless or illegal w.r.t. the concept of information here.

That's a really good question

Plot twist: the engineer is the CTO.

What industry is that? In companies I have seen it's a matter of principle that an engineer can't make as much money as managers. They would lay off the best engineer in the world before giving him as much money as they make.

It's the old class system, an engineer is "blue collar" (no matter where he want to school) and a manager is "white collar".

Of course engineers don't help themselves at all with all the open-source "software should be free" and feel-good "anyone can learn to code" stuff they come out with. If you won't put a cash value on your work, why would they?

I was the founding CTO of a company that did ~$100M in sales it's last year. My top engineers made more in salary than I did. And our top sales people out-earned the CEO and all his staff's take home pay by a quite a bit (except, occasionally the VP of Sales). Which the CEO had no problem with, whatsoever.

If it matters, it was a company that sold software primarily to large banks globally.

It's a b2b tech company. I've had at least one direct report who made more than me for my entire tenure.

How many VPs are there, and how many engineers at his pay grade? As in, if a junior engineer at your company is looking at their future, are there five times as many chances to become a VP as to become a highly paid tech superstar?

Advancing as an engineer is probably easier for the ambitious because there's not a fixed number of senior technical staff. If a technical contributor levels up their game, they can nearly immediately level up their pay.

The management track doesn't work that way; we need to level up our games, and then wait for an opportunity to arise due to corporate growth or turnover. For example, I'm getting coached to take over the CTO slot, but there's no reason to believe that I'll ever get the opportunity, because there's no reason to believe the existing CTO will ever give up their job.

It's an unfortunate truth of our society and business culture that we see these things as linear, hierarchical progressions rather than what they are, different roles with different purposes. Just like in the educational sphere we see High School < Bachelor < Master < PhD, there is a tendency to see technical < managerial from a leadership perspective and managerial < technical from a technical perspective. I wish we would move away from that stupid way of thinking. Devs are one role, PMs play another role, managers, directors, VPs ... they all should be serving distinct and different yet essentially equal roles, yet we see it as a competition and instill an artificial hierarchy. It's really only a symptom of a larger social value structure thing though, so it won't change any time soon or without a disruptive process in between the two states.

The challenge is that a lot of companies don't place engineers into the "critical skills" category, which leads to the [perceived by business & IT leadership] natural method of increasing an excellent engineer's sphere of influence being to promote them into management. Sometimes this works wonderfully, but it's obvious how spectacularly it can fail, too. If a company doesn't have engineering as a core competency, they're far more likely to fall into this trap than a company that does.

I'm speaking from experience here, having spent 15 years working for a company where promoting "technical managers" was a source of pride ... and 90% of the time the fallout of such promotions was that engineering quality degraded.

I have no idea if this is true, but just postulating a reason…

If you consider management to be a distinct skill,Someone with 10 years of experience engineering and also 10 years in management is (potentially) very skilled in two distinct fields. Imagine you have a lawyer with a PHD in geology and they work on ground water disputes or oil well stuff.

Being an expert in two fields is valuable.

I agree. In my experience (PhD in geology actually, and decent modeling/statistics/etc.-type programmer but not 'expert' by HN standards), this sort of dual expertise is quite valuable, especially at a higher level: Not only can you be a liaison between the two domains and, say, proficiently implement an idea or interpret scientific findings in terms of case law for your clients, but you can also see opportunities for solving one domain's problems with another domain's tools, when the problem domain may never even realize there's a good solution (or even much of a problem!).

In terms of management and engineering, dual experience or expertise could definitely help with understanding how to implement features in a way that encourages collaboration or efficiency between devs, or leaves a feature open for extensibility or interaction with potential features that the engineers aren't aware of yet.

You will lose a lot of your technical skills in 10 years time. Also most companies will force you to become more political and "reasonable". Thereby making it even harder to straddle both as the real engineers will smell the stench of your technical decay a mile away, and will rightly retch all over....

In Deloitte there are now "orange profiles" which are only technical and are earning more than functional figures. It is true though that at the best of my knowledge no "orange profile" has made it yet to a Board.

But why would they if they're optimizing for technical skills? It seems the two are mostly orthogonal, so this wouldn't be expected. Not many biz execs are superstar engineers.

FWIW, I know senior engineers that chose the technical route rather than manager route, who make absolutely ridiculous amounts of money. Like close to 1,000,000/year including equity. I don't know any non VP level people making anywhere close to that.

Obviously this is anecdotal though.

We know these people exist but it's whether or not they're common enough for your better than average tech to land and whether it requires actual technical knowledge or just good salesmanship.

I imagine it's a mixture of both, but that if I wasn't a contractor, I'd probably feel it's easier to get paid more by going tech -> team leader -> manager.

I've never heard it suggested that these best-of-the-best types of positions should be attainable by "your better than average tech." If your biggest asset is that you are "better than average" I think even hoping for a generic Senior Software Developer type of position is ambitious.

Not everyone can be the best of the best, a lot of us are sadly just a bit better than average and we matter too. The market encompasses more than just the elite.

That said, given cultural differences and our abilities to judge their own skill, it's entirely possible your best of the best is just my above average.

You'd be surprised how mediocre many of people at the top of companies are, technical track or not.

"including equity"

Pretend the equity is worth zero or close to zero (which it almost always is). How much are those people making then?

At a startup this is a good rule of thumb, but the more established a company is, the closer to cash equity becomes. At a publicly traded company, equity can be a periodic (albeit variable) cash bonus if you want it to be.

> Pretend the equity is worth zero or close to zero (which it almost always is)

In a startup or private company yet to IPO sure.

In an established, large, public company, RSUs, ESPP and whatever else you get is definitely going to deliver cash. Sure as the market moves around it'll change in value but you might look at it as +- 20% of the expected value. It's certainly not worth 0.

Equity is almost always worth close to zero? You realize at publicly traded companies, it might as well be a cash bonus because you can instantly cash it out the second it vests, right?

Where? Doing what?

Well known, top tier tech companies. I won't get into more than that they're senior engineers (partially because I don't know that I can answer that with more specificity). They all have 10+ years of experience and are typically tech leads on their teams.

Can you elaborate on the kinds of work they do? I can't see a senior engineer doing iOS/Android development making that kind of coin, but I can see it for someone who has been working in-depth building out datacenter technology or low-level mobile technology stacks, for example.

And I know of plenty of people who play football who make several million dollars a year. The question is, how common is it? In both athletics and engineering, the answer is not all that common.

The difference in football is that if you miss the cutoff for several million dollars a year, you make bupkis. In engineering, if you miss the cutoff for $1M/year (which itself is the low-risk alternative to "make a billion or nothing"), you'll make about $250K/year. And if you miss that, you make $200K/year. And if you miss that, $150K/year.

Engineering - at least at this point in history - is remarkable among professions where the very top of the pay scale is "the richest man in the world", but there's a relatively smooth progression below that where even a 25th percentile engineer makes a comfortable middle-class lifestyle.

This is as true as:

1) We value work life balance!

2) We only hire the best! Everyone here is a rock star.

3) We love diversity!

4) We have an open door policy. You can complain about anything!

> 1) We value work life balance!

I interviewed somewhere that specifically mentioned #1 in the job description. I applied in part because it was the only job ad I had seen to that point specifically mentioning it.

It was brought up again in the interview as a perk of the job, by the person who would be my boss, without my prompting. In the very next sentence he made a generalization about being confused as to why developers would not willingly work 45-50 hours a week as a rule and how "40-hour clock watchers" never lasted long at the company.

The cognitive dissonance was staggering.

I don't disagree with the guy on the "clock watchers" point but he should appreciate that in some cases people's circumstances push them to become "clock watchers". If they commit and produce excellent work during the time they are there then they should last.

Also, yeah, that doesn't make sense at all! It suggests they didn't a) read the job spec or b) believe in the company's values or c) perhaps the phrase was really "We value [when you] work [your] life [out of] balance" ;)

Wow. That person sounds like an entitled ass.

The best way to tell if some company actually gives a shit about the above is to ask them what they are doing about it.

I interviewed at a company once where the answer to #1 is "we do 4-day work weeks and make sure people are actually working 32-hour weeks instead of 40-hours-in-4-days". They seemed like they actually gave a shit.

Ditto diversity - companies love to talk a lot of smack about hiring women and racial minorities, but ask them about actual programs, policies, or structures in place to pursue this goal and... crickets.

But yeah, in most places the answer to "what are you doing about these things you allegedly value" is "absolutely nothing".

The best way is to look around and see who is rewarded financially. Just because a program is available doesn't mean it's not a trap.

Are the 40 hour workers getting promoted? Are people joining us from Google, Facebook, Dropbox, etc? Are there minorities in management?

It's probably true, but the thresholds to move up to the next level are vastly different.

On the "management" ladder, you probably need to mostly stay out of the way of your team and let them execute, while acting occasionally to filter information up/down the chain. If you've stayed in the position for a reasonable time and have not really screwed things up, you advance to the next level.

On the technical ladder, on the other hand, you'd really need to make quite a difference to move up to the next level. You'd have to go above and beyond doing your daily expected taken-for-granted work and make technical contributions on your own time to advance to the next level.

This may be true for the low levels of the management ladder, but it definitely won't take you to the point where you have 2-300 people under you and growing.

Very true. From a certain level on managers have to be extremely high performing. But in the lower ranks it's easier to advance as a manager than for technical people.

Until engineering decides to do something about it, engineering will always be subordinate to management.

There are no true parallel career paths.

Until engineering decides to do something about it, engineering will always be subordinate to management.

There are no true parallel career paths.

You nailed it. That is all. If we want respect, we have to fucking earn it by forcing businessmen to see us as equals, whatever the effort and cost.

What would "forcing" look like? Typically forcing someone to do something requires power - political, financial, or other.

When engineers have something that managers or investors desperately want (e.g. Zuckerberg et al), then engineers have power. When engineers are interchangeable code-monkeys, then managers and investors have power. Of course, engineers could band together in a labor union to increase their power, but managers and investors don't like that very much, and that generates a cat-herding problem.

I'm curious what exactly you have in mind.

Well, if nothing else works, a programmer's union.

I'd prefer something more like the Screen Actor's Guild, which provides support (legal assistance if you need it, access to talent agents) but doesn't regulate compensation. That said, I don't think things necessarily need to go that way, and I don't want to see the negatives of traditional labor unions. But that shouldn't be off the table. The other side isn't going to play nice, so neither should we.

FYI, SAG does set minimum compensation, working conditions, meal requirements, etc. It doesn't set upper bounds or demand that more senior people get the better jobs.

It's also somewhat difficult to get into. Any aspiring actor can't just go and join.

FYI, SAG does set minimum compensation, working conditions, meal requirements, etc. It doesn't set upper bounds or demand that more senior people get the better jobs.

Sounds like what we need in software: downside protection (especially against managerial misbehavior) but no limit on the upside, and no stupid seniority system.

It's also somewhat difficult to get into. Any aspiring actor can't just go and join.

How does it work?

I'm sure I'll get this wrong, but the way it was explained to me is that you need to appear in 3 SAG productions in order to apply for membership. Since it's a big hassle for the movie production to get an exemption to hire non-union, you need to be special in some way (the director really wants you in particular, you have some special skill like dance, etc.). It helps to know other actors who will call you and say "hey, they need a ballerina to be in the background tomorrow" or whatever.

I'm also not sure how you'd bootstrap something like this for programmers. The reason it works for actors is that every actor who is even slightly famous is a member, so every production has to work with the union or only get completely random people (you're still allowed to make an indie film with your friends if none of them are members).

I think the selectivity problem is less of one for programmers than screen actors. We can use code tests or Github for membership screening. Thus, we don't create the chicken-egg problem where (a) it's almost impossible to prove yourself if you're not part of the union while (b) you have to prove yourself before you can join.

Getting broad-based membership is much harder. This is an industry full of (a) young people who think they'll have investor contact in 6 months and be founders in two years and retired in six, and (b) indentured servants on H1-Bs. Even if we get 95% of the top 50% of programmers (and that's wildly optimistic) as members, most managers will just ignore their need for talent, in that case, and hire bottom-rung engineers, preferring that over being responsible for bringing in a union. It (that is, hiring bad engineers to avoid bringing in represented ones) won't work, but it won't hurt those managers' careers personally, so nothing will be done about it.

* Who writes the checks?

* Who writes their own check?

Those people hold the power.

The company where I work has the parallel career paths, but like you say, has a much higher proportion of managers at the higher levels.

In my view, money and advancement have to be part of the motivation for becoming a manager. Otherwise, it's too stressful and boring, and nobody would do it. My evidence is that every person who has joined management at the lowest rung, where the work is the most boring and unrewarding, has been somebody with a family to support.

> The "parallel" technical career path never seems to deliver equal amounts of power, or even money, as compared to managers on the same level.

The scope of a person focused solely on technology is narrower than the typical scope of senior management, and does not typically cover key functions like strategy (i.e. top-level decision-making) and sales (i.e. revenue generation).

I'm not saying that the latter are more valuable than the former but I will just point out that there are plenty of examples of companies with great technology that fail because of poor strategy or an inability to market their product/service as effectively as competitors who have crappy technology but better (or, at least, more effective) sales and marketing.

I think that managers also enjoy leverage from the people/teams/resources they manage - a kind of reflected-glory halo effect. The equivalent for a technologist (e.g. the creation of technology that makes others more productive) is not as obvious in most companies for various reasons (e.g. senior management lack of understanding of the impact technology has upon their company, non-technical managers' greater focus on self-promotion).

> Is this really true?

No. Even the poster boy companies have fancy titles and slight salary upgraded, but nothing that could be called a career path.

At one previous job, they tried the "technical career track" scam, but the most senior engineer still reported to the most junior manager.

The "parallel" technical career path never seems to deliver equal amounts of power, or even money, as compared to managers on the same level.

Very true. Engineering is the hard way up, because there's so much less of the title and grade and salary inflation on the management track. Take Google. If you're a manager and don't make Director in 5 years, you fucked something up. On the other hand, the Director-equivalent Principal Engineer rank is 3 jumps (all of them non-trivial to make) above Senior. When I was at Google (and this is probably no longer true) the number of Principal+ Engineers at Google NYC was... zero.

The cynic in me suspects that dual-track organizations actually serve management's goals by making it look rank-per-rank superior, just as the lopsided college admissions climate convinces middle-class public school kids that prep kids who get into Harvard are somehow impressive (because it is very hard to get into an Ivy from a middle-class background, but really easy for rich legacy kids). If you make it astronomically difficult to become a VP-equivalent engineer, then the VPs (who had a much easier climb) look more impressive. Far from providing a genuine alternative path to success, this process cements the tribal superiority of management.

Most telling is that when Google really wants someone and is competing with finance or Facebook and gives them a High-Compensation Plan (HCP), the person is put on the management ladder, even if that person intends and expects to be a full-time programmer. It's really hard to justify a $500,000 salary for an engineer but much easier if you give that person a managerial title. I'd imagine that Google isn't alone in this. It's probably a standard big-company thing.

Engineers (and, in finance, also quants and strats) also share some of the blame for the relative grade deflation, because we beat each other up relative to businessmen. They give each other consistently high marks and talk each other up. We're far too honest. And this "honesty" is something I've come to view negatively because what it really is, is ratting someone out to management, often cheaply or for free. My inclination, if they aren't hurting me or a project that I care about, is to protect underperformers, not because I like it when people underperform, but because information is power and I'm not going to share honest performance information on other people unless there is a legitimate reason to do so. (I care if someone is fucking up my project, or an existential threat to the company or my career. I don't care if he's costing someone else's company a salary while doing nothing; that's not an existential threat, so who cares?) But engineers have a storied history of being willing to tear each other down for cheap or even for free, and technology management has been exploiting our lack of tribal cohesion, in order to turn us against each other, for decades.

Pretty sure a lot of what you said about Google isn't true. I personally know at least one Principal Engineer who works on the Search team in Google NYC; it's possible he was promoted after you left, but even then, he would've been Senior Staff and highly regarded.

Also, upper management in Search is still on the engineering ladder. These are folks with 2000+ and 500+ folks reporting to them, one of whom reported directly to Larry when I left, with net worths probably in the hundreds of millions, and they've chosen to stay on the eng ladder.

I also know folks who were special hires (tech celebrities elsewhere in the industry, with independent press and a strong publication record) who were hired in as Senior SWE with a salary befitting their previous accomplishments.

There were Senior Staff SWEs at Google NYC when I was there. It's not surprising that there's a Principal SWE now.

You're talking about anecdotes with regard to those highly-compensated engineers. They exist, but I don't think that anyone entering Google at 2015 has any real chance of becoming one of those 9-figure engineers from a SWE-3 start.

Growth is everything in both tech and careers. I don't think someone coming in to Google as a SWE-3 in 2015 has a realistic chance of being a 9-figure Distinguished Engineer while rising through the company. I don't think a manager does either - Google will be dead before they can climb the hierarchy. I think someone coming into Google as a SWE-3 in 2015 who then quits after a year or two and either joins a fast-growing startup or founds their own has an excellent chance of being re-acquired in 5-10 years as a 8/9-figure VP.

I don't think a manager does either - Google will be dead before they can climb the hierarchy.

You think so? Why do you think Google will be dead in the next few years? I'd bet on it being around, in some form, even 50 years from now.

A halfway competent manager at Google will make Director in 5 years and VP in 10. That might be, in part, because Google has so few competent managers that a "5" or a "6" is a local 9.75. And (for as much as I trash Google) I think the odds are that Google will be around in 10 years.

All of that said, I'd imagine that there are plenty of VPs and Directors at Google who are not making 8- or 9-figure packages. You can get VP on seniority alone at Google, just by not making mistakes once you're on the management ladder, but the 8-figure RSU packages require a bit of luck.

I don't think Google will be dead in the next few years. I think it will be dead in about 15-20 (because that is the typical lifespan of a tech company - witness Sun, SGI, DEC, Apple if Steve Jobs had not returned, Compaq, Microsoft, and many others). I also think that the average manager at Google will never reach Director, and indeed a SWE3 has a better chance of making Distinguished Engineer than a manager does of making Director.

The reason I believe this is simple numbers. Assume a Director is responsible for a department of about 120; he has 5-6 direct reports (all managers), who average 2 managers and a handful of direct reports. In total, the department has 15 managers, one director, and about 100 ICs. In a steady-state company (one that is not growing, which I think will increasingly describe Google in the near future), the only way for an existing manager to get the director job is for the director to vacate it. When will that happen? The competition for the spots the director would want to move upwards into (VP positions) is just as tight, and they are often filled externally. The competition for the CEO spot is non-existent; there is about zero chance that Larry will step down during his lifetime. So every single manager has to wait for the Director to retire or leave the company, and even then, he has only 1/15 chance that he'll be the one selected.

Things were different when Google was doubling in size every year; when a company grows that fast, it's ready for a new level of management every 2-2.5 years, and instead of multiple people fighting for the same spot, everybody on the team could be made a manager and a new level of fresh recruits placed under them.

On the engineering ladder, at least, promotions are not zero-sum. You can get promoted for building a system that has high impact, without having to displace anyone on the org chart. The problem is that "high impact" is hard to define for promo committees, and so they often fall back on metrics they're familiar with like "number of people on the team" when assessing promo cases. But the number are not against you the way they are when climbing the management ladder.

I'm not sure you have demonstrated what you are trying to show.

If I understand correctly, you've calculated the chance a manager is promoted to director as 1/15 * average number of directors that leave over the relevant time period.

But you haven't made any argument about the chance an engineer is promoted to distinguished engineer besides stating promotion non rivalrous. A system in which no one is promoted to distinguished engineer is non rivalrous, for example.

The false assumption is that you need to have 100 people under you to be a Director. It's a title, not an organizational role.

Managers benefit from a seniority system at places like Google because you get automatic level bumps after so long. Sure, the ladder will get longer at the top (there will be VPs and SVPs and EVPs and SEVPs and CVPs) as they have to invent new levels up there, but the fact is that it's just much easier for you if you're a Google manager with guaranteed promotions for average performance, as opposed to an engineer who has to do something special to get Principal+.

You could be right, though. Google may have to do an honest layoff (as opposed to the dishonest stack-ranking/PIP bullshit which is a layoff masked as a "low-performer initiative") and, when that happens, a lot of managers are going to find themselves on severance packages. The ones who manage to hold on will still be getting the guaranteed title bump every 2-3 years, unlike engineers to whom no guarantee is made, but it won't be the same, and being a manager at Google won't be the cushy, write-your-own-performance-reviews job that it historically has been. The churn will free up positions, but the game will (as you noted) feel more zero-sum than it is when it's expansion that creates them.

The day I decided to make it a goal to switch from developing software to management: I was sitting at my desk at 8:00 at night fixing some bug and I looked across the sea of gray half-height cubicles at a someone 30 years older than me doing the same thing with the exact same job title, probably not making much more than I.

At 95% of companies, there is zero career development and advancement once you become a "Senior Software Engineer". Fix that and you'll see more engineers stay put (where they're likely happier and more productive).

True in my experience that managing developers paid better and had other perks like more equity and some control over priorities and projects that was nice. Technical or pure software companies seem to do a better job of valuing engineering talent and how core they are to business but still not as good as they could. The two things I've seen over and over are:

1) Pure technical people are under appreciated and in general under compensated in most organizations. Often management doesn't understand how important they are.

2) Good managers/management are under appreciated by most engineers. It is hard to measure quality in management and it is one of those jobs that when you're doing it best it appears like you're not doing much as you're avoiding bad projects/crisis in the background and putting your people forward to make sure they get their credit and are enabled to get their work done.

I'd like to see some more courses to help technical people be better at management as it isn't something you'll necessarily be good at just because you're really smart. I'd also like to see a technical 101 course for management types so they can better appreciate their true tech talent.

On a side note I thought Havard's article about management research at google and related hacker news comments were interesting. Most management philosophies I've seen weren't in the tech space and I'm not sure the production line and sales team techniques transfer over to software. https://news.ycombinator.com/item?id=6762222

> Good managers/management are under appreciated by most engineers. It is hard to measure quality in management and it is one of those jobs that when you're doing it best it appears like you're not doing much...

Oh, the irony!

Can we just agree that any job that require expert judgment of context-rich situations to take decisions - versus the raw application of fixed rules - is simply not suited to Taylorist evaluations???

Maybe developers valuate themselves too low more often than management, at least when it comes to negotiating salaries? In general they might think more in terms of what they need (or "should earn"), than what they could earn. That is kind of a mistake.

Certainly everyone has the responsibility to make sure that they like the deal they entered into and ask for more compensation when appropriate.

I think that good management realizes that things will end badly for them if they don't compensate employees well, but I for one though have never seen a corporate dashboard that tracked how fairly the developers are being paid. Management often seems genuinely surprised that they can't just replace the talented technical person who left and that they can't hire top talent for median wages.

This is a contributor to the 'gender gap' in pay.

The 8:00pm bug is why I had volunteered to transition into project management at my job. Actually, I kind of just took on the job informally. I balanced a ratio of coding/project management until I wasn't really coding anymore.

I'm not sure what entices a developer into pursuing management. As the above post pointed out, they didn't see a viable career path. I'm going to guess another reason is that many are fed up with how things are currently being done at their workplace, and they feel they can do a much better job than their current manager. This was my case.

Maybe the next statement is a little naive, but if you want to make things better, than just do it. Insert yourself wherever possible. Learn what you need to learn. If you end up hating it, at least you tried. It's a lot of effort to support yourself, but it can be well worth it. For me, I was able to introduce a Wagile workflow for our team, which had dramatic effects in just a month. I'm now actually starting to do product work as well as transition everyone into a full Agile approach.

I've been places where I was there for the 8:00 PM bug (or later). At most of those places, my manager/supervisor was still there, too, trying to help us figure it out. If nothing else, they were there for encouragement and food runs. (If your engineers are working through dinner, feed them.)

Doing management right doesn't mean that you no longer are there at 8 PM. It means that you're there at 8 PM more often than any one of the people under you.

Doing management right means your team does not have to work until 8pm every day.

True. But it doesn't mean that your team never has to work until 8 PM.

You are right about the salary. but what is your opinion on job security and employability. the way I see it, in a tech role, as long as your are flexible and open to learning whatever technology is thrown at you, you will always be employable. But in management,especially in junior management and especially in very large organisation, managers are in most cases dead weight. they don't do much.Don't they feel the insecurity?

Perceiving a manager—no matter how junior—as simply "dead weight" signals a failure in the organization, the individual manager, and/or your own perception. In addition to ensuring accountability, a good manager also helps to shield subordinates from the bureaucracy that is inevitable in large organizations. This work may not always be visible.

Bureaucracy inevitably leads to inefficiency.

If a primary purpose of managers is to "shield subordinates", then you have a much bigger problem within your organization.

But chaos is also inefficient. The best possible management minimizes both the chaos and the bureaucratic inefficiency, to get optimum output from their organization. This does not happen without management - the "natural state" of an organization is not as efficient as the optimal state.

Good process adds some latency, but reduces risk.

Definitely not as many available jobs. Every company in the Valley seems to be looking for engineers by the truckload, but there are not so many openings for [people|project|product] managers. Apparently, engineers now self-organize and products simply leap from their fingertips onto store shelves.

As for job security, I guess I'll find out eventually. My gut feeling is that in software companies, it's easier to get laid off/fired as a manager, and it's the opposite in companies where software/IT plays a peripheral or supporting role.

Yeah, this is my gut feeling too. Unspoken is the fact that productivity tools like Asana, Trello, Slack are innovations to replace management.

If you think you can replace managers with Trello, you clearly have had some very awful bosses in your career.

I don't need anyone to tell me to keep working on my TODO list. On the other hand, someone who grasp the big picture is useful to have around to tell me in what order to tackle the task in the TODO list. Its even better when said someone has the clout to go poke a 3rd party that is blocking me so I can keep working on the TODO list.

But the very best managers I have had are the ones that are willing to bite the bullet and say "No, X cannot go into the TODO list as it is now. Let's work together to define what realistic actionable items need to happen for X to be accomplished and then we can put those in the TODO list."

There are a few good managers. Everyone else is a boss. Boss's are detriment to an organization.

Managers manage. They don't wait until there's a fire and then start running around tossing the blame ball. Boss's do that.

I would say the type of manager you describe could be more aptly called a leader: visionary (motivating the team behind ideals), willing to do the hardest work (as opposed to handing it down apathetically), respectful (building trust and such) and more.

"Leader" is usually reserved for a different kind of work. A leader determines where the organization should go; a manager ensures that everyone under him is marching in that direction. They require very different skillsets - leading is an outward-facing, synthesizing, strategic role, while managing is an inwards-facing, empathizing, tactical role. To use Ben Horowitz's terminology [1], leaders are Ones and managers are Twos. The CEO's usually the most visible leader in the company, but you'll often find them at lower levels as well, like the tech lead trying out a new experimental Skunkworks project.

Both of them are distinct from "boss" as the grandparent describes it, which is usually what happens when you get a manager who lacks empathy, awareness, and flexibility. Both leader and manager are highly cognitively-complex, pro-active roles that require constant information-gathering. Boss is what happens when you get someone in that position who lacks the confidence or skillset to stay on top of all that information and then reacts through command & control techniques when things go wrong.

[1] http://www.bhorowitz.com/ones_and_twos

"a manager ensures that everyone under him is marching in that direction"

That sounds like a boss to me (and not just because you used an unnecessarily gender-specific word ;). One of the anecdotes in the article is about this person, as a manager, acting as a listening board and ultimately conduit for an engineer when discussing the importance of a specific project at Twitter, and raising questions that came from that engineer that ultimately resulted in the project being cancelled. I think that advocacy role is important management – where the manager advocates both up and down (and ultimately you can't "tell" people what to do, you can only fire them or convince them, so it's "advocacy" both directions).

Difference between a "manager" and "boss" is entirely in how they go about getting everyone on the same page. For any given strategic direction, there are a lot of different ways that could be achieved. A good manager takes in information from all her reports (including their preferences, fears, concerns, and goals) and then figures out a plan that keeps all of them happy while also achieving the strategic goals coming down from above. A bad manager takes the goal as the only input and then outputs commands to achieve it.

Totally agree. A good tech resource is hard to find. The guy who makes you go to a meeting once a week to tell you the floor plan is changing a little? Not so much!

So a good tech resource is harder to find than a bad manager? Hard to argue with that.

Ah, but the managers are usually the ones that decide who gets fired. If they fire you, you can be back on the job somewhere else in a few weeks. If they fire themselves, what other manager would hire a former manager who even implied that a manager was the least productive employee in the unit? That's crossing the thin green line, man!

Half of a manager's job is justifying the importance of management to the employees, and the other half is justifying their own importance to their superiors.

Let's put it this way. I have never been kept around long enough to see my own manager get fired. And I have been through 3 mergers.

> At 95% of companies, there is zero career development and advancement once you become a "Senior Software Engineer". Fix that and you'll see more engineers stay put (where they're likely happier and more productive).

In many companies I see more undermanagement than overmanagement, so starving out the management track doesn't sound like a great strategy. And if a company is going to have better career development and advancement, it's managers who will make that happen. The pithy answer is "why don't you become a manager so you can fix that?" – and maybe you don't want to and that's fine, but you should hope that some other enlightened person chooses differently.

Re: advancement: to have greater impact than a Senior Software Engineer you need to do more than hack or stay late to fix bugs. What we define as "management" might not be the best way to do that, but it's got to be something. And at a certain point impact based on individual skill is hard to scale. I don't think we have a very good model for what it means to be more than that, so there's something precarious about the upper levels of the technical track. I recall seeing an article describing the developer equivalent of "The Wolf" (the character from Pulp Fiction), and have encountered people in that position; it's kind of like a wildcat manager role, diving in to fix problems that are typically both technical and organizational. There might be other models of what it means to go beyond Senior, but I think they aren't as well understood as they should be. And a lot of them will look somewhat like management because a large component is doing work that makes other people more productive.

OP is not saying to starve out management. Providing a meaningful career track for experienced engineers as technical experts rather than managers does not require reducing the number of managers. It does, however, require accepting that there's such a thing as a non-management job that might actually pay more than one higher up the org chart.

Often, organizational and technical challenges are intertwined. We become susceptible to certain technical pitfalls because of the unique weaknesses of our organization and its technical leadership (or lack thereof). I concur that many senior engineer roles will look like management. One thing that distinguishes them is that the senior engineer is not involved in the minutiae of HR decisions that line managers make for their employees (salary & promotion, approving vacations, etc.) nor in the broader allocation of corporate resources that consumes so much manager time, but rather on high-level but still distinctly technical tasks.

In my industry (power engineering), it is very common to see giant engineering companies that have gutted the senior engineer role. They are made up of hordes of interns and junior engineers and lots of hotshot bosses and nothing in between. The quality of work they can produce suffers noticeably.

I guess my sense is that in some fields – software development specifically – the management track is generally starved. Sure people enter management, but they do so reluctantly (which itself causes many problems), or for the wrong reasons, and that's in part because there's not enough people interested in entering that track.

I think it's a case of different people having different priorities.

For example, I have zero interest in career advancement. I just want to draw a paycheck so I don't end up homeless and so I can afford to buy the occasional cool gadget. It'd be nice if my work was interesting so I'm not completely bored while I'm working for my paycheck, but advancement is definitely at the bottom of my list of what to look for in a job.

Worth noting is that it's not just about titles. Titles matter, but they can also become a joke. It's easy to imagine a company, realizing that its best seniors are underpaid, inventing a new title to justify paying them only 10% more instead of the 30% they should get.

The bigger problem is that most companies view "engineer" as "implementor of ideas that come from the business". Hence, all that Agile/Scrum bullshit in which engineers just churn tickets, rather than making meaningful technical decisions and building projects of increasing scope. No one who has any leverage and talent wants to work in that way. This becomes self-perpetuating, because even though there are good people who stick around (usually, with kids in expensive private schools, or uninsured sick relatives) the assumption becomes that good engineers leave after a certain point and, thus, that anyone left isn't any good.

For me, I only enjoy coding if it's part of a bigger whole, and if I am proving something in doing so. If I'm stuck in a ticket shop and can't leave for 2 years for some reason, I'm going to manage (preferably officially; unofficially via aggressive delegation if necessary) because I was done with that junior-level business-story coding several years ago. I graduated out of it long ago, and I won't be put back there like Billy Madison.

Totally agree with your second paragraph.

Good technical people at large companies (ran by non-Technical management) are often undervalued. I see over and over again how an engineering team gets a non-technical PO/Manager - who is just a very bad proxy. They can't bring any important insights into technical products and can't easily fix inter-team dependency. That's why all Google's APMs are technical (most with CS degrees).

This gets worse when top level management is not technical for a technical company. Since they are not technical, they don't have good vision about where the industry will go in 10 years and what are the limitations. Ex. Microsoft under Steve vs Satya. One only had a vision for next quarter and the other seems to think longer term (and knows where the technology is going).

> The bigger problem is that most companies view "engineer" as "implementor of ideas that come from the business".

Isn't that the inherent nature of a lot of the programming jobs, though? For example, I'm currently contracting at a e-commerce company. My day to day work is as you described - closing tickets that get assigned to me in the Sprint. I also suggest new tickets, but they're solely limited to technical issues (mostly addressing technical debt, trying out new technologies etc.).

Honestly, I wouldn't know how to suggest anything on the business side - I don't know a first thing about how the market we're in operates (except that it's very competitive), and we have a separate person (Product Manager) whose only job is to think of new features for our team to implement. I think that's the only arrangement that works for non-technical products, which is what vast majority of programmers work on.

I was thinking about the same sentence you highlighted, and I think you're right.

The problem is that it's often bundled with a similar but patently false and demonic idea---that the business and technical sides can be siloed without ill effect. They can't.

Someday someone will write a best-selling business book about how it's valuable for management to have technical expertise, and it'll have some catchy term like the "mangineer" or something.

Some of the better VC firms (eg. a16z, YCombinator) are already putting this in play with their investment decisions, but they would rather profit off it than write a best-selling book. There's a reason why the conventional wisdom in the Valley - at least among firms in the know - is that you need a technical founder who also thoroughly understands the business.

Then empower yourself by learning how the business/market works, or if that sounds stupid and boring, leave for someplace where it wouldn't be.

I'm not the OP, but the point I think is that as long as you are content to be a "code monkey" (no disrespect meant at all, but that's what it sounds like) that just does what they're told for 40-50 hours per week, you can't expect to have any upward career growth.

In this kind of setting there is no career growth though. You're either a 'code monkey' or someone like a technical product manager, or you manage people. They are all different paths, with none of them being inherently better or worse than others. Money-wise, a lot of code monkeys are contractors, which means that they take home as much or more than senior management.

Honestly, I'm not even sure how "upward career growth" could look in a company structured like that. I don't think I saw a single programmer in here who empowered himself with business domain knowledge to a degree where he could make meaningful contributions. I guess we're all comfortable with where we stand.

Engineers, speaking generally, are more than happy to work with the business.

Where there's divergence is that engineers don't want to work for the business as a subordinate, or for compensation that justifies working on something less interesting or career-beneficial than what one would prefer.

> The bigger problem is that most companies view "engineer" as "implementor of ideas that come from the business"

This is exactly what I tell people when they ask why I'm applying to business school instead of being a career software engineer. Engineers will almost always just be implementers of other people's strategy decisions -- and they will be largely fungible -- but the strategy decisions are where you can have a real lever effect on organizations as an individual.

I cannot tell if blog post is this a theory or 15-page commercial for one man's opinions. The title claims it turns engineers into remarkable managers, yet provides no evidence. I see a lot of bold claims (e.g. "As with any new job, the most important task you should be doing at any given time will definitely be uncomfortable. It should be") but this piece lacks the reflection and perspective of a PG think-piece or any sort of evidence to justify its numerous opinions.

A more accurate title: "Some guy has opinions on what managers should do so we typed those opinions up."

My other big objection is that the pieces of advice (e.g. "manage up") seem stock and not actionable. Merely telling one to "manage up," (i.e. make your boss happy) is a new phrase for something entirely obvious. Nobody would disagree with "Make your boss happy," but somehow you spin the phrase in a new way and make a new lexicon around it and you have a facade of content.

Didn't Steve McConnell (code complete) suggest that managing up should be a firing offence.

No mention of firing offenses... Perhaps you're misremembering Steve's description of project management mistakes, one of which is to "place politics over substance" [1], where the project manager tries to convince stakeholders that the project is progressing well, when the data says otherwise.

[1] "Classic Mistakes Enumerated" http://www.stevemcconnell.com/rdenum.htm

What? Why? That's insane.

Most overt and intentional "managing up" is a waste of time at best and often runs counter to the organization's goals.

By this, I mean when you decide on your drive into work "Today, I'm going to manage up" or block it on your calendar. I don't mean doing a naturally good job and keeping your boss informed of what's going on, figuring out how to best help the company achieve its goals, etc. That's the productive version, but it's 1% of the usage of that phrase IME.

Most of "managing up" ranges from pure politics to useless paperwork to ass-kissing.

What gets measured gets done. If higher levels of management measure politics and ass-kissing and useless paperwork then that's what goes down when "managing up." And of course there are plenty of organizations where that's a big chunk of what gets measured. People who value those things tend to strive for management positions.

There are some where it isn't. In those "managing up" can mean something else and management tracks can attract and keep people interested in creating that other meaning.

Ill have to reread my copy of rapid software devlopment but i think it was the toxic effect on the team.

His point was: be aware that to be a good manager you need to be effective in all three directions. From my experience, engineers stepping into the manager's role will primarily want to make their team happy and productive. But if that becomes all they concern themselves with, they will tend to land their team in the soup! Call it what you will, I think steering managers away from this is sound advice.

Interestingly, in my office's parlance, "manage down" is "make the boss happy (by making the team do what the boss wants)"...

Couple random pieces of advice:

1. Learn management, even if you're never going to use it. Everybody in this world has a manager. The more you know about the job, the better integrated you can be with others, either as a manager yourself or working with managers. That 3-way diagram? Holds true at the developer level as well.

2. Management ain't programming. When I learned to fly airplanes on instruments, the toughest thing was realizing that I had to rely on the gauges and fight my natural instincts. Likewise, if you've been a super-cool coder for many years, you're going to have to give up those coding and architecture instincts and learn people management ones. I see far too many extremely smart people try building and managing systems of people just as if they were computers. Wrong answer.

3. Ambition is fine. Being a jerk is not. If you like managing, you need to realize that it's always a gut check to make sure you're doing the right thing, and you very well may end up in a position where it is better to leave your current company and go play somewhere else than it is to continue. That sucks, but there's a difference between being a cog in a machine and being a professional. Be a professional or don't do it.

> Learn management, even if you're never going to use it.

Yeah. Those who don't do management will still have management done to them.

I've done the engineer -> manager transition successfully about two years ago. The biggest help for me (=somebody who likes to read) was the Hardard Business Review's 'Guide to X' series:


In particular (X=):

- Better Business Writing

- Coaching Employees

- Giving Effective Feedback

- Finance Basics for Managers

- Office Politics (parts of it)

But really, all of them are pretty good, at about ~150 pages each, I plan to read all of them just to be sure.

I knew a guy who did better business writing at Hardard!

This is a list of things a CEO wants managers to do and be like. IMO following these rules will keep you submissive and his castle nice and orderly. Not what you want if you have an ounce of ambition.

To actually survive and excel as a manager you need to play politics and win turf battles. Take on the highest value projects and ship. To get the good projects you'll need to fight because everyone wants them.

TLDR: Adding value to the company is how you get promoted as a manager, not by showcasing talent in a skill.

According to the Peter Principle [1], the entire concept of promotion is flawed in that people get promoted according to their performance in their current role, not the future role. Perhaps, it would generally be better if promotions would require a test run in the new role over a long time period (e.g. a year) before it is set in stone.

[1]: https://en.wikipedia.org/wiki/Peter_Principle

A lot of companies only promote individuals after they have been acting in a de facto capacity as the higher position.

Yes - and this is commonly misunderstood. The critical thing in getting a promotion is the ability to demonstrate the capabilities that will be required in the new position. This means actually being able to point at examples of you doing that successfully. This is really different from being brilliant at your current job.

I think you misunderstood the post your replied to. That poster was talking about employees that have been going above and beyond their current role and taking on many/most of the responsibilities that their "promoted to" role would entail. The promotion is just becomes a recognition of the increased capacity that they are currently taking on.

That’s still just one sample outside their expected competence. Ideally, you’ll want to test people over a long time period to take as many samples as possible.

Just because someone is promoted doesn't mean they can't be fired or demoted. What difference is their in your 1 year training period suggestion and simply promoting then firing or demoting in 1 year if things don't work out?

I personally prefer providing opportunities for a gradual increase in responsibilities over outright "here's your new job title and fresh office". Then once they've shown capability with the new roles they get the increased pay and job title. I guess that's the middle ground between the two possibilities you suggested.

Most companies don't demote at all. Even if an employee requests demotion (I have gone through this a few times, where a great technical staffer was promoted to supervisor or manager and then decided later that they really hated the change.), it was always a huge hassle trying to convince HR to accommodate it, and the employee in question had to write a personal letter requesting the demotion and explaining why.)

Does that seem unreasonable? I don't have any experience with such things, but it seems reasonable to me. The company decided you'd be most effective in position Y, so they put you there and gave you a pay/benefits raise, and now you're saying "I'd really like to do position X which is less optimal for the company even though you want me at Y and might/probably have already found someone to do X, and my reasons are A, B, and C".

A letter sounds like the perfect medium to communicate something like that.

Yes, it was the right way to handle it, but my impression when I went through it was that it was completely novel to the HR organization and they were reluctant to agree to demote anyone at all, whether they were requesting it or not.

It's a loss of face for HR and the company.

Admitting they made a bad mistake makes everyone unhappy.

"What difference is their in your 1 year training period suggestion and simply promoting then firing or demoting in 1 year if things don't work out?"

You don't have to pay them the higher pay for the year.

The problem being that people are going to have to perform both their current job AND their future job, for the same pay they have now.

How do playing politics and turf battles add value to the company?

SOMEONE will end up managing the team that adds value to the company. I think the point is to play the politics & turf battles so that YOU are that someone.

Exactly right. If you feel you're the highest EV manager with the best team then getting that hot project naturally maximises the value for the company. And being the best is useless if you're not perceived as the best, and that takes politics and turf wars.

This is very realpolitik ;) Note that you aren't proposing that you get ahead by bringing the most value to the company, you are saying it's important to be perceived as bringing the most value to the company.

Interesting, I think this idea should be explored more. Does anyone else think the "MBA Degree" market is rip for disruption? We've been seeing a huge flux of MBA graduates that gets hired for mainly their network or connection. This seems almost opposite to the whole meritocracy culture in the tech industry.

So given a manager/employee could do effectively what a MBA can do, why would a company hire a MBA degree instead?

Well I am an MBA(IT)[+ Mechanical Engg.], and right now I am managing some 15+ people engg team. I can very confidently say that being an MBA has helped me a lot. It gave me an insight in being a leader and made my job of managing a engineering team easy.

However I started my career as developer and have spent 7+ years in developing complex systems. The one difference I could always notice was leadership/initiative distinction between me and other developers and I used to think why these guys are not able to manage their time and guide their juniors. Simply they were not able to think beyond code(I am not generalising but the pattern I noticed with obvious exceptions).

Counterpoint: I'm not an MBA but I have a BA in history and a MEng in Industrial, and I spent the first 5 years of my career as a programmer before moving into management. I steadily moved up and am reporting to the CIO and managing 115+ folks. As my old boss said, you can learn the key skills of an MBA on your own, but you can't learn emotional intelligence or how to lead without practical experience.

I'm not saying your MBA hasn't helped you. I'm just saying it's not a magic bullet (unless a company requires an MBA to get in the door). For most situations, just having a basic understanding of accounting & finance is enough, and for the times it isn't, knowing how to organize and lead a large multidisciplinary project is. That part's tougher and all the theoretical knowledge & case study readings in the world will only get you so far.

Agreed. MBA just helped me a bit, but I guess most of my career is a result of coding & sitting with fellow programmers spending nights and learning vudu tricks.

MBAs can be particularly useful at extracting value from an existing product / solution, fielding complicated legal / accounting issues, ensuring communication within large companies has high (or at least respectable) signal-to-noise, executing M&A / partnerships, working with outside partners or services...

There are well-defined scenarios where an MBA has some value. Agree with you that managing developers is typically not one of these scenarios, but I don't believe b-schools typically frame MBA programs as a means to teach management of people but rather management of well-known business problems.

A good proportion of managers get promoted due to necessity rather than merit (as mentioned a the beginning of the OP). This issue is more conspicuous now that employees of fast-growing companies are more open about this issue and have time to blog about it (as growth has become somewhat more efficient).

Would love to see the space of engineering management get "disrupted" by high-quality, community-reviewed, and freely available publications. Might not 'kill MBAs' but will help people decide if they even need an MBA.

> MBAs can be particularly useful at extracting value from an existing product / solution, fielding complicated legal / accounting issues, ensuring communication within large companies has high (or at least respectable) signal-to-noise, executing M&A / partnerships, working with outside partners or services...

As can engineers. Aside from the presumption that MBAs want to and are hired to do this kind of stuff, and will put in 100% of their time doing it, there's no exceptional value that the MBA education in itself brings, IMHO. Most of this is stuff that a reasonably smart person would be expected to pick up on the job. The MBA does not learn enough finance/accountancy to do a CFO/accountant's job, nor does he learn enough to do a lawyer's job...

Things like YC and startups in general are already disrupting the MBA market. Far better use of time and money to just go start/operate a business.

What's wrong with hiring for network and connections? (If they actually do contribute to the bottom line of the company.)

They are finite. Hire for the ability to create valuable networks and connections, not for the few contacts that someone got in exceptional circumstances (like studying an MBA).

"Focus on enhancing strengths, not fixing weaknesses. “It’s a common trap for new managers to focus on fixing their engineer’s weaknesses than enhancing their strengths. The upside from improving someone's strength is typically greater and more likely to stick than the upside from addressing a weakness."

"Teach Yourself Management in Ten Years" haha

Management isn't that hard, specially compared to engineering where competition is fierce. The degrees are an absolute joke. I had virtually no social life during my CS studies, but the other one? Some of the managers I know don't even have one.

If you're the average HN reader you might have to hone up your soft skills and that's about it. Any competent developer would do just fine without training, even with autism going rampant in our industry.

It's not like we all jumped into the management career path in search for a challenge.

Just because something is a "soft skill" doesn't mean it's easy.

I suspect anybody that thinks effective management is easy would not do very well in that role. I've seen plenty of competent developers get chewed up and spit out as managers because they didn't understand what they needed to do to run successful teams.

For me, the whole idea of management in the software industry is to get out of the way to ensure engineers can do their job and and https://twitter.com/therealfitz/status/623526248338186240

FWIW, I don't believe that managers should shield engineers from what's going on up above. Instead, they should present the information in a manageable way, but also in a way that's honest. Political reality is too important to your reports' careers, so withholding it is kinda irresponsible.

No, managers should actually make the engineers' jobs easier. The manager should take things off their plates (or streamline with good processes) anything that they aren't specialized to do.

This picture is accurate, just someone should realize this shit on the top is not needed and not adding any value.

After being a consultant, engineer, manager and again starting as allinone on a small project, I believe organizational hierarchy is just an OK solution. If I put on a career planner hat, I find so many career paths which are in big hierarchies personally bad deals and would avoid them in future and advice the same to others. I wrote a summary of what I observed so many times. Sorry for a lengthy post.

When a software company becomes successful, it becomes a magnet for crazies. The crazies are the process-people who use fancy marketing lingo to tell you that you are doing something inadequate and you should be using a different methodology which is more correct for your company.

This takes the conversation away from “ideas” to “sudo-ideas”. The conversation shifts from what made the product amazing and what else we can do about it to a new conversation about how someone should do a certain job and fulfill its role. A new engineer with a good potential to produce software will have to go through a phase of self doubt surviving in this world and asking himself/herself if he/she is meeting the role and understanding what it means to meet the role. Now you need more people who are smarter than the engineer to tell him/her and hold him/her accountable and enforce certain improvements needed to fulfill this role.

This leads to a burdensome overhead which derails the whole organization from focusing on the core or the simplicity in its culture which enabled the business to succeed in the first place. This overhead and drama around it is what the smart helpless people call politics. Instead of a plan to solve a problem you can see people talking about a plan for a plan. Instead of a simple understanding between people, there will be a process to come up with more process. Someone writes a document about how to write documents because somehow that seems to be more rewarded. You got to be good at being the process abiding employee fulfilling the Role to play in this environment. An expert professional sees this system as something that is designed to keep you at the same level of influence no matter how much value you can produce and sees the leadership very un-inspiring.

There comes a point where if you are a productive engineer, it is more easy to build something and let the market forces decide if your invention is worth any merit. The bar in the market is not too high either. You build an app that lets you share your dick pictures, you get a billion dollar investment. Though it takes multiple engineer teams to produce useful software, it is possible to build a very useful feature or system that is missing from an ecosystem of a larger product or service. This micro service/product which generates revenue, Improves on the market feedback, succeed and itself might one day become a magnet for crazies. The feedback the market gives you is far more useful and actionable than the feedback you get in a large organization that is designed to to fit you to the role.

You got it right; you either conform to the role you're given or you get out and do something else. The role doesn't even have to be aligned with increasing revenue or increasing customer happiness, typically it's aligned with making your manager happy.

Paul Graham talked about this in an old essay; the fewer layers there are between hackers and users, the happier both of them will be. Dealing with organizational politics doesn't help either the hacker or the user.

I just joined an organization with minimal hierarchy (no team leads, no architects, no whatever) and minimal process. It feels right somehow, I'm curious how its going to work out.

In my experience poorly as it starts to scale above 5-10 developers on a team. Good developers tend to be opinionated people and after a certain size you need someone to break ties and keep everyone pointed in a useful direction. I'm a team lead/Developer manager and somewhat new to the job and that's my role. Help the team get the info they need, make difficult decisions about the direction of the tech, and help solve the really hard issues that they are bumping their heads against. Mostly stay out of their way if things are going well but still keep track of everything that's going down.

I took on a project management role in a "take one for the team" scenario, and it was a disaster. I believe I managed the project fairly well, but since I hadn't wanted the job in the first place I felt I had some leeway to do things my way, and the boss ended up resenting that I didn't "want" the job and didn't reflect that by working hard to get things done his way. I ended up leaving the company after four years of good reviews. Not a mistake I will repeat.

I've never understood this. At some point, you suddenly become great at managing people? No. You worked your way up by being good at what you do, coding. http://lizthedeveloper.com/how-to-reward-skilled-coders-with...

At some point you realize that your career is going to hit a dead end in most organizations.

That's the reality.

Software engineers, by and large, are under-compensated relative to value produced.

I'm sure everyone has their own opinions on all of this but, wow, that is an incredible resource.

You might want to check out the manager-tools podcasts as well, (different people, I believe,) if you haven't already:



Lol... who the fuck wants to manage instead of code? I guess if you're burning out and seriously paranoid you won't be worth a fuck as a coder, you have to go in the management direction.

But the joy of where things are headed -- and what technology is increasingly enabling -- is that we can finally get rid of managers.

"Every time you dissuade a great engineer from becoming a manager, an angel gets its wings." - Roy Rapoport

Related, a little opinioated as well and incredibly well drilled down: http://www.defmacro.org/2014/10/03/engman.html

They should just call it "Management Perspective Training"... even if you don't graduate to manager you're still given essential insight on how to help them do their jobs effectively.

Has anyone here had experience going the other way: management to technical?

Well, it seems to have worked well for AMD (Su) and GM (Barra) so far.

Long article but really a good one.

Very well written article

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact