3. Do well for a few years until you become out of touch
4. Watch your team stop respecting you on technical subjects because you’re behind the times and too rusty but don’t know it so look foolish and are ignored when you give suggestions, which radically undermines your relationships with them as well as your ability to lead
5. Watch as your role morphs from a manager with chops and respect into a PHB, unless you happen to have been born with natural leadership skills (you probably haven’t)
6. Realize you are now just a mediocre manager who can no longer return to the engineering track since you cannot compete with other candidates
7. Drag yourself to retirement by slogging through life as a relatively poor middle manager
> unless you happen to have been born with natural leadership skills (you probably haven’t)
Leadership skills are important, but I disagree that leadership is something you’re either born with or not. Leadership can be taught, learned, and practiced.
The real issue is that a lot of people who are pushed or drawn into management roles don’t actually like managing or leading. Some are pushed into management because they’re the most competent IC on the team. Others are drawn to management for the perceived prestige or possible career advancement.
Some common failure modes for engineers turned managers:
1. A person who enjoys quietly coding alone for hours at a time is not going to like being removed from the code to do management work
2. Anyone who dismisses relationship building and diplomacy as “office politics” or “brown nosing” is going to struggle to build the required relationships to get things done as a manager.
3. People who get exhausted from context switching or juggling multiple topics will hate the manager’s schedule.
4. People who loathe meetings are going to be miserable as managers.
5. Anyone who struggles to have difficult conversations, broach uncomfortable topics, or confront people who are causing problems is going to struggle to lead.
6. People who assume they’ll naturally be good at leadership or management won’t learn the necessary skills fast enough, unless their company forces it on them. There are many good resources for learning management and leadership skills, but it’s not uncommon for first time managers to assume they’ll learn it on the fly.
>The real issue is that a lot of people who are pushed or drawn into management roles don’t actually like managing or leading. Some are pushed into management because they’re the most competent IC on the team
I think this is spot-on. People, for whatever reason, view management as the next step of a career when it's actually a career change. Yes, it's in the same domain, but it's a totally different job.
I've done the transition from IC to Manager, back to IC, and then back to Manager again. Unless you like and want to do "manager" things, you're going to have a bad time.
I will also add though that I think there is another dimension as well. I think much perceived middle manager "incompetence" stems from middle management juggling direction/pressure/expectations from senior management, and the realities of the program and the engineers. The best managers are capable of managing expectations from above while keeping their team shielded from all that overhead and just keeping the team chugging along and being productive. Other managers seem to have the ability to weigh their team down by allowing too much of the "managment overhead tasks" to leak down to individual engineers. I've seen this vary across programs and managers, and can't say I know all the answers, but I do know I much prefer the role of the IC....
- reduce Peter Principle and pyramid org-chart building
- retain, train, and invest in good managers as a profession, not a will to power
- hire more administrative and secretarial people to navigate the minutia to unblock highly-paid employees from finding answers in the bureaucracy and doing unnecessarily-dumb paperwork
How have you found success balancing these things? It’s been my experience that managers of the first group eventually become unintentional members of the second group, even despite their best efforts to maintain productivity of their subordinates with intentional prioritization and grooming exercises because the business wants that new feature yesterday, and not getting it means lost revenue, angry customers and negative performance reviews.
What happens though when the business puts these types of middle managers in the impossible position of not being able to say “no, this isn’t a priority right now” but still expected to maintain the same amounts of engineering productivity and feature throughput?
> not getting it means lost revenue, angry customers and negative performance reviews
Staying in exactly the same place won’t affect revenue, customers or performance reviews at all. It’s when people work under the mistaken assumption that they have to increase at all costs that you have a problem.
> business wants that new feature yesterday, and not getting it means lost revenue
That's just plain bad planning on a business side of the company. They should either fix that, or face gradual departure of their workforce, from best to mediocre.
I don't agree with this. I enjoy management and coding. However, when I'm in a manager role, I consider contributing with coding to be an essential part of the job, to maintain my ability to lead the team with credibility, truly understand what their job is like, and differentiate myself relative to other managers, who by and large have bought into the narrative they can't and shouldn't try to code.
This cuts directly against the narrative by the article, and the narrative of the article is the common one. The argument seems to be "you just don't have enough time to do both well!" but in general, there's no free lunch here, you are choosing between different trade-offs. Management is hard no matter what, but if you already have the skill to contribute to a team's efforts, you're not just leaving money on the table you're lighting it on fire by abandoning it by letting yourself atrophy into becoming a manager who's skill stack is shallowly scoped to people management and leadership skills. Whenever you see a commonly held narrative like this that has clear negative consequences to those acting on it, all other things being equal it pays to be contrarian as long as you don't fall into the obvious traps, since you're going to differentiate yourself.
I'm surely not the best manager and I'm sure I suck at a lot of it, but everyone does somehow. I'll go head to head anytime with an engineering manager who doesn't ship anything anymore any day of the week in terms of who engineers would rather have as their leader when building something difficult.
I would like to add my perspective as an IC who is reporting to a technically-focused manager. I feel frustrated that my manager does not spend even 10% of the time they spend coding on coaching/guiding/giving feedback to me. I feel that part is more important aspect of being a manager compared to churning out code. I understand the need to keep on top of the codebase, especially when coding is something you really like. But if you don't spend enough time on the growth of your reports (amongst other responsibilities of a manager), why bother becoming a manager?
Edit: Just to clarify, the question in my post is kind of directed to my manager and not to parent commenter :)
Yeah I think this just shows the trade-offs. The path forward for your manager here is to grok they need to turn the dial, at least in their relationship with you. What I reject is the idea that the dial needs to be dialed all the way away from coding, especially permanently, or that doing so is not without immense costs.
It certainly makes the job of a manager harder when you are forced to reckon with the fact that you can't just throw out coding without it undermining your ability to be a good manager. In practice, I would try to ebb-and-flow with the teams' needs - it's a dynamic, challenging process.
Also, there's a tricky issue of, as a report, being able to identify what is intentional vs unintentional. Your manager is probably failing you, but there's also a chance they are forcing you to grow by disengaging a bit and letting you fall into a few ditches. Sometimes a good coach will just shut up and let you make mistakes. Until you see the net effect of their behavior on you over an extended period, you can't know if you have a good coach who is pushing you in a way that you can't see, or a bad coach who is just failing you. A lot of people with good coaches resent them in the early days for being too hard, too disengaged, or other things, which forces them to push themselves harder.
I agree with you that I don't want my manager to completely stop coding (especially if it is something they like a lot). I just want them to realize that there are higher priority items on their list of things to-do. And spend at least some amount of time figuring out how to help their reports grow.
Also, this depends on the experience level of a manager's reports as well. If all of them are quite experienced and have clear goals regarding their career, the manager does not have to spend much time on career coaching. They can focus most of their time on coding. But if that is not the case, then they'll have to balance their time accordingly.
That's a good point you make regarding intentional vs unintentional. This point had not occurred to me earlier. After thinking about it though, I am confident that its not applicable for my scenario :0. I will have this in mind for future situations so that I don't come to wrong conclusions.
> And spend at least some amount of time figuring out how to help their reports grow.
I hear this an awful lot, but either as a manager or IC, I have no idea what it means.
From my perspective, if you leave me alone to do my thing and don’t interrupt me with random shit all the time, I’ll grow naturally. But the manager doesn’t have to be involved in this beyond shielding me from the bullshit, so I guess people are talking about something different.
>From my perspective, if you leave me alone to do my thing and don’t interrupt me with random shit all the time, I’ll grow naturally. But the manager doesn’t have to be involved in this beyond shielding me from the bullshit, so I guess people are talking about something different.
That's what _you_ want, but it's not what everyone wants. Some people want or need much more active participation in their growth, and it's a manager's job to find what's right for each person. A common failing new managers make (and one I made as well) was assuming everyone wants to be managed like I want to be managed. I was very much in that "leave me alone and let me do my thing" mindset, and that caused a lot of problems much later in life.
I think it depends on how each org or company defines its team structure and the responsibilities of the different roles. We don't have a separate tech lead role in our team.
Even so, wouldn't a tech lead be focused only on technical aspects. Say if I want feedback on some customer interaction I had or maybe regarding a meeting I ran, it is not the role of the tech lead to do so I think.
A lot of technical leads who become managers assume they're doing a good enough job on the management side and that they have to master every technical detail, when the truth is they're only convincing themselves that their split allegiances, attention, and priorities aren't a problem of trying to work two jobs.
An engineering manager who was technical, listens to their staff, and delegates can still be respectable and has the time and focus to help the team in a greater capacity with non-technical things proactively rather than reactively.
An engineering manager who can setup an HA database is as useful as a fireman who can play chess. It's all well-and-good, but it doesn't add value to the management of the team if someone else has that duty. Technical leads yes, but not managers.
You've clearly stated an opinion, but not an argument. You've also smuggled in the claim that an engineering manager who ships stuff is performing two jobs. I argue that engineering managers who cannot ship stuff are performing half a job. (I don't really, but you can see why this is a fallacy in both directions: it's an argument around definitions.)
Your opinion is the same on made in the article and is the consensus view. To me, the consensus view is there for a lot of reasons, one of which is that it's a common anti-pattern for formerly technical engineers to become managers and let themselves get drawn into the code at the cost of management. In all things, balance. The other, more general anti-pattern is to see a failure mode and then presume the diametrically opposed opposite is the global optimum. If engineers are prone to be bad at management because they get sucked into building stuff, then whatever benefits may come from that should to be ignored: they should abandon it altogether. (This is a common error in other domains, like the canards "ideas are nothing execution is everything", "you should never pick stocks, and only invest in index funds", etc.)
It also turns out it's much easier to believe that engineering managers who ship code are worse managers, because it means that you can feel good about deciding you're going to stop coding: you're doing it to do your job better. You already have so little time anyway. But what if it turns out being able to ship stuff actually helps you in being a manager? Now it's harder: you have to decide where to draw the line. And so, it's a much more difficult thing to come to terms with since it means there are no easy choices and you actually have to live with the fact you are always going to suck at this in one way or another.
I argue that, all other things being equal, having the ability to ship with the team makes you a better manager. The question is if that is true or not, and if so, at what point does the trade-off stop making sense to maintain that ability. Creating false hypothetical situations like "setting up an arbitrary HA database" doesn't prove much of anything about the actual, local, domain knowledge I'm referring to that you get by continuing to perform IC-like work alongside the team you manage.
I replied elsewhere a longer form argument, in the form of concrete examples, why I feel being able to ship code confers benefits to engineering managers. I'm not going to argue about titles. Titles are useful for internal political signalling and are basically minimally-transferable cultural norms, but less useful for determining how to best take care of your responsibilities. For the purposes of this discussion I consider an engineering manager's responsibilities will be to maintain the velocity, mental health, and general happiness of their reports. People who argue about the role a person has and what they ought to focus on based upon their designated title, or in this case derive it in the opposite direction, to me, are mistaking the map for the territory.
Also, if you think I'm writing this to defend my ego, you ought to become a psychologist since you are able to read minds over the internet.
Then why are you writing? Why are you unable to interact without respect and curiosity but with adversarial hostility? Are you going to escalate to name-calling since you don't have an argument, only rationalizations to reinforce your worldview or the inability to consider approaches outside of your own? Maybe curiosity and self-reflection would help improve the quality of your conversations rather than promoting a religious doctrine through snide defensiveness.
Interesting that you’ve now accused me of arguing to protect my ego and being snide in the same breath as saying I’m the one being hostile. All I said is that you expressed an opinion, not an argument, which is explicitly true based on your first reply, and explained why if your argument was going to be about why actually there is no trade off why I disagree with it - based on your further responses it feels like you may have taken that personally. It wasn’t personal.
If you’re going to accuse me of a lack of curiosity then you need to explain why anything you have written actually does more than repeats the claims in the article I was explicitly rejecting, or why my claim that you leaning on titles to form your argument is just debating over definitions is false.
Ugh and it's not usually their fault. Too many orgs are promoting this by making manager pay higher. In a sense higher pay is the career goal. Why stay in coding when you can get a 30k bump for coding plus whipping people?
I was pushed into it because they needed a supervisor in that position. I might be a decent leader from a technical standpoint, but not a good manager after a year into it.
Guess it all boils down to management vs leadership. I just wish we could go back to not calling every second employee a manager of something.
„manager of technical people“ is great example. You would expect a technical person who the team respects with equally great management skills, farsight and vision.
I'm curious. Multiple back and forth seems to indicate that you missed your previous role. Was that why you made multiple shifts? Or were they just different opportunities?
I would argue pretty strongly that if you are not a natural leader, the road to development of leadership is paved by domain knowledge which lets you get respect “for free” to leverage to ratchet up those skills. So I’ll adjust what I said to mean you are racing against your engineering skill atrophy to develop those leadership skills. Once you can’t code anymore, it gets a lot harder to do so.
I don't get it, doesn't everyone dislike/struggle with these things? Who likes context switching, office politics, sitting in meetings and having difficult conversations
The truth is that if you’re a manager who has no other marketable skills, you can only hate pointless meetings so much since without them you’d probably be putting your resume in down at the local Starbucks. Clear an engineer’s calendar and you probably make a more productive engineer, clear a manager’s calendar and regardless of the consequences to everyone else one thing is sure: that person’s job function is no longer obvious.
If you’re in sanitation, you have a more nuanced relationship with trash than those who aren’t, even though everyone dislikes trash.
Good managers should abhor pointless meetings as much as anyone else - their task is to make useful meetings. Anything else is just a waste of time and wasting everyone’s time is not exactly the hallmark of a good manager. Now, there’s people that hate all meetings and regard them all as a waste of time and if you’re one of those, you’ll never acquire the skill to actually make meetings useful - this is a skill which needs training like any other skill does.
If you work in an organization where such meetings are the norm, please share what led to such a magical place. I've heard Amazon is such a place but I'm very skeptical. My general presumption based upon years in the industry is that by far the majority of scheduled, large block meetings are not worth the opportunity cost of having them. Effective meetings don't come from an individual transforming normally ineffective ones into effective ones by some form of wizardry over everyone else in the room, they come from a culture where everyone makes them effective together through shared values. In a large enough organization, this seems basically intractable to maintain. IMO the only way to win is to not play and move most meetings to short, unscheduled ones with timeboxes in conjunction with asynchronous communication tools.
> My general presumption based upon years in the industry is that by far the majority of scheduled, large block meetings are not worth the opportunity cost of having them.
I entirely agree with you here - I disagree with the notion that "managers" (should) like those meetings any more than other folks. Most large block meetings are ineffective, the more effective ones have a strict agenda and someone moderating them with that agenda in mind. They can be useful for announcements or large-scale alignment, but most of them should be struck from the calendar with no replacement - and good managers recognize this and strive to do so.
> Effective meetings don't come from an individual transforming normally ineffective ones into effective ones by some form of wizardry over everyone else in the room, they come from a culture where everyone makes them effective together through shared values.
The person leading a meeting can make a substantial impact -
being prepared, making an agenda and a plan, setting a clear goal for the meeting, deliberately limiting the number of people attending, requiring others to come prepared and enforcing that (possible adjourning the meeting if it turns out to be ineffective), time boxing. There's no magic place where all meetings are effective or feel effective for everyone, but there are places that try to improve and there are techniques that make improvement possible.
Point taken - I think to drill into my point more is that very few meetings are objectively "pointless" - and managers are much more likely to see a meeting as having "value" than the engineers, in part because of the effect I mention where their jobs are defined by meetings, not in spite of meetings. (Sometimes this is not the case, eg a manager may see the latent value of literally just having two people in the same room together and talk to one another who would otherwise not, for political purposes, that the engineers cannot understand.)
To cut it in the other direction, your average testing engineer will have a much harder time agreeing with the idea that most of your test suite is useless and should be thrown out, even if it is useless, because to do so would be to admit that their entire job is less credible as a concept if it is true.
I disagree that a managers job is (or should be) defined by "meetings". A mangers job is to facilitate certain aspects of shared work, for example alignment on goals, ensuring availability of resources (financial, time, expertise, ...), recognizing and possibly removing obstacles. Meetings are one tool that can be put to use, but they are not an intrinsic goal. The same holds true for a good QA engineer - their goal is not writing a test suite. The same should hold true for a programmer - the code is not the goal. Removal of useless code is a good thing. However, there are people that fail in all of these professions - I've seen enough coders that write complex code for the love of complex code, DevOps folks self-managing kubernetes where a simple virtual machine would have been sufficient and managers hiring people just to increase the headcount of their department and increase their perceived standing.
I don't think implying that QA engineers being biased in favor of having unnecessary automated tests is the same thing as saying that QA engineers have a goal of writing tests. It's just the nature of the beast. My point is jobs inherently favor artifacts or actions which (perhaps ceremoniously) justify their existence, and often resist attempts to remove such things since they've integrated those things as core to their job function (even if their motives and goals are in fact not to create those artifacts.)
No. Some people like relationship building and diplomacy. Building the business. Having meetings fleshing out direction and staffing needs. And many others will put up with it for the increase in compensation and tell themselves it's not that bad.
I really honestly dont mind context switching all that much. It makes me less productive or course, but it does not make me angry or annoyed.
There are plenty of meetings I honestly dont mind at all. Some I do mind, but it is more about how those meetings are moderated then hating on meetings in general.
> Some are pushed into management because they’re the most competent IC on the team.
So Plato's Republic describes how this comes about since ancient times, I wrote something a bit more detailed[1] about it.
But here's the TL;DR - the punishment is that he who refuses to rule is liable to be ruled by one who is worse than himself. And the fear of this, induces the good to take office, not because they would, but because they cannot help ... because they are not able to commit the task of ruling to any one who is better than themselves, or indeed as good.
Some are pulled into management because of the existing mastery and a looming management vacuum.
This isn't something new in tech - it has always been that competent people leave their mastery work to do management (rather politics of ensuring funding), because they see no other choice.
Until I found a manager who was better than I was (and once I understood how they did it and what they did all day), I did think in very similar lines, a little bit aided by the "I'm a smart guy" ego clouding my judgement.
This is definitely true for me. I cannot imagine wanting to inflict some of the managers I’ve had on the members of my team. Better me than the chance of someone worse (and I’m pretty bad, I just judge the chance of someone worse taking it up if I stop to be higher).
Do you have recommendations for how to go about 6?
I've been moving into a more manager-like role and your list makes me a bit worried, though I was already considering this to be somewhat temporary. So far it's been a valuable experience though (harder than I thought).
About 2 - I actually really enjoy relationship building. However, if you have issues like nepotism or problems around equity in the organization, I think it can be really hard to have to work with people who make decisions that you find distasteful. That's the main thing that makes me miss the solitude of coding.
One of the biggest hurdles is most people don't want to be responsible for thinking for themselves, their judgment, and their decisions.
And then poo-pooing things outside of their current role that they either don't understand or don't appreciate.
In large orgs, I think one day a month staff should have to intern in a random department to appreciate what others have to go through to build morale and empathy.
A good leader is a humble, messianic therapist, salesperson, and accountant.
2b) Start coding again because your superiors promote you to management but treat you like you’re still an IC and ask why you haven’t contributed any points to the latest sprint while actively shutting you out of the kinds of discussions and decisions an EM would be making in most other orgs—-while somehow simultaneously asking you to also be the bearer of frequently changing and poorly communicated business priorities for your subordinates
Yes it’s happened to me, yes I’m a bit bitter about it, yes I’m looking for a new job because of it
Heh, I also fell into this trap once. (I no longer work there.)
Just as much coding work as before, plus becoming the interface between the developers and the actual management, with no pay raise of course. Not able to change anything, but regularly reminded that I am responsible for the results.
It means "individual contributor" , and implies you don't have any reports. As opposed to "tech lead" or "player-coach" (currently in vogue) which implies you are supposed to be effective as a technical contribute but also have a formal manager relationship with at least one person. Let a lone a classic manager who doesn't do much or any direct contribution technically.
There is some confounding in this thread of manager-of-people roles and manager-of-things roles, which also causes confusion.
I always feel bad when I see someone who was pulled to the management track early in their career. They often never acquired the technical skills or even knowledge of the technical skills of their more senior engineering counterparts.
It really does a disservice to pull someone into management 3-5 years into their career. People will often take the role as it looks like a promotion, but ultimately it's a lateral move with slightly better pay in most environments.
Though I thoroughly enjoyed reading this dark path, in reality the bar is set so high in top companies that an engineering manager is usually an architect/senior engineer/and a people manager.
So most don't make it, and those who do have a tremendous career that's fulfilling and financially rewarding.
This is a great observation. At Amazon it's quite possible to become an L5 manager after being an SDE II for a while, but most of the people who do find it very challenging. They don't have the organizational clout to get things done because nobody respects a manager at that level and because more senior technical folks will steamroll over your technical opinion. To be a successful EM there you pretty much have to have made it to SDE III before switching over.
My intuition for this is leverage. As a people manager, the team's output is your output. When you manage a large team, small changes in IC output can quickly exceed 1 FTE. These multiplicative productivity improvements are why Managers get paid more.
There's tons of ink spilled on the idea of the 10x engineer. Let's assume that exists. Even if an extraordinary single person can deliver 10x output (call that 10FTE), a good manager can deliver a similar productivity boost by merely 2x'ing the output of a 10-person team of average ICs (10FTE output -> 20FTE output for a delta of 10FTE, same as hiring a 10x engineer, which is hard to do.)
If you have a 10 person team of 10x engineers, a good manager can deliver that 10FTE bump by increasing team performance by just 0.1x (10x 10FTE/person = 100FTE -> 10 x 11FTE/person = 110FTE team output, for a 10FTE boost). THAT is why good managers are worth paying.
Don't sell yourself out for money unless you need to. Figure out the amount of money you would like to make then if your at not getting paid that at CurrentCo go find a darling SV company, unicorn, or a FAANG+Microsoft and switch to an IC role at one of those companies and get paid better.
Going into management for money is a terrible reason to become a manager...
Unless of course your goal is executive management... but that's very different from engineering management.
I agree, and I think you should only go into management if you like managing. You can be a good IC and a good leader and a good manager, but more than likely you will be better at one or two out of those three.
You're sort of arguing though that, if you don't want to go into management, you should become an extraordinary IC (or just accept you'll get paid less money).
Sure. Absolutely nothing specific to tech. In fact, many big tech companies have a much better IC career ladder, mostly but not entirely for engineers/devs, than non-tech companies do. Sales is the main exception I can think of.
That's exactly why I was adamant (on condition of taking my current manager role) that I was always going to be coding. But I agree with most of these steps and when I was solely an engineer, I resented managers in 4 - 7. It was my goal to never be like that.
Don't think people are born with leadership trait. Its the experience that one goes through in work and life and along with the thinking that goes with it that makes a leader.
If people are born as leaders, how come world history is full of bad kings/emperors?
Interstingly I found a similar career path in many scientists. Some of them are getting completely out of touch (you never see them in a lab, they don't learn new techniques, they rigidly defend things they learned before but that is obsolete) and just presenting their students/postdocs works and editing papers.
Too pessimistic. Many ways of having a successful and happy live. You can teach, mentor or become an advisor. You can also start your own company. Or you can find something entirely different in a different industry. Going up career wise isn't the goal you should pursuit
I hope your realise that the days of being a white, middle aged programmer are coming to a close. If anything, get some management/leadership skills under your belt if you get the chance.
I've managed several teams at this point (maybe poorly?) and have been hearing this warning for at least the last decade from the other managers who can no longer ship software because they bought into the idea that being able to do so meant they were choosing to be worse managers and therefore harm their team. (I don't know what being white has to do with it.) I'm pretty sure the tendency to instill this kind of fear in others often comes from the need to rationalize the choice such people made to leave behind their hard-earned ability to build and ship software. Since if it wasn't the case the people like me would eventually come to realize their profound error, now ruined by their mistake to prepare for their eventual undoing (due to age? AI?), it would mean that they gave up something that presumably made them happy, that they can't get back easily. I was told this will happen to me when I got married, bought a house, or had a family. Those events did not have the effect, so I presume when people told me this it just meant they had those changes in their lives force them to decide their coding days were behind them.
For the most part these people are now never going to be ICs again and must find a path that lets them hop from one VP of Eng job to another. It's a lucrative gig but feels a bit like a house of cards ready to crumble at any time, at least that's how it would feel to me if it was my only forward-looking career path. When belts tighten they're the first to go.
I seriously question #4. While the popular tools and languages and techniques churn, there are no fundamental revelations in software development that cannot be understood at a higher level by somebody who stopped programming in the 70s. If anything, not being obsessed with the churn helps these managers step back and ask fundamental questions that are often ignored by magpie developers.
It is very possible to keep up do date on all the new tech coming out at a surface level, ie enough to manage engineers and ask questions, without spending the time to deep dive into the nuts and bolts of each new tech.
For 3, you can keep yourself informed without coding on the job. Continuous education is a common part of many professional careers. Just code a personal project every couple of years and read the tech news and you’ll be fine.
Not to mention just sitting in on code reviews and listening to the developers will help keep you continuously educated. Take notes and read up on any debates that come up that confuse you.
No, I'm not talking about those kinds of skills per se. ("Fundamental revelations.") I'm talking about:
- Grokking what actually sucks about the tools, languages, frameworks, etc in use. And grokking what complaints of suckiness are shallow or misplaced. The former is an opportunity to deliver empathy for the team's suffering and propose good solutions, the latter is an opportunity to remind engineers (esp junior ones) not to be overly-cynical or see problems where they don't truly exist.
- Ability to participate as a true peer in technical discussions, which deepens the bond you have with your team. If you are able to contribute one or two concrete, correct, and actionable ideas that unblock developers or the project's construction every quarter, it pays dividends imo in counteracting dynamics where you are considered an "other" in certain contexts given your position. I'm not talking about things like "maybe you should write some tests" but "maybe you should ditch that testing framework because the problem you are hitting is a non-issue if you just write a special harness yourself. You can start from mine." It's no silver bullet, but it helps. If you literally save a week's worth of effort for a team member by cleverly reframing the work they are doing to a better MVP they can handle (via your domain knowledge and intuition about implementation difficulty) they will be unlikely to care if you accidentally forgot to send them a birthday email. If you don't do that regularly, and basically are a full people manager, the missing birthday email could be a big problem.
- If you aren't in the trenches at all, lots of problems will crop up over time that are insidiously hard to see once you've exited having the domain knowledge. For example, you won't be able to assess talent well enough to flag bullshitters who manage to sneak past your team's interviews. (Given you are the manager, you probably tilt more towards having the people skills needed to detect bullshitters which your team lacks, but without domain knowledge, neither you nor your team may have the total sum of skills needed to detect them.) Or, when giving overview discussions of how the software systems work to other managers, your team members might have to start biting their tongues when you're explaining things in a way that is objectively incorrect but coherent in your (now shallow) mental models. Having to regularly hear your manager saying something that is totally wrong is demoralizing, because it means you either have to "educate" your manager, which is awkward, or you have to effectively endorse what they are saying by staying silent.
All of these come from a loss of literacy in the local domain of the work your team is doing, not in general principles. These are totally different forms of literacy, and the latter one is dynamic and requires effort to maintain (and losing it comes opportunity cost.)
Edit: Also, people saying sitting in code reviews is good enough are fooling themselves imo - to believe that you also generally need to believe that you can become a good programmer on a project by just doing code reviews enough and then instantly be able to execute as a top-tier team member. This is objectively false. So the question is what margin is needed between "code review level literacy" and "building literacy" to get the benefits I mention. I'd argue it's a pretty big margin.
If you're not coding 100% of the time on important value add tasks, you're not ever going to be as technical or as current on the details as your team. As a manager being the technical lead IS NOT YOUR JOB. You have people for that. Empower them, listen to them, arbitrate between them, enable them to get their job done.
It is not your job to decide what technology is best, your team is the one with that know how and will offer you choices and tradeoffs; if you need to decide you'll need to trust their information to choose the best set of tradeoffs for the business strategey. Trust them to give you the right data. Nurture the team so they don't lie to you; if they're lying to you, there are much bigger problems to solve than the technical details.
I completely agree with you. How do you prevent this happening? I've relocated from a team where I used to be a software engineer on the team (and therefore had a peer-level understanding of the systems) to one in a different company where I'm starting from day 1 as a manager. How do you maintain/build that localized domain knowledge? It doesn't feel like it's solvable by doing a week of coding now and again.
I will disagree with one point. Neither eng managers nor tech leads should be doing project management. It is a unique skill and worth having someone explicitly in charge. They should own the structure of requirements docs, story breaktown, ticketing, jira processes, etc. While they may be somewhat technical they are more ensuring consistency and quality of process without burdening devs.
The best team composition I have ever worked on looks like this:
Product manager: Has <=3 teams knows company product / strategic goals / customer needs. Sets high level goals, updates those in response to scope estimates, coordinates with product org.
Eng manager: Highly technical, has institutional knowledge of codebase + understands the politics of the org. Has <=3 teams. Sets tone, handles dev career growth, mediates/prevents conflicts, recruits, shields devs from institutional nonsense.
Senior Dev / Tech lead: Trusted by eng manager to independently make arch level decisions. Can mentor / peer with / support other devs.
Dev1: Specialist in one relevant aspect of stack, but with general knowledge (can pick up any ticket if needed)
This group is flexible, resilient, and plays to people's strengths. If you don't have a project manager then yes it can be left to the eng manager or tech lead, but it's not ideal.
Do you really enjoy having 3 different managers to report to? All of whom have 3 different projects they’re dealing with? IMO, it’s better to have a 1:1 ratio of managers to teams. A 3:3 ratio is a recipe for endless meetings and communication overhead. 1:1 and 3:3 have the same number of employees, but 1:1 eliminates all of the communication overhead because there’s only 1 manager per team instead of 3.
In my experience, splitting managers, designers, and QA people across 3 simultaneous projects results in 1 project dominating their time and the other 2 projects being starved for attention. Repeat this across the product manager, engineering manager, QA person, UI designer, and project manager and you virtually guarantee that every project is going to be starved of resources.
Instead of having 3 separate product, project, and engineering managers split their time across 3 different projects and wasting time synchronizing with each other and the teams, it’s better to have 1 person handle the role of product, project, and engineering manager with 100% focus on the project and team.
I’ve worked in teams like you’ve described. It quickly turns into a mess of meeting scheduling conflicts, repeating every discussion 3 times because you have to communicate it to 3 different managers, and constantly working around blockers because your UI or QA person has been pulled into a higher priority project.
Put small teams together. Let them focus 100% on getting things done. Don’t cross everyone over to 3 teams. Don’t give everyone 3 different managers.
Product manager (Product Owner in scrum), Senior Dev / Tech Lead, Dev1, Dev2, QA, and UI/UX Designer all report to Engineering manager.
Further, changing the mindset from "as a manager these reports work for me" to "as a manager I work for these reports" improves the feeling of ICs having "multiple managers". The managers job should largely be unblocking the ICs.
In my experience, product managers have never reported to an engineering manager.
Which is probably part of the problem, and why this type of hierarchy can lead to a "3 managers" type scenario. The product manager, senior dev / tech lead, and engineering manager all have some management responsibilities. When the separation of responsibility is not clearly delineated, so the regular team members are left in an awkward position of having 3 different people they have to report to, and often get conflicting feedback from each of them.
I would further note, if you have a Project Manager that reports to leadership outside your direct team, you should have a Product Manager on the engineering team to counter-balance. Project Manager's goal is to drive leadership initiatives, where as the Product Manager's goal is to guard the members of the team so they are not stretched too thin and can build a quality product.
> 1 person handle the role of product, project, and engineering manager with 100% focus on the project and team.
This is incredibly difficult to get right. A good product manager needs to be spending time "in the field", sometimes literally but always in terms of focus. A good engineering manager has to be spending time "in the lab", again literally & figuratively.
These two things are in contention, and balancing them properly in one person is very difficult.
Anyone who has project management skills can do that part, but trick is dedicating enough time to it. On a complicated project, this can easily become a full time job.
matrix management has it's own challenges (not that this is the only way to handle it) but your contention that because there are 3 "managers" involved means that everyone "has" 3 managers just isn't true. Most of this stuff is about responsibilities, not chain-of-command.
I don't think the IC's have 3 managers in this arrangement. The product manager & engineering manager work together in a customer-provider relationship, while the project manager acts as a sort of facilitator and metrics collector, & doesn't hold direct authority over the IC's.
I think this is about right, but one sticking point I've found is: what kind of employee is the project manager? Who do you hire, what is the career trajectory? There is a temptation to have them be a manager, because hey, manager is in the name! But having gotten over that, there is a version of the job that is essentially entry level work; what you describe of managing the tickets and all the stuff is just not very high level work relative to what the rest of the team is doing. But then what is the progression? What are they trying to do after they've put in their years wrangling tickets? I think this can actually lead to a lot of unnecessary complexity. If you have a smart and ambitious person doing this job, they're going to naturally look for ways to make it more meaty. But it doesn't really need to be, so you're in a bit of a bind.
I think this is where the impulse to let the managers handle this as a small part of their job comes from. It's already clear who the managers are and what their career progression is, and handling stuff the team needs to unblock, which doesn't fit well into any particular box is already part of their job.
Project/program management is probably one type of position that almost has to lead to people management at some point. Basically operational roles that have project/program management (folks) among others reporting to them. In other words, having overall responsibility for projects of smaller or larger size.
Ideally it seems as if you'd want someone with administrative capabilities and focus but with enough understanding of the tech and business side that they're able to understand context and conversation.
Problem is, although its easy to find administratively capable resources who you can pay a decent salary to retain, the minute you require them to understand broader context the incentive structure changes as this is inherently more work.
To me that is why Product Managers who's focus is a single product should also take over administrative tasks on that project. It gives them an opportunity for "field time" as stated by another poster as well.
Oof, I really don't think that's a good use of a product manager's time. I want them out talking to customers, or evaluating similar products from other companies, or using their own product to understand its capabilities and gaps, or looking at metrics, or just writing and debating product proposals. I honestly think there is already way too much work that is way too valuable for them to be doing, for them to take on project management duties. It's a much closer fit for an eng. people manager if a dedicated resource can't be found or hasn't worked out. At least their job is already interrupt driven and focused on knocking down blockers for their team.
The challenge with this is that you have ~7 defined boxes that you are trying to put a team of 7 individuals into ( or 7 roles and 13 people ). At any given point in time there won't be work commiserate with all 7 job functions, people will grow to a different role, someone will be the bottleneck, and someone will be MIA or in a backfill.
It's often best to keep the number of roles low on the team to increase flexibility/provide freedom for individuals to tailor the roles to their own strengths.
I just left a team that was structured similarly. It was a pleasure managing them.
Team members were:
- Manager (me), BA - managed backlog and some project management (actual title was principal dev, but she wanted a role change), 2x senior developers (both capable of architectural work), 2x developers, 2x test engineers, 0.5 Product manager (they report through their own branch of the org chart and cover several related products).
Additionally, I had 2.5 developers working on a different project, run as a separate agile team.
New team is 1 architect, 1 senior dev, 1 dev, 1 test engineer. BA and PM support comes from elsewhere, which is a big change fo me. Also in a new technical area (SRE vs 20 years of product/app dev). Fun, but stressful. I'll reserve judgement on the lack of BA/PM until I'm a few months into the role.
It's impossible to overstate how much I agree with the need for a separate project management role. Project management is the biggest distraction I have from the "things only I can do" and the biggest morale and time suck. I don't have advice to give because I haven't solved my lack-of-project-management problem, but I sincerely believe I could be much more effective if this was off my plate.
Can I just throw in a wrinkle, I'm what could be described (from this list) as an Engineering Manager and Tech Lead. I architect and implement solutions while also doing all the traditional managerial duties. I feel like I've been eaten alive lately on HN that this arrangement isn't possible and you cannot do both well, but I beg to differ.
What I would say is that it's possible but very rare to do this well, and furthermore that people often don't have an accurate sense of how well they're doing at it. The individuals on the team might know but might not want to say, but an even bigger problem is the individuals on the team not being aware there is a better way. I was about a decade into my career before I had an experienced dedicated engineering manager. I had already spent time as a tech lead / manager myself by then, and thought I had done ok, but experiencing a dedicated engineering manager made me see that I had actually done the job quite poorly.
You may be doing it extremely well! It does happen. But I can understand why you're getting skepticism.
A lot of us have been an engineer on a team where the dev manager thought they were contributing but were actually taking all the interesting architectural problems for themselves and making all the decisions, which quickly becomes extremely demotivating since the opportunities to advance your own skills quickly dry up and you’re left just mindlessly cranking out code. The worst is when an abstraction is imposed on the team that doesn’t adequately cover the problem, so you have to spend twice as much time bending the code to make the dev manager happy instead of doing it the way you think is best.
Granted this is just one way that situation can go, I’m sure there’s plenty of effective dev managers who still write code regularly, just hasn’t been my experience.
Sometimes the interests of the TL contradict the interests of the EM. Circumstances like those are usually brought on by strong budget or roadmap constraints.
Usually, people in your position will systematically wear one hat at the expense of the other, leading to long-term retention or code quality problems.
It's a delicate balancing act, that isn't easy for most people to pull off. It's not impossible, I've seen it done well. But it's a lot easier when "times are good", and you are not consistently tested by hard decisions where the EM and TL hats would disagree.
I don't doubt that it's possible. Except from having these creepy "one-on-ones" and review meetings, I have no idea what the engineering manager is even doing all day, never seen any transparency around this. "attending meetings" is what they say, but what meetings and why, I have no idea. Nothing is delivered and nothing comes out of it, I really think it's a bullshit job. "Sets tone, handles career growth, shielding the team" lol, do some coding instead.
One on one meetings are not "creepy" - they are a chance to have an open conversation about your goals; your concerns; and anything else that needs to be discussed about your career, the organization, etc.
Do you know what the sales people in your organization do? What about the legal department? Procurement? HR? Your lack of knowledge is not evidence.
"lol, do some coding instead"? And what should I code? How do you know what _you_ should be coding? Where does that work come from? Who makes sure that you're writing quality code and not some shit spaghetti mess? When the lawyers come knocking who answers the questions about security and compliance? You're just going to write some code for that?
Your myopic complaints do nothing to further your own goals - rather than make baseless accusations, look into the problems yourself and try to solve them. You might get some career growth out of it. At the very least you'll understand that not all problems can be solved with code.
I mean, I understand why 1:1 are considered necessary, but I still get the creepy vibe. It's probably mostly my introversion speaking, but this is honestly how I feel about it.
> conversation about your goals; your concerns; and anything else that needs to be discussed about your career
What goals exactly? We do sprint planning every spring, plus all that backlog refinement and other stuff.
Long-term goals? Well, they don't change that often (that's what "long-term" means). Neither does my career. So having this kind of debate once or twice a year would be quite enough.
The two people in the meeting decide it. I'm sure if either of them are creepy then you will end up with a creepy meeting. Otherwise it's just a professional meeting with an agenda and a desired outcome, like any other.
If you have no goals that's your failing, not the meeting's. If you lack the imagination to see where you want your career to go or the introspection to see where it's headed then, again, your fault - not the meeting.
Questions I get in my one on one's with people who care and are going places:
-Why is the organization failing at x/y/z? How can I make that better? Is it worth fixing?
-I am having trouble accomplishing e/f/g goal - I've hit q/r/s roadblock. What do you recommend I do about this?
-I want your job, how can I change what I am doing to get me closer to what you do?
I also use them to get information I need from these people:
-How is your team doing? Is anyone under/overvalued?
-Are your commitments on track?
-Is there anything I can do to make you or your team more effective?
I mostly have these meetings monthly. A month is long enough for things to change. 6 months is too long - too many things have changed, too many have been forgotten.
I feel the exact opposite, as a dev I don’t want to have to explain why my team’s work takes time, why we can’t do 50 things at once, and why we have to set priorities to the product teams or external stakeholders, I just want to write code. The engineering manager should enable the engineers to not have to get distracted by all the organizational chaos around them, their entire focus should be on developer productivity.
I've never seen any team where Senior Dev / Tech lead have had any power to make "arch level" decisions. And I have a very hard time imagining a team where the other junior/mid level engineers would accept to have such decisions made over their heads, by a member of the team.
Well, that’s how we do it. Senior devs make arch level decisions (how could you expect ownership otherwise?). It’s also not made over others’ heads but by involving them in the discussion, hearing their input.
I've been an engineering manager for a couple of years. I'm still expected to do 50% engineering and 50% people management. As the article describes, it is a struggle to do both well. I don't see this responsibility split changing in my current role. I do often wonder what it would be like to be 100% people focused, and whether or not I would miss engineering too much.
When my role first changed, I was very intimidated by doing one-on-ones. I never felt satisfied with the one-on-ones/catch-ups I had with the managers throughout my career, and I wanted to make sure I was doing a good job with that aspect of my role.
I initially did lots of research on how to do one-on-ones, but it was only after getting experience talking to people that I finally felt comfortable. I started getting some nice feedback from my lines, so I wrote some thoughts about how I like to do one-on-ones:
[link redacted]
I think good one-on-ones are very important to keep people happy and productive. I'd recommend any new engineering managers to spend time learning how to do them.
Regarding the advice in your link, how can an employee trust their manager when they're trying to get them to open up like a therapist, while at the same time gathering notes to use as "evidence" in an annual review? This is an inherent conflict of interests, and I've always regretted revealing any difficulties to managers. It usually comes back to bite me, as in "doesn't work well with others," or getting passed over for tech lead because I expressed doubts about my leadership abilities.
Speaking as another engineering manager, the advice in that link is pretty shallow. I think it encourages a rapport that feels efficient for the manager but is plain insubstantial for the report.
> I have found 30 minutes is the ideal length of time. Longer meetings tend to lead to us talking about normal day-to-day work, or going off topic altogether.
Compare this bit of advice to Andy Groves's, the former CEO of Intel and big evangelist of 1:1's:
> "I feel that a one-on-one should last an hour at minimum. Anything less, in my experience, tends to make the subordinate confine himself to simple things that can be handled quickly.” [1]
People need time to express themselves; to air their resentments, frustrations, disappointments, disillusionments. Cutting a report off before they can tell you what's really on their minds or in their hearts, does not seem like "quality 1:1 time" to me. Or at least not in the context of managing high performing knowledge workers.
It's kind of ridiculous for a company to 'expect' 50% engineering and 50% people management. It should be fluid and vary depending on the skill level of the team and the complexity and criticality of various projects over time. It shouldn't be fixed at 50% like some magic number.
Agree. For all but the smallest of teams, this just means being both a poor manager and a poor engineer.
Trying to balance this was one of my first mistakes as a manager. I was a roadblock to shipping things because of my limited coding bandwidth, and I wasn't spending enough time focusing on growing people, having career conversations, ensuring my org was structured for success, etc.
Finally putting down the keyboard was the key to me being a much better manager. Yes, I don't have the depth on every framework like I used to, but I still have over 15 years of hands-on-keyboard experience and the "engineering" part of "software engineering" is less about fluency in languages, but more about how to effectively set goals, mitigate impact of external dependencies, design for performance, etc. That knowledge is still very useful.
My hope is that those illustrate the 'spirit of the law' of taking both responsibilities equally serious. An issue is when middle management, so often comprised of literally minded number crunchers, interferes.
The agenda for one on ones should be driven by each direct report!
If your meetings are stale ask them to start setting the agenda. The time is for them, let them take the lead.
As a basic format, try 15minutes for them , 15minutes for you
The time for them should be whatever they want.
The time for you should be about directing them to what they should do next, understanding if they have roadblocks, giving feedback, identifying opportunities for coaching, and thinking about their long term progression.
Their concept is based on the idea that the key activities of all managers should be primarily focused on one on ones, feedback, coaching, and delegation.
If you do all 4 well then you will be able to grow your direct reports career and help them to better align their output with their career goals and also what the business needs them to deliver.
I'm also in the same boat but my split is 80/20 engineering/managing. It may be the product of whose on my team (many independent and senior level devs) but there are those who need more help/mentoring/etc.
Contrary to a lot of the other commenters, I feel like this team works but it may be a product of it being made up of these people rather than a broader generalization.
In about 90% of companies I’ve seen they expect you to do all the manager things and be an engineer too. It’s not so much a mistake individuals make as that it’s an explicit expectation that you’ll be wearing multiple hats.
Folks generally get bombarded to manager because there’s no career ladder and this is what people think they have to do next to be able to continue to grow. And once you become a manager it doesn’t suddenly create a head count to backfill the “loss” of an engineer so there is continued pressure on you to do both.
Once career ladders start to get better defined this starts to change too, and as the size of the company increases manager and IC responsibilities end up being different people. But companies seem to only figure this out at the 500-1000+ employee threshold.
Folks generally get bombarded to manager because there’s no career ladder
That's a pretty serious organizational flaw. At my employer, we have a well-define architect path that ends with "Technical Fellow" which on the job matrix is parallel with director-level management.
As a developer, I see 4 basic career tracks. Developer-track - caps out at principal developer, thought most people in this role are capable of architectural work within their product/tech-stack. Architect-track - high-level strategic technical decision making, caps out at Technical Fellow. Business-track - eventual move into a BA or Product Management role. Management-track - typically moves in scrum master or project management role, then into full-time personal management.
I started down the architect track, then hopped over to management because I wanted to challenge myself (at the time, leading people was WAY WAY WAY outside my comfort zone), not because I was forced into it due to lack of career growth.
I agree that "no career ladder" is a serious flaw. That said, it's not uncommon that, in terms of money anyway, IC tracks tend to cap out at lower levels than management tracks even if there is a well-defined IC track.
Yup. And it's not limited to software/tech. The local police department has the same problem with patrol/beat officers - many of the good ones were promoting into desk jobs because their salaries capped out. IIRC, they ended up creating a new tier of patrol roles on top that corresponded, income-wise, with the first or second level management.
> t's not uncommon that, in terms of money anyway, IC tracks tend to cap out at lower levels than management
This is pretty natural, at least in a big organization. At some point your IC tracks almost always have less impact. There are weird corner cases sure, but not enough that you can't deal with individually.
But that's ok; Almost every manager isn't going to eventually be C-level either. What's important is that there is some career track that makes sense for IC focused technical people to stay in throughout a normal career.
There are weird corner cases sure, but not enough that you can't deal with individually.
I think that's where a lot of organizations fail. Take the "Technical Fellow" I mentioned earlier. This is the "weird corner case" - a technical IC who is capable of contributing strategically but has no interest in management.
The people in this role generally have ~20 years in industry and most have advanced degrees. They're some of the smartest people I know. They have the people skills to manage, but little interest (or rather, prefer to stay purely technical). Without the technical fellow role, they would have likely moved into management after 10-15 years and moved into director positions, at a loss to the company. Or, they'd dead end as senior devs at a lower salary and not have a voice with senior management.
My employer has 3500 employees (across all BUs). There are fewer than 10 technical fellows.
That doesn't seem an unreasonable ratio. I was at an analyst meeting at IBM Research many years ago and one factoid I still remember is that IBM at the time had more general managers (i.e. a rather senior management position) than fellows; I think there were about 300 of the latter.
> And once you become a manager it doesn’t suddenly create a head count to backfill the “loss” of an engineer so there is continued pressure on you to do both.
That must be on the top of your “new engineering manager” TODO list.
It usually is. But the fact that it’s on the top of the list doesn’t mean there’s head count available. Most organisations do this through planning phases and depending on how often these happen it can be a while. Then add the time it actually takes to hire someone.
I did the exact same thing, I liked the idea of being able to code still.
And then three months in I took stock and I didn’t like what I saw. I wasn’t able to devote the time I needed to help people with career development and truly enable them to shine. I was also slowing my team down because the time I could spend in code and crucially code review was much lower. PRs languished and folks had to go in and fix things after me.
So I dropped the code bits, aside from really small code fixes here and there across our code base and focussed on doing the management thing. I was happier and so was my team.
In my experience the "mistakes" mentioned in the article are mostly a motivation problem. The assumption is that a successful engineering manager is one that makes their team thrive whereas in reality the companies only reward individual success. Same goes for developers, best developers only get junior->senior promotions while the ones that join the most meetings and do strategical thinking goes towards engineering management and leadership.
1. Still doing much technical work
If the technical work tackles an important bottleneck or solves an immediate internal problem for the company, this will be seen as incredibly valuable (even more so compared to the eng. manager were still a developer) as opposed to delegating it.
2. Not giving (enough) holistic feedback
In my experience, managers never evaluated based on how helpful they are to their teams. They only need to avoid negative feedback, which is not necessarily aligned with being honest and direct to their reports.
3. Doing all the project management
There's an urgent problem. Eng manager dives in, quickly fetches developers from teams and micro-project-manages them until the resolution and moves on. This is recognised as a success.
4. Not sharing enough information with the team
Sharing is good for the team members, not necessarily relevant or hurtful for the managers' success.
5. Not doing one-on-one coaching
Same as above, managers help their reports out of good will if they do but if they are evaluated on their help with delivery and not the health of their team, they do not have the motivation.
Thanks for bringing this up! This is all definitely true for way too many companies :/ One of the questions I ask when I think about switching companies as an engineering manager is: "How will you know if I'm doing a sh*tty job?" - you'd be surprised how few companies can give a proper answer to this.
If you, like the author of this article, spent 13 years as an IC, perhaps it is OK for you to focus on acquiring the soft skills required to be an efficient engineering manager.
After 13 years as an IC, you have a pretty good perspective on what it means to be an IC, how to identify valuable team members, how to assess their skills, how to identify blockers and facilitate solutions, and most importantly, how to classify technical problems, how to analyze requirements, how to plan, estimate, communicate on deliverables and releases, etc.
If you have the hard skills, it's fine to spend most of your effort growing your soft skills. But if you don't have the hard skills, you'll have to focus on that as well.
You can delegate things to different team members, but at the end of the day, the responsibility is still yours. Team members can "own" things, but you're still responsible if they don't execute. And in order to do that efficiently, you have to be prepared to ask the right questions to the right people, and that requires hard skills.
1. Growing in the 'soft skills' areas doesn't mean you should stop growing in engineering excellence - that's the problem
with one-sided articles like this (I am the author )
2. Super important point about that you don't delegate accountability!
I disagree about 'Still doing much technical work' being a problem. The author incorrectly infers that a manager writing code is going to take away developers' freedom. It's the opposite.
The way I manage developers is I design the system into small projects with separate concerns and which can be easily integrated together. With the participation of the team, we discuss and iterate over the design of interfaces between those components/projects.
Then when it comes time to implement, I assign 'ownership' of each project to a developer (with consultation with them). Then with the exception of a few basic guidelines, they can implement it however they want. We just do regular peer reviews of each other's work. We tolerate code style variations between different projects but each project must be internally consistent.
So far all our projects never needed more than 2 people to implement (each one having 1 developer as the project owner). At the end, we integrate maybe 10 different projects into the final working product (which gets its own repo).
This approach to development is extremely fast and robust (very few bugs which are easily caught and fixed). We don't even need special tools or programming languages. We just use plain JavaScript; never had the need to use TypeScript, the code is very easy to follow so it's not a problem.
All you need is to have small projects with clear separation of concerns. The trick is to not invent new abstractions; all technical abstractions should come from the specification and be understood by non-technical people. Also all components/projects should have simple interfaces between each other (only basic types that can easily be serialized into a JSON string). Different projects/components should never pass 'live instances' to each other; that would indicate poor separation of concerns.
I always held the opinion the "perfect" leader would be a hybrid of leading + devving, flexible enough to switch to 100% leading if need be, yet perfectly capable of picking up any technical work required, therefore never landing in the above situation out of inability.
I've never seen the problem "we don't have enough management capacity". On the other hand, I've seen plenty of non-/low-technical people become engineer managers, flailing their arms when there is too much work and not enough time. Only making the situation worse by stressing everyone out and taking up additional time in communication.
Those are the same problems. Managers flailing when there is too much work and not enough time means that there is not enough management capacity.
Not often called out because the short term effects of managers not existing are minimal, where as without engineers work stops. Long term without managers work continues but the value tends toward zero.
Frankly, personal anecdotes disagree. I don't need managers breathing down my neck because they aren't capable of resolving the issue, and end up overcommunicating with the customers, reinforcing behavior in customers to continuously ask for information instead of realizing the harm they are doing. "Two days" means "two days", no matter how many times you ask for a progress update or try to push it to one day.
Quality managers doing more than shoving boxes, that's a different story. We are definitely lacking high quality management capacity actually capable of preventing these situations from happening in the first place. I'd argue an overcapacity of managers actually actively prevents healthy relationships and usage of developers. People who aren't capable of doing anything useful in the moment, get antsy. It is a lot easier to get antsy as a manager than it is as a developer with an endless backlog.
That's also one of my arguments against full time managers. Management work is actually pretty rare, and full time managers tend to inflate it as to not twiddle their thumbs. As we move towards more "self-managing" practices (actual self-managing), total FTE of managers required drops significantly. It makes more sense to hybridize the role, so they keep an affinity with technology, than to put them on the "people manager" path which makes them rapidly lose their connection with technology and will quickly makes them stub their toe against Dunbar's Number. That's before considering tech will rapidly take away most of management's routine work. Their most important responsibilities don't take the majority of their time.
This is, in my opinion and experience, the main gist of the problem. Management work doesn't take full time and people get bored or scared they can lose their jobs if someone finds they didn't do much. So you end up with a lot of synch meetings, one-on-one's, backlog refinement meetings, weekly reviews etc.
And now most of the managers have a calendar full of meetings to coordinate projects with other managers that after that they meet with their teams to get feedback/answers they need to go back to the project meeting and tell other managers that tell their teams... If they were not managers but developers or engineers with technical knowledge, they would save a ton of time (and team's time) and solve most of the issues in a couple of sessions.
But most managers will disagree because they cannot see how the "difficult technical problems they helped solving" were not so complex in the first place... when you put together the people who knows about the code/projects/systems.
This is the winner right here, this is the manager who will get the most things done and deliver the most business value. This team would run in circles around a whole department of snowflakes. Focusing on being efficient at getting the actual job done, not wasting time on bullshit like figuring out how to have the perfect "one-on-one" to "make people happy". People on a team like this will be happy because they have a high level of purpose, craftmanship and impact.
I wouldn’t want to work for you, since it sounds like I would be put into a small box where I would have limited value and potential for growth. The only way to produce more value is to finish my projects faster. No thanks.
Well it's likely I wouldn't want to hire or sponsor you either because you seem to jump to conclusions and make incorrect assumptions.
The projects I manage are open source, I pay in crypto (which has been going up in price so my team is earning more over time) and I pay based on value added (small base sponsorship amount <essentially a monthly retainer> + generous bonuses at the end of each month based on delivered value) not lines of code or hours worked. I don't expect people to be fast, I never rush anyone. People can come and go whenever they want, all remote. They can change projects after they finished their current project (a clean working state). If they want to work multiple projects in parallel they can do this too if they have the capacity. As I said, projects are limited in scope so they get finished quickly, usually a few weeks to a month or so so people can still move around and tackle progressively more difficult projects.
I suspect that devs complete projects quickly because we have good separation of concerns and developers have a sense of ownership and independence. To top if off, we let developers work for other companies if they want to - At least one of them does and he creates more value for us than in his other company, in less time. We probably pay him more too thanks to increase in crypto prices... In fact he says he wants to quit the other company. He just liked to have it as a backup because we don't pay predictable income but it's getting high enough that he feels that he can take a chance.
I wasn't convinced of the gp commenter's sentiment about you being a less-than-ideal boss to work with but it seems you proved his/her point.
Not sure whether you actually understand the issue raised by him/her -- the process of defining, designing and architecting a solution is very much something that an junior engineer would aspire to be able to take responsibility for one day. But under your working model, only one person (you) would be mainly responsible for doing that, and other people could only prove their worth by doing their piecemeal work (the small and isolated "projects") faster.
Not saying that this is actually true, and from your original comment it seems that it might not be completely true, but that's what the the gp commenter wanted to say. And you seem to confirm it in this comment -- you praise people who work fast but haven't seen you mention about their code quality or "taste" in architecture or design.
... and I haven't mentioned the retaliatory vitriol. Seriously, talk about jumping to conclusions...
Personally, I would wonder how you assess "delivered value", given that this is basically one of the hardest problems to solve involving questions about asthetics, ethics, business management, leadership, capitalism and even the worth of a person's time... but I'd jump to my own conclusions and will assume you think you have figured it all out :)
When you code all the time for over a decade, you know what good code looks like. When you care about the product, you know what a well implemented feature looks like from the user's perspective. So it's easy to approximate value from these two aspects.
The people who work with me learn a lot about architecture because I explain everything. I only had 1 manager who had a similar style as me in my own career as a developer (out of over a dozen) and I wish I would have had more of them or that I could have worked for them longer.
You're assuming things because you've probably never seen a good manager in your life. It's difficult to imagine something better than the best you've known.
To put it more concretely, how many people have you been able to promote into a role like yours where they are defining the architecture, in the last 5 years?
For simpler projects (like simple front end applications), I usually let developers decide the architecture themselves (I mostly just offer advice).
Since in those cases, architecture is not as critical.
I was myself overlooked for promotions for over 5 years (in spite of constantly asking for one).
I was better qualified than my managers to be making architectural decisions but they only realized this after I left (since I started a competing project).
So I know how it feels to not be given the chance. I even know what it feels like to have an incompetent person promoted as my boss.
That said, it doesn't make sense to put someone 100% in charge of architecture if they don't yet have the necessary skills.
Some systems are extremely complex and easy to mess up architecturally so I wouldn't hand off this responsibility unless I knew that the next person would do it properly.
I was an engineering manager for 25 years. I could say lots on the topic, but my dance card is pretty full, right now.
It's a nice read. There's a ton of other pitfalls (both for newer and more experienced managers). I gave a quick shortlist in a comment on an earlier thread[0].
The author has a number of articles in a similar vein. I think they are pretty good[1].
This sounds like the kind of role a lot of good engineers get promoted to unwillingly/unknowingly, how do you avoid being assigned this role and remain a valued engineer once you have experience?
> how do you avoid being assigned this role and remain a valued engineer once you have experience?
Change company.
If the only progression for an engineer is to become a manager, change company to one that allows an engineer to continue growing, continue learning, and continue to earn more.
Some signs a company will force you to become a manager to progress:
1. Artificial ceilings: "We have Principal and Staff Engineers, but those are defined as having had impact outside the company so you cannot become one as your work only has impact internally" - effectively these titles are only offered to strategic hires and it's not attainable from inside the company
2. Managers paid more than the top engineers.
3. Title inflation as this stifles actual growth and learning and tends to limit overall earnings forcing you to look to change your career to find new challenges and earnings even though you want to be an IC and continue to do engineering.
Unless a company truly has a clear progression for ICs with learning, growth and earnings all factored in, and that the IC progression goes all the way to near the top of the company, and it's achievable within the company... then you're going to reach the point that you'll look at the manager career and think it's the only way forward. It isn't, and it's not even forward it's to the side and backwards a bit (you reset your career and start at the lowest level of a new track).
If you can't progress as an engineer and wish to... change company.
This is basically what I did. I ended up trapped in a half-management-but-no-real-authority-but-also-we-need-you-as-an-engineer role. It's an easy place to accidentally find yourself when the managers above you aren't technical enough to manage engineers effectively. All my previous jobs were in smaller companies where this tends to be the norm.
It has been incredibly freeing to work at GitLab where there is an engineering career path and no pressure to move into management. I don't think I'm a bad manager, but I don't enjoy it as much as engineering, and it's nice to just be able to do what I'm good at.
The ranges overlap: an early career engineer will definitely be paid less than an early career manager... but a top engineer should be able to earn more than the vast majority (if not all) of the managers.
Not true. The idea that an IC is going to out contribute a top manager who oversees dozens of lower tier ICs doesn't make a whole lot of sense.
A good manager is a productivity multiplier which is why the top companies spend an arm and leg training up their managers.
The real issue is that is much easier to manage a group of top engineers than it is to manage a group of engineers who think that they are top engineers.
And this is the perfect example of why so many companies are doing it wrong. Managers that truly believe they are the ones pulling the weight and making projects possible (without any mention to technology and eng. knowledge) and if not, it is because the engineers are over their minds and you have to micromanage them.
And because managers tend to be the ones proposing promotions or career upgrades, they reproduce this mindset by selection bias.
The point mentioned in some comment above about changing company if you feel forced to move to management has been proved by this comment. If you see this behaviour in management, no matter if you want to continue your IC career or move to management, run. Find a better place.
Good individual contributors are also productivity multipliers. There's nothing specific about managers that makes this trait specific to them.
Also, using salary to force engineers into becoming managers is a good recipe for losing good engineers. Either because they become managers or because they leave.
Yup, that's a common career path mistake companies do - making the only possible 'next step' for senior engineers to become managers. If your company doesn't have a strong career path for senior ICs, you should push for one
Honest question -- why does there need to be a "next step?"
It's been over a decade since I've worked at a company with managers. However, it was common for the top programmers to make more money than their managers there.
It's been over a decade since I've worked at a company with managers. However, it was common for the top programmers to make more money than their managers there.
Programming and managing are completely different jobs that accomplish different things for the organisation, but they are typically arranged in a top-down fashion, the manager has power over the programmer. A manager's job is to do the function of interacting with the wider organisation in order to determine the best way for the programmer to spend his time, in effect it's a research job, then he presents the programmer with the results of his research and they both agree that the most value can be added to the organisation by working on bug X today instead of feature Y. But what actually happens is the manager says "do this, because I said so, and if you don't I'll block your next raise". Or so-called engineering managers cherry-pick the most rewarding work for themselves and assign the unfulfilling work to subordinates as punishment. That's deeply dysfunctional but it's what happens when you have a group who wants to do real work, and another group who has plenty of time on their hands for full-time politicking.
here are companies where managers are truly in a supporting function. I'm not here to advertise but my last two jobs were like that
Unless programmers have equal knowledge of and input into their managers salary as their manager does in their's, there's still that fundamental top-down structure.
I agree. I work in a matrixed consulting organization. I have a "People Lead" who guides my career development, and I'm handed off onto projects to "Project Leads" who guide the day to day. And I use the word guide intentionally. When I'm staffed to a project, my role as a project member is to look for the project lead for finance and schedule and PM direction, and maybe to a principal consultant if there is one to guide technical direction, but I'm an IC and expected to do my work. My People lead solicits feedback from those I work with, the project leads etc. But is disconnected from my day to day, so there's no feeling of power, just a willingness to help me with my goals.
I am doubtful. If the managers are writing the performance reviews, they are not in a supporting function at all. They are the arbiters of the subordinate's success in the company and that is a vertical relationship.
The need comes from the folks feeling stuck - it doesn't "have" to be that way.
I've also had engineers making more money than me and looking at their impact it was well justified - the question is not only money but the sense of growth and acknowledgement of growth from the company's side - and there's a clear need for that. A bigger salary is just one (pretty volatile) form of it.
The problem is when it comes time to choose a direction, its gonna be you vs the person with N direct reports who can make it happen. I've seen companies give up on this and turn principles into directors - that hasn't worked out well either. It seems to be a pretty bad problem with the standard hierarchical way businesses are set up.
I've heard Goog does a bit better with a bit more autonomy so people can gravitate towards good ideas, but have also heard plenty of downsides. Maybe a new way to structure employees could come about?
Say “no” when offered the role, if you don’t want it :)
Keep the Peter principle in mind always and recognize when a promotion would actually “diminish your value to the organization” - that’s a great way to sell it so you’re not seen as just passing on the offer.
My company bifurcates people managers and ICs in engineering roles. Each level has both starting at tech lead/manager. Next is principal/director. Even VP has two tracks, though I have met only one IC VP. SVP and up are always people managers. AFAIK comp is the same. I help my senior engineers and leads understand their preferences and hit the path they want.
Negotiate, I guess; on the one side as a good engineer you want the recognition (and pay) that goes with it, so for yourself you should ask for a raise or promotion to a title like idk, "senior principal engineer". But for the leadership skills, you should push to hire a dedicated manager type, who works alongside you and does the people management part.
Nice read. I can also strongly recommend Rands (Michael Lopp) who has a great blog https://randsinrepose.com/ and wrote "Managing Humans" - an amazing book on the subject
Something I think that's often overlooked is your relationship with your peers after the transition from "peer" to "manager".
It's tough because you want to continue to treat your direct reports as peers, but that only makes it extremely awkward for them since the relationship dynamic has changed.
I agree very much, I hate when managers try to pretend to be your peer when that's clearly not the nature of the relationship. It's actually a huge pet peeve of mine: managers who always want to put their own modern twist on being a manager. Like I'm your boss, but actually I don't like to make decisions and I'm also a cool guy who's just your friend. They try to avoid the negative stereotype of the manager, but just end up not doing their job and leaving people confused, and making for a very awkward environment.
I was in that role nearly two decades ago and can confirm it's spot on.
Would add that you also need enough self confidence to stand your ground in discussions with upper management: this affects the outcomes on some points made in the article. Also, one should pretty much ignore unsolicited input/help from non-stakeholders in the project.
In the one I was, architects were siloed off from the projects in a parallel sub-unit in the department, making it a bit of an ivory tower. They would issue design and scope decrees without facing any schedule pressures themselves. It took me a while to realize that most of my managing peers were quietly* ignoring them, delegating the actual decisions to the team.
(*) As in, amend them to a workable design through a few status updates rather than making a stand-off in the initial meeting.
The Magician of the Ivory Tower brought his latest invention for the master programmer to examine. The magician wheeled a large black box into the master’s office while the master waited in silence.
“This is an integrated, distributed, general‐purpose workstation,” began the magician, “ergonomically designed with a proprietary operating system, sixth generation languages, and multiple state‐of‐the‐art user interfaces. It took my assistants several hundred man years to construct. Is it not amazing?”
The master raised his eyebrows slightly. “It is indeed amazing,” he said.
“Corporate Headquarters has commanded,” continued the magician, “that everyone use this workstation as a platform for new programs. Do you agree to this?”
“Certainly,” replied the master, “I will have it transported to the data center immediately!” And the magician returned to his tower, well pleased.
Several days later, a novice wandered into the office of the master programmer and said, “I cannot find the listing for my new program. Do you know where it might be?”
“Yes,” replied the master, “the listings are stacked on the platform in the data center.”
— The Tao of Programming, chapter 7.3 (Geoffrey James, 1987)
A situation like this can backfire quickly though. If the project fails or a setback occurs, the architects can quickly say that the engineers weren't following the original design and specifications.
Sure, but here lies the importance of my point: you get to be responsible either way, but at least you get to make your own call. If you turn that around and fail to deliver "because architects overdesigned it" everyone is going to give 0 f*cks - it's still your fault.
Yup, a tough call to make for sure and certainly grey areas with no clear path. When things fail, folks are quick to pass the buck and it's best to have as much recourse in your back pocket as possible. Don't give yourself a bigger mountain to climb so to speak.
Yes, this is situational. As mentioned it was a recurring pattern so a dysfunction peculiar to that particular org.
What happens is that many non-coding architects (sorry folks, not all of you but plenty enough) are essentially junior developers with little experience who negotiated themselves into these positions. Which is not that a big deal if they feel themselves part of the team and are grounded in the situation and open minded about debate. But unrestrained they build Daedalus wings and in the end it's you who get to do the falling.
You as a manager with engineering background have better comprehension of your team, with its strengths and weaknesses. You navigate the project leveraging the former and avoiding the latter, and if third party (neither the customer requirements nor your team) starts meddling it's not going to end well.
I don't care about any of these points, and I especially dislike one-on-ones. I just want my manager to do one thing: make decisions. To resolve conflicts, and make sure discussions wrap up and reach conclusions.
I would agree with that. But the problem (already mentioned) is: how could a manager help you grow in the technical field if the manager is out of touch with it and didn't do coding or dev work for years?
In any case, if I have to choose (and more times than not I wished I could) I would choose the option of the first comment.
> Focusing on your team’s health and growth will pay much higher dividends than still being half an engineer.
This logic is completely flawed as it assumes that the manager has reached a point in their career when they have nothing else to teach and nothing else to learn about coding.
I'm an excellent coder and manager but I'm still learning all the time, even after 15 years. My team greatly benefits from me still being in touch with the code. Also, it helps me to make stronger arguments about why we should avoid using certain tools or blindly following hype.
The best engineering managers I've ever had were coding alongside the developers. The worst ones were not. This point about "Still doing much technical work" being a problem could not be further from the truth.
Counter point: There's a lot of delusional engineering managers that say they want to be "hands-on", but that's not in the best interest of the team. They are either not top notch coders, or they can't juggle all the work. What they're doing is being selfish, because they don't want to be a manager, they want power and money. They need to grow up and do what they signed up for.
Just wondering, is job hopping as engineering manager as easy as coder/individual contributor?
It seems like the market for people with focus on soft skills is way more saturated (we get many more applications for project management roles than for software developers for example).
Project management is a pretty saturated field, you are correct. Engineering team management is considerably less saturated and EMs are just as in-demand as ICs.
However, much of the value of a good EM is derived as someone who builds and grows a team over a long period of time, so you don't see nearly as much short-term job hopping as you do with ICs.
+1
Author here: the other thing is (at least for me) that it becomes really hard to leave my team after a while because they just grow on me. I feel responsible for their wellbeing and want to make sure they are set up for success. When I was an IC it was much easier (in my head).
I've come to realize that the promise of a 50/50 split between technical work and management after getting promoted to a data science technical lead manager is not something that is feasible within my org. Unfortunately, I'm at an organization in which the only way up is for ICs to move to management. So I'm leaving to another company that has much more runway for IC career progression.
I've got a great relationship with my current employer, so I've mentioned this career progression issue to them in my exit interview and it's something that middle management is tracking, but getting corporate leadership on board to change their thinking is difficult since our revenue is driven by billable work on a man hour basis. This creates an incentive for people to build teams of direct reports under them and grow a business line/contract to increase revenue in order to show value and accelerate career growth.
Until the company can get more service contracts where they're selling software/licenses/support instead of butts in seats, I don't see this paradigm changing any time soon.
Very interesting how business models drive things like this. Obvious in hindsight, but still interesting to think about in terms of incentives driving org structure.
I used to manage teams and missed engineering too much, so I quit to be a freelance engineering consultant. It felt like the best way to progress as an IC for me.
Bigger tech companies do a better job of IC career paths than others, but it still feels like your influence is muted compared to managers.
As a new eng manager with about a year under my belt, #1 really hits the nail on the head. I couldn’t step away from the code because I was so used to IC.
Now as a result, I’m having very difficult discussions about promotions (or lack thereof), because I didn’t give my team the chance to grow.
This sounds like it's not too late to turn the ship around. It's also tricky, for some folks it's enough to see space for growth and they do it automagically, for others you need lots of conversations and gentle nudging. Don't be too hard on yourself, just start fruitful career discussions with your team.
Not "letting go" to be a manager, which turns them into a micromanager. I got stuck under a brand new Engineering Manager in what is effectively his old role during the last reshuffle, and he still has to be intimately involved in every aspect of every project because it was his job. Every minor decision goes through him and I don't think I've attended a meeting in over a year where he wasn't part of it.
Between other issues with #3 and #4 it's a nightmare. I've been bringing up these issues for most of that time (it's gone from diplomatic to brutally honest over the last few months) and nothing changes.
Thankfully the job market is starting to rebound after tanking during early Covid.
The single biggest mistake I see new managers make consistently is not training your self awareness and being retrospective.
Everybody makes mistakes. The trouble is if you are not on the lookout to identify, correct and learn from them.
In my opinion, every other advice is secondary as it can only work if you are honest with yourself and wanting to apply it to improve your work.
No advice will help if you think you are better than everybody else and you attribute all your failures to other people letting you down or working against you.
> there’s the concept of the ‘tech lead manager’ which is supposed to be 50% programming and 50% people management – in my experience it doesn’t work well in the long run
I discovered this organically as I grew into an engineering manager role that lasted about 8 years. Software companies in the US though expect the opposite to the point where I found it better to return to an individual contributor role and am now wondering how my own truths about the role can be so different from the norm...
I think those 2 words should not be in one title. Recipe for hot mess. Choose One and stick to it. I am not sure what kind of mentality to mix both. There are not compatible positions. Cost of context switching is not cheap.
It's absolutely unreasonable and unrealistic to be an engineering manager and a technical lead. Management is a full-time job consumed mostly by minutia and bureaucracy (mandatory meetings and paperwork) so that the team doesn't have to deal with it.
I'd add:
6. Defend the team, especially pushback unreasonable, untenable changes from on high.
7. Peter principle: title doesn't assure greater competency. Don't micromanage experts. Seek their knowledge, opinions, be curious, and ask questions.
8. Go-giver and mentor. Always help staff grow their careers, confidence, and capabilities, wherever that takes them.
9. Be helpful to the team and its individuals without being annoying. Replace that crap printer that wastes everyone's time. Fix that door that maintenance ignores. Whatever it takes. Go above and beyond, especially when it's crunch time.
2. Stop coding
3. Do well for a few years until you become out of touch
4. Watch your team stop respecting you on technical subjects because you’re behind the times and too rusty but don’t know it so look foolish and are ignored when you give suggestions, which radically undermines your relationships with them as well as your ability to lead
5. Watch as your role morphs from a manager with chops and respect into a PHB, unless you happen to have been born with natural leadership skills (you probably haven’t)
6. Realize you are now just a mediocre manager who can no longer return to the engineering track since you cannot compete with other candidates
7. Drag yourself to retirement by slogging through life as a relatively poor middle manager