A lot of people whom I see in this category are people who fall more under the "engineer" banner than the "developer" banner - they tend to look for hard problems to solve, and are still happy solving logistical and financial problems.

This is an awesome article and resonates with me.

My schooling was Computer Engineering, my career started as a Software Engineer and has wound all the way up to Director level. I’ve been on both sides of this equation for a long time.

Your typical “just a manager” has to spin so many plates and babysit so many people that most real “engineer types” would loathe the job and frankly, not be very good at it. I struggled mightily as a team manager where there were a lot of competing priorities, personal issues, and directions that I needed to follow. As I got higher up the chain of command the job got easier, I had less direction I had to conform to, I was thinking architecturally and in longer terms– and I didn’t have daily interpersonal drama to deal with.

Management isn’t for everyone, engineer or not. It’s a lot like parenting: Most people are just making it up as they go, trying their best, and the best ones generally put others before themselves.

Put the idea that Engineers should be these lone wolf rockstars that just to get to do what they want, regardless of corporate objectives or market positioning is ludicrous.

As an engineer, I can confirm that we’re just as short sighted and dismissive of other people’s work as they are to us.

In my experience as a developer at a bunch of different companies, the worst managers have actually been the opposite -- they were ex-engineers who knew nothing about management and decided to become managers for the wrong reasons (small raise, more power, etc), and had no passion for management. The longer one's career, the more one comes to respect managers, I think, and understand what a skill it is unto itself. Many young engineers have times when they feel hostile towards management or even the idea of having a "boss" at all, but that just makes the situation worse. One needs to have a more collaborative attitude to succeed. Again, it's the ex-engineers who think managements is just "common sense" are the ones you need to steer clear of.

Maybe you don't see other things they do. Their work isn't only 1:1 with you. For instance, hiring, evaluating employees, redirecting team efforts if new priority arises, fostering collaboration with other teams if needed, unblocking things, reporting to high management about the team whereabout, making sure every IC has what they need for their job, taking the temperature of the team, informing people about opportunities, and so on...

The "if they wanted" part is key. It's hard to become extremely good at something unless you really enjoy doing it. I'd imagine that most people who are top engineers would rather be doing engineering than anything else. If you make them a manager, they're going to enjoy that less and not be as good at it -- but a lot of people get pressured into becoming managers nonetheless.

As someone who has moved from being an IC to being a manager, I can assure you that's not true. What we do think is that an engineer won't necessarily work on the right things. Engineers have a tendency to work on something until they've solved it, which isn't the same things as finishing it. This is why personal projects usually end up being unfinished and unpolished. Engineers also sometimes let the perfect become the enemy of the good. The oft-cited Malcolm in the Middle episode (http://www.youtube.com/watch?v=RHpJFROEOmg) illustrates this well.

As a manager, I don't see it as my job to keep my team busy or even productive...they do that on their own. I see it as my job to keep them focused, particularly on the tasks that will provide the most benefit for the business.

Exactly. So many engineers follow a default career progression into management, and then end up losing their edge from replacing an IDE with excel spreadsheets and powerpoint, and going from meeting to meeting all day.

This also results in folk being managers, who do not have the skill and character needed to manage people.

- Management is a skill, not a career path. - Gabe Newell

I don't think they're orthogonal skillsets. A major part of management (arguably the most important part) is helping your team improve their skills, which works much better if you're a skilled engineer yourself.

> I would basically worry about stunting my development as an engineer if I switched to focusing on management, and I'm not even convinced my role models for career development are really in primarily "managerial" roles (I'm thinking of both famously very good backend devs both at my company and at the big SV companies).

Yes, becoming a manager will stunt your growth as a developer.

> Separately, I have relatively little interest in being in a role where my output is judged as the output of a team of people who aren't me. I get that that's the best way to judge managers, and that managers do very valuable intangible things in unblocking their team, but I'm skeptical that I'd be able to feel satisfied by this.

You probably wouldn't enjoy managing then.

> I write all these things, because it really seems like a foregone conclusion of both this article and the industry as a whole that an engineer will eventually become a manager. Is that what I most likely have to look forward to in my career if I wind up working at the well-established/mature companies?

Definitely not. Most big companies have separate technical and management tracks, and most developers shouldn't go into management.

> Can someone explain to me why I should want to become good at management?

The major reasons to become a manager are: (1) you can have a much greater impact on the business as an Xth percentile manager than an Xth percentile engineer, or even an (X-20)th percentile manager; (2) you enjoy teaching and watching people grow; (3) you're more interested in causing good software to happen than you are in building it personally.

I'd say that's the real "just ignore the cycle of failure in the industry and keep writing the same stale think pieces" approach. We've had decades of talking about how vital good management is and how better training for management is a great idea, and to what avail?

> It's telling to me that rather than elevate the role you're more inclined to destroy it.

What it should tell you is that in my experience, steps in the direction of destroying the role have resulted in better outcomes, whereas steps in the direction of elevating the role haven't.

> I've described, with the most pessimistic lens, 2 layers of management to the top of your company, with a focus on team collaboration. Having managers with strong engineering experience and technical sympathy decreases the depth of your organization, it doesn't increase it.

