| > engineering and engineering management are two nearly orthogonal skillsets, but for some reason we insist on "promoting" people who are good at the former into positions that require the latter. 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. |