How to fail as a new engineering manager
blog.usejournal.com
blog.usejournal.com
The only caveat I'd add to that is that I can't keep on working on things in the critical path, at least as the sole developer picking up those tasks, because I'm hugely more likely to have things come up that prevent me from doing those things in a timely manner. That then leads to other people being blocked on my work.
The best balance I've found is for me to either pair with a developer who's able to remain focused on a task when I'm inevitably dragged away to do something else, or for me to pick up non-urgent tasks like refactoring, or developer tooling. The latter is probably my favourite as it means I'm applying my experience to tools and libraries that can then be used in widely applicable circumstances to make the rest of the team more productive.
1. As an EM you do sometimes have to resolve conflicts about code between senior members of the team(if it involves the team's tech lead) and it helps to not to have strayed too far.
2. It's much easier to drive new engineering initiatives if you are fluent at code and can quickly read and understand code documentation about a new library/way of doing things.
3. Sometimes while chasing deadlines, it helps if an EM can just sit with an individual contributor and do pair programming. Reminding developers about deadline won't motivate them as much as an EM sitting beside them and helping them out with coding.
4. EM jobs can be a bit hard to find, so being fluent at coding helps you to secure a job much easily since individual contributor jobs are far more prevalent than EM jobs.
I usually try to pick up a side learning project every couple of months to just have some fun and learn something new. After moving to an EM role, I missed coding a lot and had thoughts about moving back to being an IC since EM at my company was a lateral move. Though I chose to stick on since the amount of stuff that I could pick up at a given point of time was no longer limited by my own personal bandwidth.
I completely agree with your point about team members not having to dumb down complex concepts. Sometimes team members can come up with really novel solutions to problems which cost more time to implement on the short term but pays off in the longer term. Unless one is comfortable with the technical chops of a project, it's easy to dismiss ideas which aren't conventional.
I'm in a somewhat different field, but I had this experience a couple of times when I was younger-ish and didn't feel good about it. I don't think it raised my productivity
It may have been a good management move -- mitigating a high-stakes delivery risk by literally keeping an eye close, i.e. sitting next to me at my desk, but it felt more like panicky micromanagement (lasting for two or three days only, thankfully) than sharing the burden of an unplanned delivery.
(Unplanned delivery requests sometimes happen in my field. But what we do isn't as bottom-up as programming; it's more like a progressive GIF, iterative refinement from high level concept down to action plan, so unexpected intermediate deliveries can be good for the client.)
I personally do it in crunch situations for the following reasons: 1. Since there are more eyes on the code being written, mistakes made are an intersection of what either the driver or navigator would make. 2. It makes the developer less likely to procrastinate. I only use this as a last resort though and timebox it to an hour.
This. I've been in a management position for a few years now and was scrum master for a few before that. I try to grab a programming task every sprint, but I absolutely don't have the time to commit to large programming tasks that are critical to team goals.
I'll grab some easy tasks (stuff that takes <2 hours or so). Or, I'll pick up some analysis/prototyping work that isn't time sensitive. Or, I'll just help team members when they struggle with complex problems.
These days, I actually prefer mentoring or pair-programming with the junior developers. I have 4 of them on the team and making them more productive and independent is going to pay much larger dividends than trying to complete a complex task between meetings.
And oh, how I did get railroaded into endless eons of meetings, where no coding shall occur.
And oh, how I did get overruled by the scrum master, the moment I tried to deviate from the script of this iteration's sprint. Engineering manager, though I was.
And oh, how planning and retros taught us no lessons at all. How they were just working lunches at a hoteled desk via Skype. No desk. No one to look in the eye. No credible threat in hand.
No large, faceless corporation will ever get another hour of my time. Not even the time it would take to destroy them. For they do it to themselves by driving people like me away.
There’s a line where as a manager you’ll either do your engineering or management roles a disservice or not. Think of a napoleonic era army — You need to understand whether you are the sergeant who keeps the troops marching and fighting, the junior officer who passes orders on and keeps bullshit away from the sergeant, or the staff officer who makes sure the food and bullets show up, etc.
Not saying your way is bad, just difficult! Some mistakes I have been guilty of with your approach are:
If you do not delegate work well then you as a coding-manager can become a bottle neck. Sometimes work as a manager is unpredictable and breaks the flow of the coding part. Your coding work has to be passed to someone else (wasteful, as they need to get up to speed on it, context switch, etc) or others have to wait for you to finish the interruption manager-stuff and carry on with your technical work.
A manager like that can be tempted to make snap decisions (which may later turn out to be wrong or costly). Whereas a "dumb" manager can genuinely use the excuse that they have to consult with the team before making a technical decision. Of course you can always say you need to consult with the team, but it is really tempting to speed things up by short-circuiting the process and making decisions right away.
Not doing this makes you the restaurant owner on Gordan Ramsey's Kitchen nightmares. These restaurant owners are always confused whey their food sucks, why food is rotten in the fridge and why everything is failing. If you want to know why you shouldn't leave the 'process of developing software' -- just watch one show of Kitchen nightmares. Also, if you 'are too high up to code' -- change your title to: "project manager".
If you're saying we don't need managers anymore because that's what our CI/CD pipeline does, I agree!
I think a good manager has other responsibilities such as negotiating with other teams to enable their team's success. They don't need to understand the low-level details, but they should be able to comprehend complexity when explained, so even if I only produce '1' feature, they can be certain that my good job didn't produce '10' additional bugs to be discovered by the customers.
The place where I continued to actively participate was in architectural and system level planning discussions. In that capacity, it was to mostly ask questions, ensure focus on objectives, and very occasionally offer advice. It's mostly facilitation and mentorship.
Steve Jobs said it well: "The best managers, he says, are 'the great individual contributors' who don’t actually want to be managers but step up because they don’t see anyone else who can do the job better."
https://qz.com/work/1152331/watch-a-young-steve-jobs-give-ad...
Steve Jobs was a class-A asshole who people who are trained in leadership agree was a poor leader of humans, even if he had great success in business. I'm not sure I'd take his leadership musings without a few grains of salt.
edit: everyone -> people who are trained in leadership
Everyone agrees?
Because I'm not sure I do. Jobs was probably an "asshole" for whatever your definition of that is. To suggest that he wasn't a capable leader of people is a rather different thing.
His leadership style was authoritative, petty, and probably even mean. It was also extremely effective. It's a style that was hardly unique to Jobs, and I can point to many other effective leaders (especially in the military) who used a similar style to achieve fantastic results. From Patton to Vince Lombardi the evidence is everywhere. Hell today we see much of the same behavior at SpaceX!
I would argue that an authoritative style of leadership, with small doses of intentional praise, can be really effective under certain circumstances. Particularly when the goal is very big, very audacious, and very hard.
There are lots of ways to lead people. Which one is most effective depends on many factors.
1. You have no power. You really don't have the freedom to change salaries, you don't have final say on promotions, you often don't have final say on work commitments, often a lot of work needs to be done that simply isn't exciting. It's a killer to have a development plan for someone that's totally un-acheivable because that's simply not what your team does.
2. You are the shit shield for your team. Especially working in a remote site decisions will be made that totally screw your team and you're responsible to deal with that. Whether it be other teams breaking fundamental dependencies, or senior management forgetting why your team exists and deciding it can be cut, re-assigned, re-prioritized. Often being the person who gets the brunt of that is incredibly difficult to deal with.
3. Your job is now 100% political. Whether it's the expectations your team puts on you to deliver them pay rises at the end of the year, or your product manager putting expectations on you to deliver releases at certain times a lot of what you're doing is politics. Especially in large organisations there'll be projects that are going to fail, and learning how to protect your team from the fallout is essential. It's a shit part of the job but in large organisations it's essential.
By any chance do you work at Amazon? Or is that just common everywhere?
I am honestly not sure why team members don't understand this. Of course, now and then you hear about that heavenly happy place where this is not true. But true more often than not.
I think this point needs to be expanded a bit as to why. Salaries are determined mostly by budget, history, market, and skill fit.
1. If the budget isn't there, nothing a manager can do. The manager is not in charge of raising financing for the company, and budgets are hard-fought things where managers often can't get everything they want. A manager can't wave a magic wand and make money appear out of thin air. If someone is leaving for a better offer, the manager gets more ammunition to ask for a better salary for that person or for the team, but that's it. They have very little ammunition of their own.
2. A manager has to consider the historical wages of what current team members make. If everyone is underpaid, well, SOL. There are reasons for that, whether budget (see above), culture, whatever. If you need to suddenly overpay one person, you need to figure out how to make everyone else happy. It may not be possible, and it may unfortunately just be easier to let the superstar go. Unfortunately, not everyone is Netflix.
edit 2.b. OK, we talked about this during your annual review last year. I'd love to give you a raise. We need more people who are at the skill level where the company is paying that money. Remember what we discussed? How are those personal growth goals going? Remember Fred who got his raise last year? Remember how we talked about his code quality, his people skills during meetings, his efficiency, his list of cool accomplishments? Remember how I want you to do those things? Talk with me when you've achieved the personal growth goals we discussed. I'd love to give you that raise. I need people at that level, and I'm authorized to give it to you if you are right there at Fred's level. But I can't give it to you if you haven't grown to that level yet. Help me help you.
3. The market may actually not agree with you regarding your market worth. Just because Netflix pays their 10x guys so much money, it doesn't mean you're worth a 10x guy. This one is just certain people being delusional. What is a manager supposed to do? He wants you because you're a great 1x guy, maybe even a 2x guy. But there's no way he's going to pay you the 10x rate, because he knows the market can give him another good 1x or 2x guy at a 1x or 2x price.
4. Your in-demand skills may just unfortunately not match what the company needs. You're overqualified. Go work for Netflix, why are you staying at this crap place where you will never get what you're worth? Go get paid, just not here. We can't afford you. Or stay here, but then please don't complain about the money. I'll try to do what I can to make it worth it for you, got any ideas for me?
Business folks: please create parallel technical and managerial career paths. This can go all the way to the CEO (CTO) level - great devs can be great devs, great people/business folks can be great at managing.
I see it daily:if your manager is programming, he’s not managing. Of course there are exceptions, but as a rule, if you’re a senior dev, you’ve probably been focusing your attention on tech and not people for a long time. There’s a crazy amount of nuance, self awareness, humility, patience (!!!), empathy, and conscientiousness needed to be great at managing.
Underperforming manager -> underperforming devs
HR management should be taken seriously as an engineering (as much as software is currently) discipline and not just an afterthought for devs to pick up.
Management does not have to be an “active” job.
Great managers find out what obstacles are standing in the way of their team members, then figure out how to remove those obstacles. How much time this takes greatly depends on the company.
IMO a senior dev is different than a manager. Senior devs mentor junior devs; that is where their team productivity multiplier comes from.
Finding out obstacles and removing them is an active job.
But also, the saying about merely "removing obstacles" is not really correct. I am not even sure it is so in the happy flow where every employee is super great and full of initiative and is at exactly the right position. Managers are expected to coordinate, set priorities, negotiate about deadlines and scope of project, plan and re-plan, explain why we are going to be late, handle communication outside of team, clean up tracker, make sure testers are available, collect reports about who worked on what.
If all manager is focusing on is "finding out obstacles and removing them", you all have high chance of ending up in long term crunch and chaos.
You are describing a Project Manager. It’s a different role than a department manager.
Much of that can and maybe should be done reactively. Set priorities when your employees need them. Negotiate deadlines and scope when they're needed for a decision. Communicate when it's needed. Etc.
You may not be literally twiddling your thumbs - I'm sure there's always something to be improved even in the quietest periods - but IMO the most important part of the manager role is to be available to resolve issues that do come up, and I'd take a manager who can do that well over one who's great at planning but can't react. As a technical analogy it's more like sysadmin/ops than development.
Same with priorities. Those are not just for employees, but also for people outside the team. When you are asked about priorities and future, it is best to have reasonable answer at that time - not two weeks later when you finally reactively done reading and thinking.
Employees often dont really ask about priorities. They assume priorities based on their previous experience/opinions, everyone different which leads to misunderstandings and waste of time. You have to sync them before they ask.
If the primary role of manager is to constantly react at suddenly appearing problems, then the company needs more planning and more organization. Those suddenly appearing problems are consequence of chaotic environment. Good manager reorganize so that they don't appear anymore or looks for them before they grow big and sudden.
Incoming requirements aren't actually continuous; indeed in practice they tend to be quite bursty. When you get a new batch of requirements is the best time to evaluate their priorities and schedules.
> When you are asked about priorities and future, it is best to have reasonable answer at that time - not two weeks later when you finally reactively done reading and thinking.
Two weeks later the priorities will likely be different. Long-term planning is usually wasted effort.
> Employees often dont really ask about priorities. They assume priorities based on their previous experience/opinions, everyone different which leads to misunderstandings and waste of time. You have to sync them before they ask.
If employees don't know where to look for priority information that's a problem to be fixed.
> If the primary role of manager is to constantly react at suddenly appearing problems, then the company needs more planning and more organization. Those suddenly appearing problems are consequence of chaotic environment.
The world is chaotic. Reacting to change is often cheaper and more effective than planning and organisation.
2.) If your priorities are changing every two weeks, then you have no priorities. This is literally what management is supposed to avoid.
3.) The point was that employes are not aware they have priorities wrong. They are not asking, because they all assume they know what to do. Again, which is why you are supposed to clarify it proactively.
4.) If you have same sudden problem fifteenth time, then it is not change. If all of your projects end in crunch surprisingly and none of your plans work, you are doing it wrong.
Nonsense. Two weeks is - or should be - plenty of time to make a useful improvement to your product.
> The point was that employes are not aware they have priorities wrong. They are not asking, because they all assume they know what to do.
So fix that problem. Make sure they know when they should be asking about priorities. Don't just saturate them with priority information, that will annoy the ones who knew when to ask, and the ones who think they know won't pay attention anyway.
> If you have same sudden problem fifteenth time, then it is not change. If all of your projects end in crunch surprisingly and none of your plans work, you are doing it wrong.
If most of your plans succeed, you are not taking the risks that you need to make the big wins.
But I mean, I think I can manage managers, aggressive personalities who have a clearer, shallower career goal. It's easier than managing technical folks' squishier egos.
Am I doomed?
You're probably wrong in thinking that. But, you aren't doomed either. The skills needed to manage can be learned and practiced, just like any others. Sure, some people are "born" managers and others will never be good at it, but most competent, well-rounded individuals can probably do at least team-level management.
Does your employer have any management training/mentoring programs? If so, take advantage of them. Some of them might feel pretty "squishy" to a technical person, but that's part of managing people.
I'm changing my original question. I think I have a lot to contribute in a strategic advisor role and I would gladly switch away from a technical career track if I could do it. Analogy: it's the business equivalent of if I had plenty of experience consulting in software architecture but couldn't program because I can't type/match keys to onscreen letters. I think I'd be a great "business architect" and enjoy that work more than my technical work.
But despite having quite some experience in an "architecture" role (something my team lead even encourages), for all visible purposes I'm a "rockstar technical person" type who's awesome at solving problems. My role in pointing out higher-order (market|operations|product) architectural/strategic stuff is much more understated, it comes as a corollary. I'm glad to have the "architectural" influence I have with my team lead, but would love to make it a main career, be able to change orgs and retain this role, etc.
Within my current org, I know a few people who have transitioned from technical roles into product management roles, usually mid- or late-career. But, we have a dedicated PM group, so it's just a matter of chatting with them and waiting for a position to open that's a match.
A good line manager will shield his folks from project-management bullshit mind-games. Giving PMP's direct access to your people is a recipe for stressing out everyone involved. Unfortunately, that is becoming more and more normal these days as the manager-to-contributor ratio converges to or exceeds one.
Technical people are pretty much second class as it is, the last thing needed is to cement the status quo.
https://news.ycombinator.com/item?id=3407643
There's a lot of overlap with this article but it covers a broader range of experience and also includes some good reading recommendations.
It's been invaluable to my own career.
Leaders tend to build connections with people who have personalities, goals, and/or work ethics that are similar or compatible with that leader. So if you like that particular leader/manager it's more then likely those followers will be good. The opposite is also often true.
As people move into more senior management roles there is an expectation that you have built some form of network.
You aren't part of that inner circle, so you're potential to advance is now limited (assuming you want to advance into the roles the "stooges" now hold).
Or, the stooges are a group of self-serving near-sociopaths who jump company to company with the sole purpose of padding their wallets and padding their titles.
But, this is certainly not a 100% true thing. As noted in a sibling response, it could just be the senior manager has a known "good" set of lieutenants and he's happy to bring them along.
Hardest pill to swallow, but it's mostly true. The old adage, "If you want something done right, do it yourself" is a subversive kind of fallacy, because it's half correct. Yes, you could probably get it done better and sooner, but every minute you spend doing it yourself could have been invested in empowering your team.
However I've seen a bunch of people hit middle-management then stop and its a really vulnerable place if you're looking for a new job. I think its really important to be able to keep some coding in new technologies as they become popular.
Perhaps the best is to work with your developers code - write integration tests, evaluate checkins, research new tools.
Without really planning it, that's where I ended up. Also: establishing best practices and ceaselessly promoting them.
(1) I review the majority of the code that the team writes, and I also read other people's reviews to evaluate our code review practices.
(2) I hack around with new tools & technologies to evaluate them. This has resulted in some code bits in wikis documenting "here's how to get started with this thing", but not touching any prod systems. I usually save this kind of thing for our "personal projects"/hackday days at work.
I also remember the headaches caused when the company went into a sort of panic mode and he ended up doing actual coding on critical path projects in some attempt to dig up out of the hole. I saw that sign as, "the General has his sidearm drawn" and promptly got out of there.
It's a fine example of the potentially counter-intuitive 'Law of Comparative Advantage' [1]
This is a really hard one for me when under pressure: knowing that I can do it myself correctly in about an hour, but giving to to someone else who will probably take several iterations before it's right, resulting in a week or so turnaround and probably 8 hours of work. Or worse, half a week and it never being "right" because we just don't have time.
If you could do the task yourself in an hour, then you could also probably give very detailed instructions in 45 minutes (which ends up with a written plan in a google doc or similar spelling out every detail of how it's going to be done), or even pair on it to get them started.
Maybe you haven't saved any time over doing it yourself (maybe it's even taken MORE of your time!), but you've ensured the thing got done right, and you've also helped level up the skills of the person who did it, so that next time they'll be more capable of taking on a similar task alone.
The experience has been fun and exciting but its a mental and emotional grind more often than not. Knew it would be difficult, but I've found the learning curve to be far steeper than I expected. Its really helpful to read some of the hard earned lessons I’ve been thinking about recently expressed so clearly (#3 and #4 especially).
Thank you for posting.
I like the idea of playing a supporting role on the team. You're there to help the team get done what needs to get done. Most of the time that's going to broader organization meetings, planning, providing growth opportunities etc. However, when there is technical work that needs to be done, I'll gladly jump in and help out as much as my technical skills allow me to. By the same token, if I'm overbooked, out of the office, etc, I'll ask my team to help out with organization meetings, planning and similar activities. I want folks to know that we all play a role and have skills that allow us to participate in some activities more effectively than others, but at the end of the day our greater success comes with our ability to execute as a team, not as individuals.
I just couldn't give negative feedback during performance review
Not giving feedback at all is a problem though, first get comfortable with giving positive feedback. Don't move to giving negative feedback too quickly as a new engineering manager.
As someone with about five years of experience as a professional software engineer, I'm really still looking to level up my IC chops, along with a healthy dose of mentorship (mentoring interns or new hires on my team) and what I'd call "tech leadership" (advising on engineering reviews, making technical decisions about how to best build things). 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).
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. 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 not to say that I don't feel satisfied doing mentorship-style things or architectural advising-style things, but that feels separate to me. I think I prefer empowering other engineers by leveraging knowledge and writing good platforms/tools/APIs rather than doing the organizational empowering thing).
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?
EDIT: I'd also just appreciate being told if I'm thinking about everything entirely wrong or something here.
EDIT2: This also isn't to knock people who _do_ enjoy doing these things, but it's not for me and I imagine it's not definitionally for every good engineer.
-----
Unrelated to the above, point 8 feels a little bit in contradiction to point 1. How does one keep learning their craft without direct experience?
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.
Only reason I’m in a half technical role instead of still in SW dev track is my company and the industry in my location does not generally have good career paths while staying an IC, so for sake of my family I’m doing this for the doubled pay check to put us into financial independence.
But I’d much rather be coding.
I'm all about the feels.
I'd love to see some examples of this because IME it's not true. Great managers/leaders take normal teams and make them successful. Rarely can a single great team member or a great team succeed over a poor manager (unless they essentially start managing themselves).
It reminds of the old adage about great football coaches. The great coach will take his team and beat yours, and then take your team and beat his. Leadership and management is all too often underestimated by engineers and that is to their detriment.
You said half of it yourself: because transitioning from engineering to management entails a promotion.
(The other half: because at most companies, a promotion in turn entails a raise.)
These companies then say, "Hey, engineer XYZ, you seem to be smarter than the average bear. We would like to reward you with career growth, but we are not imaginative enough to come up with something beyond Senior Software Engineer. How about instead we make you a manager? Go, here is a team of people, go off and learn this entirely different skill set and manage people! What could go wrong?" That's pretty much how most places make engineering managers, and it's tragic. Here we have some of the smartest, technically competent people. I mean they rock as individual contributors and should be thriving. But they're not because they don't want to be managers, they just want a software development career!
To me the solution is to simply let coders code and hire managers to manage, and provide equal career and salary growth to each group!
Then 10% pay raise may suddenly evolve into 100% at way cooler place
As an individual contributor, there is just so much you can add to the product. If you find a product that you deeply care about, and want to build great, large features for it, at some point it's easier to lead a team than to code by yourself.
In your case, with only 5 years of experience, I'd say it's typical to work as an individual contributor for at least another 5 years (10 in total). No rush to move into management yet.
For me, my goal is to optimize my career for impact, and I noticed what a huge impact good vs bad managers made on my life & on the whole team, so I decided management was a niche where I could really make a big contribution. I'm not sure if I can be a 10X IC, but I think I can be a 2X manager for a team of 5.
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.
If the position has been vacated by someone who just left, you may see what expectations on the role have stayed in the Company. These may be 'projected' on the new Manager (no matter what the job description says). This would impact the ability to meet your own vision of success in that role.
If this is a new position, created just for you - again, there might be some unexpressed reasons based on what has led to that decision. If one knows the history and the decision makers, one could measure degree of freedom to have any impact in that role.
As others here pointed out, it's a move from a Senior Dev to a Junior Mgr. As such you are Junior on someone's Team, with all the baggage that comes with this.
Politics does not begin at Manager's level, but failing to see how the politics works there is what effectively dooms a new Manager.
Article lists many practical points that are team-facing. My personal favortite is #4 (express your expectations). Equally crucial should be the management-facing points.
I find that for someone with a strong technical background one of the hardest management side to adopt may be a _negotiation ability_ and a capacity for compromise, especially with the very little leverage as a Junior Mgr usually has at her disposal.
It is always: here is your job that are requirements. No meaningful one on ones. It is not only in work, I just all life have to figure out taxes, relationships, learning, work. What is even better when I was trying to pay for advice of accountant they did not take my money and no advice. I got advice from attorney but it was useless, I figured out later on my own.
Oh I got some advice from relatives like uncle or grandma but that was like outdated and totally not true anymore. Almost got fined for trying to apply that.
So my point is no one cares about one on ones and mentoring, and someones advice on life or carreer because probably they still have to figure all on their own, and they think they are smarter. so better keep track of tickets and that stuff is rolling, keep obstackles away from team and don't say yes to everything.
Absolutely this. You have to let people know what you expect and where they stand, and with honesty and compassion.
I'm surprised this article doesn't mention setting boundaries. As a leader (and coder), the best thing I've learned to do is set aside regularly-scheduled time to meet with individual colleagues. People no longer walk into my office or ping me on Slack when they run into technical problems. They take the time to think through things before bugging me and often come up with solutions on their own. It works wonders. Don't be a jerk about it, but don't be as available. If someone interrupts you with a technical problem, tell them that both of you should set aside dedicated time to discuss and explore it.
- Have clear rules about code quality, how to get code in, enforce rigorously
- Have open, written discussions about what is going to happen next (Agile can do this, most of us take the lazy option)
- discuss ad nauseum
- try out new things - lots of spikes. The spike to new code ratio for a mature product should be large
- then and only then worry about the way you fit into politics and people
Called Soft Skills Engineering Podcast. It's hosted by two seasoned developers whom experience becoming managers. It's hilarious.
I listen to it when I commute with earpohones, then and suddenly laugh like a wirdo.
That and keeping the build running smoothly.
1. (don't) Keep coding
8. (don't) Stop learning your craft