I was thinking about technically-vertical rather than organizationally-vertical. Cases where the implementation of a single customer-facing feature - the response to a single customer request - is handled by components that are the responsibilities of several different teams with their own management. That's how you'd end up needing to coordinate roadmaps between different teams, and I see that as indicating poor structuring of responsibilities, usually a result of a team taking exclusive control of an area that should be shared, which is usually a management phenomenon. You want to be in a position where whichever team needs a piece of functionality for a given feature that's their responsibility can simply implement it, whichever layer of the technical stack it resides in - where the only responsibilities that could belong to other teams are product-feature level responsibilities, not technical-area responsibilities.

> But as an example of planning, imagine a platform team runs a flight of APIs. There are multiple clients to these APIs all shipping products. Each has their own feature needs. If those teams collaborate on dependencies and optimize around what they need, everyone gets what they need faster. Not coordinating or planning provides a random outcome in a space dominated by sub-optimal outcomes.

It's an appealing thought, but it just doesn't match my experience of how it works out in practice. The best outcome is often one that isn't imagined - is barely imaginable - until it emerges from the technical constraints (a la http://wiki.c2.com/?WhatIsAnAdvancer ). Letting API feature implementation happen just in time under the person who has a direct use case for that feature raises both the ceiling and the floor on the implementation quality: they're working under the best conditions for inspired insight to happen, and the fact that they're using the feature means their implementation will at least work and fulfil at least one use case, and then the second user of the feature can expand it to suit their use case while keeping the existing use case working (people say that you'll get stuck in a local optimum that fits the first use case but can't possibly be adapted to the second, but I just haven't seen that happen in practice; code that was written for a single use case inherently tends to be simple and malleable). The absolute worst case is that the API ends up with two parallel but different implementations of the same feature to fit two different use cases, which is non-ideal but not actually all that bad in the grand scheme of things.

Whereas planning and coordinating via management as I've seen it practiced just goes wrong too badly, too often. You agree on an approach that everyone who comes to actually use the API agrees is wrong, but no-one wants to revisit the decisionmaking process. Or one manager brings a particular API under their control to expand their own importance, and prioritizes their own needs - or worse, deprioritizes work on it because they're not actually using that API for anything important but won't allow others to improve it. Or it emerges that what was initially assumed to be a single common feature actually has use cases that are so different that they should be implemented separately, but any team that proposed to fork off their own variant would be assumed to be empire-building (or, equally and oppositely, would be given insufficient support in their work), so everyone keeps muddling through with an awkward compromise.

> This entire discussion is predicated on the notion that your managers are technical professionals facilitating this. It's weird how many people refuse to accept the idea that people can exist

I don't think good technical architects/technical planners exist - I've just never encountered anyone who was able to produce better results by making technical decisions ahead of time (across a wide variety of management styles and techniques) than leaving them to implementation. Even if they did exist, I haven't ever seen an organization that was able to systematically identify, recruit, or train that skillset, and I do think they've been trying quite hard in various ways.

> while in the same forum glorifying hybrid roles like startup CTOs in the same forum who are obligated to do a lot of management functions AND be the basis of a strong technical department

I don't think I've ever been one of those people, but for what it's worth: most startups fail, and that those that succeed often do so by doing things that don't scale; in any case a startup CTO is rarely doing all the activities you listed earlier. Often startups simply don't do conventional line management at all, which works until it suddenly doesn't. Often startups don't have multiple distinct technical teams, which makes the whole notion of coordinating roadmaps between them moot.

Good management isn't just people skills, it's the ability to judge the output of your team so that you can keep quality high. Non-technical managers can't judge quality, only measure the team's self-reported progress against external requests for which they serve as gatekeeper. Non-technical managers lack a sense of how long requests will take to fulfill, which results in either a) agile-style workflows where ICs need to have daily meetings to explain to non-technical management why tasks take as long as they do, instead of technically-competent managers being able to reason estimated for themselves, b) unrealistic deadlines where non-technical management presses ICs to do the impossible, which inevitably results in sacrifices to quality, or c) continually slipping deadlines and an inability to ship. Companies promote ICs to management because you can teach people skills to engineers, but you can't teach the love of engineering (continually honing your skillsets) to professional management.

> "tech leadership" (advising on engineering reviews, making technical decisions about how to best build things).

Otherwise known as a software architect, who spends his time diagramming up larger designs and communicating them to engineers, not writing code. Because of the inordinate amount of time needed to get people in your organization to align with your technical vision, as a software architect you will need many of those same "orthogonal" soft skills which management needs. If you want to spend your career being left alone to write code, then you don't want to be a software architect.

> I would basically worry about stunting my development as an engineer if I switched to focusing on management

Try to imagine the job of a head chef in a Michelin-starred restaurant. Would you say that his job is more managerial, or more culinary? Most people would say culinary, and few would assume that you could take somebody with a high school diploma, take a course in "Agile Kitchen Operations", and be qualified. Yet the job of a chef is very much more managerial. The chef spends little if any time chopping vegetables or stirring pots, instead the chef's job is to make sure that orders are moving smoothly through the kitchen and being made to the highest quality. That is a culinary profession, and engineering management is just the same, it is an engineering profession.

