Common Mistakes of New Engineering Managers
ochronus.online
ochronus.online
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
1. Do not become an engineering manager.
2. If pushed (e.g. by not getting raises), move on.
move on to where? managers get paid more than IC on average everywhere.
Sure, if you are staff level stellar IC you might get paid on par with management but most ppl aren't.
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.
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.
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.
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.
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....
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?
I didn’t write this article, but it sums up my headspace, currently: https://www.linkedin.com/pulse/stop-doing-more-less-2019-mat...
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.
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.
- 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
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.
Edit: Just to clarify, the question in my post is kind of directed to my manager and not to parent commenter :)
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.
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.
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.
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.
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.
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.
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.
Then you're a technical lead and a technical manager; don't conflate the two as the only possible configuration.
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.
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.
I guess we could recast the term "technical manager" as "one who attempts to both do and manage."
„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.
If you’re in sanitation, you have a more nuanced relationship with trash than those who aren’t, even though everyone dislikes trash.
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.
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.
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.
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.
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.
If people are born as leaders, how come world history is full of bad kings/emperors?
So most don't make it, and those who do have a tremendous career that's fulfilling and financially rewarding.
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
There is some confounding in this thread of manager-of-people roles and manager-of-things roles, which also causes confusion.
(but yes)
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 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.
- 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.
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.
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)
Dev2: Same as above, different specialty
QA: Half-time dedicated QA resource
UI/UX Designer: 33-50% time for team.
Project Manager: Half-time dedicated resource. Owns Jira, scrum master etc as noted above.
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.
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.
You may be doing it extremely well! It does happen. But I can understand why you're getting skepticism.
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.
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.
Actually, who decides this, and how?
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.
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.
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 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.
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.
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.
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.
Eng Manager <- Devs, Project Manager
Product manager -- UI/UX (same org not direct reports)
QA (Had their own reporting structure)
'Eight?' - Bob
'Eight Bob' - Peter
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.
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.
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.
In the span of two years, my ability to even review code and spot simple mistakes has rotted (I’ve coded for many years; I was pretty good at it).
Meanwhile my team size has doubled, and I’m left feeling I’ve bitten off more than I can chew.
These days I feel I’ve made a mistake. Even one-on-ones feel rote.
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.
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.
> 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.
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.
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.
That must be on the top of your “new engineering manager” TODO list.
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.
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.
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.
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.
I hope it works out for you though!
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.
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!
Thanks for sharing!
People with good technical background could be both bad and good.
Never seen it abbreviated before.
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.
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.
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.
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.
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.
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 :)
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.
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.
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].
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.
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'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?
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.
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.
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.
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.
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.
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.
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.
https://randsinrepose.com/welcome-to-rands-leadership-slack/
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.
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.
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.
“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)
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.
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.
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.
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.
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.
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.
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...
Or anything from him, really.
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.