A Plan to Turn Engineers into Managers
firstround.com
firstround.com
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)
Obviously this is anecdotal though.
Pretend the equity is worth zero or close to zero (which it almost always is). How much are those people making then?
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.
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.
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.
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.
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.
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.
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.
(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....)
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.
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.
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.
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.
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.
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.
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.
* 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.
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.
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.
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.
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.
If it matters, it was a company that sold software primarily to large banks globally.
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?
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.
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.
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).
No. Even the poster boy companies have fancy titles and slight salary upgraded, but nothing that could be called a career path.
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.
There are no true parallel career paths.
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.
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.
It's also somewhat difficult to get into. Any aspiring actor can't just go and join.
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?
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.
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.
* Who writes their own check?
Those people hold the power.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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" ;)
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".
Are the 40 hour workers getting promoted? Are people joining us from Google, Facebook, Dropbox, etc? Are there minorities in management?
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).
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.
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).
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.
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.
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.
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.
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.
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.
If a primary purpose of managers is to "shield subordinates", then you have a much bigger problem within your organization.
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.
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."
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.
Managers manage. They don't wait until there's a fire and then start running around tossing the blame ball. Boss's do that.
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.
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).
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
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.
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???
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.
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.
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.
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.
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.
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.
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.
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.
[1] "Classic Mistakes Enumerated" http://www.stevemcconnell.com/rdenum.htm
Interestingly, in my office's parlance, "manage down" is "make the boss happy (by making the team do what the boss wants)"...
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.
Yeah. Those who don't do management will still have management done to them.
https://hbr.org/store/landing/guides
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.
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.
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.
A letter sounds like the perfect medium to communicate something like that.
Admitting they made a bad mistake makes everyone unhappy.
You don't have to pay them the higher pay for the year.
So given a manager/employee could do effectively what a MBA can do, why would a company hire a MBA degree instead?
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).
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.
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.
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...
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.
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.
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.
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.
That's the reality.
Software engineers, by and large, are under-compensated relative to value produced.
:)
But the joy of where things are headed -- and what technology is increasingly enabling -- is that we can finally get rid of managers.