> I have relatively little interest in being in a role where my output is judged as the output of a team of people who aren't me. I get that that's the best way to judge managers, and that managers do very valuable intangible things in unblocking their team, but I'm skeptical that I'd be able to feel satisfied by this. If anything, it kind of feels random: at an equivalent level of my unblocking the team and being a good manager, if I have an amazing 10x engineer on my team then the output is just going to be higher than if I have an average engineer. So in less clear-cut cases, how can I tell if I just did a good job at unblocking or if my engineers are really good?

This is the fear of somebody who has served on a team with teammates who were incompetent (as have we all...), and not wishing to be in the position of their manager, who needs to live with the output of incompetent engineers. The reality is this: if you are a manager, and you think the people on your team are incompetent, and that no amount of mentorship or training will lead to the professional growth of said poor excuse for an engineer, then you should have the ability to fire them and replace them. The way that you can feel good about your output being determined by the people on your team, is either by handpicking them when you hire them, or putting enough of yourself and your experience into the individual members of your team that you start to see yourself in their output.

> I think I prefer empowering other engineers by leveraging knowledge and writing good platforms/tools/APIs rather than doing the organizational empowering thing)

Platforms, tools, and APIs don't do nearly as much as "organizational empowering" or "unblocking" does. For whatever engineering output metric you choose, giving engineers good management will do a much better job of improving those metrics than giving them Yet Another Tool. Good management is hard, Yet Another Tool is just another magic pill sold to executives as a way of shortcutting their way to engineering greatness. When have you ever seen that happen?

> I write all these things, because it really seems like a foregone conclusion of both this article and the industry as a whole that an engineer will eventually become a manager. Is that what I most likely have to look forward to in my career if I wind up working at the well-established/mature companies?

Just like there are different types of engineers, there are different types of managers. You don't have to be the kind of manager who's in back-to-back meetings and sees her team only for morning stand-ups and weekly planning meetings; you can instead decide to be the type of manager who's much more hands on. You can choose which type of manager you want to be.

> How does one keep learning their craft without direct experience?

Eventually you get to a point in your career where you understand that there's rarely anything truly new under the sun. If you understand the discipline well enough - you understand how things fit together, how much time things are supposed to take, what good code and design looks like, how to react when production blows up, how to keep it all secure, etc. - then you understand that you don't need to have deep experiential knowledge of whatever newest tool your team is using to solve business problems. You understand further, that if that lack of knowledge really does bother you, you can decide to be the kind of manager who dedicates some time to reading documentation and code instead of going to back-to-back meetings every day of the work week.

I think that's part of it, but the bigger reason is that the management talent pool is too small to meet the industry need. The same is true of engineers as well.

There's little apprenticeship, little mentorship, and little experience is gained seeing things done well. Capable people are being shoved aggressively and prematurely into decision-making roles (whether in management or engineering) before they've developed the skills and perspective necessary to do the job well. No question, talent scarcity makes for lucrative pay and easy mobility for the average tech professional. But quality suffers, nonetheless.

In my experience, where ever engineers are not realizing that, it is when management is not managing process and people. Both management of process and of people are visible - when manager is doing it, engineers and know. But, fairly often management is preoccupied much more by activities directly visible to their bosses and and much less with those that can improve internal functioning of the team.

> and knowing how to build software is not necessary but definitely useful - mainly for questioning your engineers when they tell you something that sounds crazy.

If you are supposed to manage process, you need to know what engineers, testers, analysts, customer support do on daily basis. You dont need to be star, but you need to know where they spend time and what their issues are. Otherwise your process wont solve issues that are occurring in your team. You will be solving imaginary issues some other teams have you read about on the internet.

And the above is greatly frustrating for everyone under you.

That's rare. In most companies managers aren't engineers, don't understand the craft and are picked by their buddies. They also have completely different incentives which allows them to throw engineers who spent ages to master the craft under the bus without any regards/regrets.

If that's true, then it's probably mutual. Engineers typically do not realize that their manager's role is to manage people and process (which is a bit of a specialization in itself), and knowing how to build software is not necessary but definitely useful - mainly for questioning your engineers when they tell you something that sounds crazy.

If any engineers are under the impression that their job is harder or more important than management, sales, etc, they're being arrogant.

Coming from a former strong engineer who started a company and now manages people more than code.

He was a nice guy but useless in that he could not relate with problems the engineers were experiencing and advocate time to fix them - kind of like a black hole for complaints. Engineers by themselves had virtually no say in what they actually worked on here.

This, coupled with a non-technical PM, meant we were constantly adding features on top of a weak foundation which created plenty of fires. And for each fire we were only given time to wave away the smoke rather than put out the fire.

So I'd agree having true empathy and being able to act on it is important for managers - they don't necessarily need to code but they still need enough technical experience to fully relate to what the engineers are doing.

This transition frequently leads to unrealistic demands regarding project timelines and deliveries. There's a prevalent lack of faith in engineers among these managers, primarily because they struggle to grasp the intricacies of the work engineers do.

That's why they often don't.

So which type of engineers do find it easy or desirable to move into management?