The biggest thing most managers give up is their mind.
You start using corporate jargon. You become more authoritarian. You embrace careerism (a term I invented to describe people who erroneously conflate rising in corporate rank with happiness). You quickly learn that no one understands anything about the people or the business--and that all decisions are made by gut, cherry picked data, and story-telling. Suddenly, you'll be afraid to disagree.
Your only job as a manager is to protect and develop the team under you. You must actually like people and have a fundamentally benevolent worldview. You must be willing to say "I don't know" 10x more than as an IC. You must believe deep down in your core that ordering a human being to do something is a sign you must introspect about your failure as a manager, and commit to fixing the problem.
You must be prepared to tell your own manager to go kick rocks. Ambiguous situations are one thing, but you must never, ever knowingly do the the wrong thing. Everyone will know when you do it, and that will be the beginning of the end of your own happiness.
All other approaches will lead to you failing to deliver results, failing to retain, and a drag on the org.
The error I have seen most engineers-turn-manager make is they had a deep dissatisfaction with other terrible managers, so now its their chance to make the right decisions and do things their way.
As an IC, I’ve had about 8 managers in my day. Sadly, I failed to recognize and appreciate great managers due to my own lack of maturity at the time and not understanding the manager role.
Earlier in my career, I had a manager who I initially had pegged as disengaged - he wasn’t, he was just actually delegating and managing without getting bogged down in the IC work he entrusted to his reports. At the time I thought this was not helpful as he couldn’t help me much with my direct tasks, and I had been on the team well before he joined so he would ask more questions to be answered by me than I of him. Frequently in our 1:1s I would not even know what to talk about.
But looking back, I realized I was asking the wrong questions, and he the right ones. He carved out a lot of scope and big projects for me (and others) which greatly advanced my career. He was bullshit shielding and setting up new projects so well that I didn’t realize how good he was at that until he was gone. In his focus time he was prototyping useful but not-critical-path tooling to make us all more productive. I almost want to cry thinking about how critical of him I was (never shared, but sometimes reflected implicitly with how I phrased questions) at the time. Nobody is perfect and I think he did try to communicate, but very vaguely and circuitously in a way I didn’t understand, how he saw his role by telling me an analogy along the lines of him being more of a <well known delegative leader> than a <well known teaching/apprenticeship leader>.
To add to your list, I’d say expect reports to not understand or appreciate what you are doing for them. Maybe it’d help to make it a bit apparent now and then in a way that doesn’t flex the inherent power balance - probably better to show some of the bullshit averted than “look at what I wrote to get you promoted”. Or maybe it’d be good to directly share something like your comment to say “Hey, I’m on your side, and please let me know if you need cover for some incoming BS or want to try something with more scope - I’ll try my best even if I don’t have all our code’s class hierarchies memorized.” Because immature reports like my former self may not realize that a good manager works by entrusting reports and delegating decisions (with some consensus building) if they haven’t encountered that yet.
> I almost want to cry thinking about how critical of him I was (never shared, but sometimes reflected implicitly with how I phrased questions) at the time.
Reach out and tell him that. I'm sure he'd appreciate it.
> Your only job as a manager is to protect and develop the team under you.
That sounds like the philosophy of a tumor. Clearly, a manager has to care about other things as well, such as - how can my team contribute to the business in the most valuable way?
A manager should have a view about the business, and they must work to give their team the evidence and method of thinking to grasp why that view is correct. Only then will the team properly focus on the goal and execute effectively. This is part of developing the team.
"If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea." -Antoine de Saint-Exupery
From what I've seen, the biggest role of a manager is interfacing with other parts of the business (i.e. other managers) and actually coming up with what the team should be working on, and how it will fit with what other parts of the business (i.e. teams managed by the other managers) are working on. This is the hard part - it's so easy to just go and build the wrong thing for a couple of years. Managing the internals and the actual work of the team are, in comparison, relatively straightforward part of the job.
FWIW, I've been told I'm an exceptionally effective cross-functional communicator and that I outperform given my ability leverage my resources to recruit and align support for initiatives across orgs.
Imagine how wealthy our society would be if all the claims of by all managers about management success were actually true.
So far as I can tell, nearly all inter-management communication is useless and has, at best, zero impact. Only at the extreme margins or with select relationships does anything useful result. Like you find the IC SME who actually understand the target market, who is willing to sit with your team to set a vision.
Otherwise, nearly all managers you interact with are careerist.
> If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.
And yet, actual shipbuilding operations look, and have historically looked, much more like the former than the latter.
Probably because the first thing that group of yearning men will do is organize the work, and select someone who will be in charge of making sure everybody is in sync.
And boom! That someone is a manager.
To do otherwise ensures that if the ship gets built at all, it will sink in short order.
Wouldn't they then just leave to become sailers? I build account software. If I yearned for the tax laws, I'd stop being a programmer, and start being an accountant.
I think the parent is suggesting that protecting and developing the team is the only important task for a manager that doesn't fail at being a decent human.
The frequent incompatibility between morality and business, even down to simply shipping a shitty product to release at all, right up to building products that are designed to force purchasers to buy a replacement, is a matter that leaders must weigh.
A similar issue also applies to the people they lead. The line of professional detachment, between being too friendly and too military, is very thin indeed.
Generally speaking, while I fully agree with the parent that protecting, developing and coaching team is of paramount importance, I would say that, at the very least, hiring is equally important.
Hire the right people and your job as a manager is the easiest thing in the world.
Of course, in order to be good at any of the above, you must have a solid understanding of the business. It isn't simply a matter of being the people's champion.
I came to appreciate leetcode as a job seeker. Still don't think it is a great signal for HMs, but for the candidate it is a lot stressful than whiteboard coding.
Most problems solutions are a variation of small set of algorithmic techniques and you learn fast to identify the gotchas in the usually terribly edited problem descriptions.
Once you incorporate practicing coding tests in your life routine, they become an enjoyable passtime and a good substitute for mindless scrolling.
Nah.. I've rejected roles right after getting a leetcode link. Called a recruiter one time while on the bus, just looking at the link. Told her not to bother. I didn't want to work with anyone who would send such a link.
The called me back and said sorry, and I interviewed with their dev manager.
Most managers I've worked with haven't been shy about saying this. It's usually followed by "...but try asking <x>" or "Let me find out and get back to you".
To be honest, if anyone, in any role, never says "I don't know", I begin to question their abilities.
I worked for 5 years at an American company in Australia and I heard this multiple times per day from my US colleagues - my conclusion after heard it said to the most basic questions was that it’s mostly a filler phrase used to buy time while the respondent thinks up an answer.
Not super relevant but I’ve noticed recently that when I ask someone a question, they start their answer with the word “absolutely” even though the question was not a yes or no question.
Is this a time-filler like “that’s a great question” for extreme people pleasers? Or just an agreeability signal? To me it makes the answerer seem overeager to share. It could just be regional culture.
Depends heavily on how it's said. If it's flat with no derivation from the previous sentences intonation, it is probably filler. If it intentionally stands out, it is probably not.
Personally, I use the phrase often as a Senior IC in a way that makes it clear it t is not filler. I also use phrases such as, "Hell if I know, let's google it and find out together."
Yeah, if anything, managers bluff and pretend to know significantly more often then engineers. And those who don't, gets removed or are seen as less capable by those over them.
It seems like you're a manager, but how do these two sentiments go together:
> You must be willing to say "I don't know" 10x more than as an IC
> All other approaches will lead to you failing to deliver results, failing to retain, and a drag on the org.
Your advice is contradictory on its face. How can you embrace "not knowing" and having a curious mind, while at the same time declaring that this set of operational activities are "the only way to do it"?
> You must believe deep down in your core that ordering a human being to do something is a sign you must introspect about your failure as a manager, and commit to fixing the problem.
This also just seems like new-age guilt injected into the work place. Don't be a micro manager always in people's faces for no reason but if you're telling yourself you're a failure because _as a manager_ you told someone to do something, I'm not sure how you last more than 2 days on the job.
>> You must believe deep down in your core that ordering a human being to do something is a sign you must introspect about your failure as a manager, and commit to fixing the problem.
>This also just seems like new-age guilt injected into the work place. Don't be a micro manager always in people's faces for no reason but if you're telling yourself you're a failure because _as a manager_ you told someone to do something, I'm not sure how you last more than 2 days on the job.
I don't know. As a parent it's something I do all the time. My aim is very much to lead my kid and I absolutely hate being authoritarian. So whenever I do find myself being so, I try to introspect (not very successfully for the most part) and find a better solution.
Seriously, no knows anything about parenting. Properly considered, it is the most difficult and intellectually challenging task conceivable.
“Here, take this tabula rasa child and, over the course of many years, with virtually no timely feedback about the impact of any of your actions, raise a fully formed rational adult capable of effectively dealing with the problem of human survival on a planet incredibly hostile to life.”
Most children grow up to be decent human beings despite parents having no clue. I don't think you can do much for them, they do it all by themselves... just don't destroy them by being a horrible person and treat them with respect, even knowing you have all the power in the relationship.
You must be a merciless judge of what you hold has knowledge (that is, have certainty beyond a reasonable doubt). Misstating as a manager is vastly more damaging than as an IC. Even if you know something, it is often valuable to defer to your team for the answer.
Giving direction and context is different from giving orders.
After being drafted into Engineering Management from 3 IC roles in a row, I decided to jump in with enthusiasm. My primary motivation is that I've had bad engineering managers and a couple of great ones and I want to be like the great ones.
Along the way I have studied a lot about how to manage people in a positive way. I learned coaching and that has helped me help others grow in their career which I find very rewarding!
As an engineering leader I have 2 primary goals: 1. Enable the team to deliver top quality work. 2. Do everything I can to make this a great place to be a software engineer. I filter every decision I make with these goals. If doesn't move us closer to both of them then its probably not the right decision.
I do miss full time coding but I have hobby projects and I do monthly games and challenges with the team with the goal of all of us having fun while learning something useful and/or interesting.
Honestly, it's a completely different job as an Engineering Manager vs being an IC. What you give up is replaced by what you gain. If you like helping people be their best and achieve big things, it can be very rewarding.
> Honestly, it's a completely different job as an Engineering Manager vs being an IC
This is the right perspective, in my opinion. The way I think of it is that its more like you are the coach/manager of a sports team and not a player. Sometimes the best players do not make good coaches and sometimes players that are mediocre/bad are really great coaches/managers. Its a different role. If you approach it with the mindset that your role as coach/manager is to help your team's outcomes be the highest they can be (which will differ based on the make-up of your team) then you (and your team and your company) will do well.
In business/management terms this is called servant leadership - serving others to help them grow and succeed. Traditional leadership is typically the accumulation and exercising of power to "move up" a hierarchy - much like in the animal world with wolves or lions, etc.
I have been a swe for most of my life then transitioned into a manager (corporate and small/mid startups) for a while and am a director now (scaleup unicorn).
The politics is something that always bothers me, the higher you get in the ladder, the more people are obsessed by "just following the process", and there's always so many inefficient processes that are applied in environments that definitely do not require such overkill, but make people feel like they are "doing the right thing" by following as many processes as possible - if you follow the rules you don't have to think.
Hours and hours of group meetings (that definitely could have been a slack message, with better outcomes), so many reports no one read, different and often incompatible styles of management, a complete switch from trust-and-ownership to micromanagement from upper management.
But the thing that always bothered me the most is being in the middle between the people you care about (your team) and the people that tell you to do things because they can't be bothered actually doing them (upper management).
I still miss those days where I could put my headphones on and code, solve real problems with my team, ideate and create and focus on the user, not on "making the machine run".
> the higher you get in the ladder, the more people are obsessed by "just following the process"
This is definitely not universally true, and it's a red flag if you're hearing it a lot. The tricky part is understanding whether it is subtle feedback from skilled leaders (I can think of a half dozen reasons why this feedback might legitimately be given), or whether you are dealing with muppet leadership who are leaning on a rote processes to mask their own incompetence. The truth is generally somewhere in between, and very hard to ascertain with a good amount of diverse experience and enough time working with the individuals in question to understand their strengths, weaknesses and styles.
> But the thing that always bothered me the most is being in the middle between the people you care about (your team) and the people that tell you to do things because they can't be bothered actually doing them (upper management).
This comment is a sign of immaturity. The point of a hierarchical organization is to be able to maintain some direction while scaling the workforce. Every manager needs to make a decision on how to best spend their time, and delegation is a critical piece of that. Obviously you can and will have differences with your boss from time to time, but fundamentally if you don't have some general faith in leadership above you that their reasons are good, then you're going to be in a rough spot. The belief that you serve your team while leadership is a nuisance to be tolerated and worked around is a toxic mentality. Your job is to create harmony between those perspectives, so the right information is flowing both up and down, and you can't do that if you don't understand where leadership is coming from.
> This is definitely not universally true, and it's a red flag if you're hearing it a lot.
not hearing it, seeing it. people don't really have time, will to change processes. In private settings they comment and complain about the inefficiencies, but no one spend time rethinking how things are done. (this is literally what pushed me to go higher in the ladder, so i could change that attitude and environment)
> This comment is a sign of immaturity
thanks for the free judgment.
> Every manager needs to make a decision on how to best spend their time, and delegation is a critical piece of that.
I am not saying i want to code, and I am not saying I am the saviour of the team. I am saying having to deal with things like your manager asking you to force your team to come to work becase he wants to see the office alive, but not bothering to take the responsibility on the decision. I have had colleagues (managers) taking every day note on who would go in the office and who wouldn't (precovid).
> I am saying having to deal with things like your manager asking you to force your team to come to work becase he wants to see the office alive, but not bothering to take the responsibility on the decision.
Moving up the ladder means dealing with requests that may be ill informed from a ground-level perspective, your job as a manager is to reconcile those things. It's impossible to make an accurate read on the situation based on what you're posting here. On one hand, maybe your boss is incompetent and not doing his job, on the other hand maybe he's making a reasonable ask and it's you that's failing to see the big picture and how to navigate the situation. Either way, you should be getting on the same page privately. Make your case 1:1, but if you're not able to influence then you have to disagree and commit.
What doesn't help is to air your dirty laundry publicly—either within the team or anonymously in a public forum like HN. It might feel good to vent in the moment, but it doesn't help morale of the team, and ultimately it does not help improve the situation so the team can do their best work.
I did not say where I work or who these people are, I am not publicly airing anything, it's an example I gave to explain the problems people may face "moving up the ladder" which are much more complex to deal with as the personal opinions and management style are much less comparable in short term, compared to coding, and end up easily becoming a religious war (just like this conversation) and obviously the team is shielded and not aware of these discussions, but it sucks to be in that room and having to commit on doing things that go against your beliefs around culture and how to manage people.
At the same time some people are cut for the corporate mindset and easily align or deal with these type of situation with a more detached approach, I am glad you handle this better than me. I still care about my values :)
This is not a religious issue for me, as I stated I don't have the information to judge the situation, my goal was just to reflect how your initial message struck me as someone who has been in software engineering for 25 year and seen a lot of failure modes from all levels of leadership, management and ICs. Feel free to take it or leave it.
It's less than 25 years (about 15) but very intense, and yeah I have had the luck to work in very different environments, countries and type of companies and I have seen amazing leaders and ICs and pretty average middle managers (the "average" part has nothing to do with personal performance, but average processes win over great individuals every time).
I wanted to highlight that the higher you get in the ladder, the more the processes get you and suppress the individual qualities (good or bad).
Sorry if my answer came out a bit negative, I am just saying that as an IC you are not exposed to these type of problems (as a matter of fact I have never experienced these types of problems as an IC).
thanks for sharing your opinions!
"With the storehouse of skills and knowledge contained in its millions of unemployed, and with the even more appalling underuse, misuse, and abuse of skills and knowledge in the army of employed people in all ranks in all industries, the United States may be today the most underdeveloped nation in the world." - W. Edwards Deming, Out of the Crisis
Has that happened at all your workplaces and from manager to director? This sounds almost identical to how an IC would experience a bad manager. It just sounds like you have or have had bad managers yourself.
I’m but a lowly leaf node in the corporate hierarchy ATM but I’m curious about the “do things because they can’t be bothered actually doing them” - isn’t delegation down the tree like the entire point of being a manager? If you could elaborate I’d be quite interested
Every workplace, 5 different companies. Definitely the bad manager part happened, but it's very common and it's easier to name managers/companies/projects/teams that don't have this environment than the opposite!
To be frank? long term employability and short term job security.
The lower levels of management are terrible because you don't actually manage much, and become just a glorified bellboy for upper management, passing messages back and forth.
At the same time, due to disuse, your technical skills atrophy. So, it soon becomes a race to climb the corporate ladder or die.
> ...it soon becomes a race to climb the corporate ladder or die...
Oh man, i'm at the dying stage (metaphorically). I made the mistake long ago of moving to management, and have regretted it for years. But, its somewhat weird for me in that any and all of my direct reports throughout all of my decades actually love me as a technical leader...they all really like working for me, stated that they're the most productive in their lives working with me, havce felt happy coming to work, yada, yada, etc. But man, do i ever hate being management. So, over the years i thought that maybe what gives me happiness is not coding, but maybe solving problems in other ways...so i pivoted to project manager and product manager roles. Nope! While product manager roles come closest for me to get intellectual fulfillment, there's nothing more satsifying to me than coding and managing complex systems. So, then i tried coding again on the side...but unfortunately the languiages and systems that i love to play with (python and linux) are not the ones that tend to be used by the corporate companies that i jhave been employed at. So, i tried getting jobs at smaller firms...and honestly its really hit or miss. Either its some startup that i have no clue if they will survive (and hey i have bills to pay, dont have time to play games)...or its a small business where the senior leaders don't respect the value of what technology brings to an org., etc. Of course, i can always quit my jobs, and start at the bottom again, and code for peanuts...and if i get hit by a layoff, i'm not so proud that i won;t do what i must for my family...but, wow, i wish i can go back to an IC role that is more coding and managing complex systems, and less people management...for someone like my age (pushing 50).
If it serves of consolation, I always found that people who are not enamorated of power and have questionings about their leadership roles make the best leaders.
And man, have you ever considered coding again as a side gig? maybe start your own business on the side?
Yeah i had a side hustle for several years, and found lots of the work quite rewarding (especially in the intellectual fulfillment sense). But if there is anywhere that i suck in life it's leading sales. I'm pretty good as a second banana to another sales lead...but since I ran a one-man show my sales acquisition record for my side hustle was abysmal - even though my existing clients at the time loved me! :-)
But, yeah i considering starting something up again but maybe partner with someone better at sales.
Wouldn't architect role be something you're looking for? Of course, there's a lot of different types of architects and some are just bullshit slidemakers, but you could get some coding and a lot of complex problem solving in right architect role.
You hit the nail on the head there! My current role is as an architect...however my peers and i are really forced to be nothing more than bullshit slidemakers (senior IT at my current employer values the opinions of one of those big consultancies...leaving my peers and I to only focus on making slides - which is ridiculous and so sad...Anyway, yeah, I had the same idea as what you receommended - basically getting an architect role - but so far it has been vastly far from ideal. I tried applying for other architect roles at other employers, but none (so far) have sound palatable; either they're some sort of the same slidemaking bullshit, or they're looking for someone who has been an architect for 20 years (which i have not been this role for that long), etc. I'll keep looking for archi roles...but we'll see. I do appreciate your recommendation, and very much enjoyed learning a new (and true!) vocabulary term of: bullshit slidemaker! Thanks! :-)
I think the author's experience is more true in smaller companies or startups. In the big tech companies especially, high-band senior or principal engineers are expected to lead through influence (without being anyone's boss) and have to make these exact same tradeoffs effectively to succeed. You can coast as a senior in many places if you want to just deliver by yourself, but you won't get further.
Also note that the author points out that he chose to make many of these tradeoffs not from being a manager, but when he got older and chose to refocus on his family. This is a tradeoff many people have to make whether they are a people manager or not.
I quit managing because I couldn't stomach the language managers are required to speak. The cliches, the obfuscation, the outright lying when relaying the c__p coming from above, the list goes on.
The best managers I've worked with don't do much of that stuff. They do use the cliches and obfuscation, but only upwards. They talk to the team in the team's language. As for the crap coming down from the leaders, if anything, the best quality in a manager is understanding what is crap and what's actually useful, and deflecting the crap stuff before it gets anywhere.
This is something I learned in management that I think also made me a better engineer. It's important to be able to code switch on the fly. Shift your whole persona to fit in with the group with which you're immediately dealing, and be able to translate things into their own language. Then go to the next group and immediately morph to fit their culture. Rinse & repeat.
> The best managers I've worked with don't do much of that stuff. They do use the cliches and obfuscation, but only upwards. They talk to the team in the team's language.
It's not a big consolation because, esp. in larger organizations, managers spend most time speaking to other managers, not to their team.
This isn't particularly different from any leadership role, even technical ones. To some extent, you have to own decisions you had say in making. If you just whine about upper management or their decisions, you demoralize your team. So, you have to do the opposite: cheerlead for the new status quo. Depressed people aren't going to get any work done. The situation you disagree with probably has no real day to day consequences. So you have to be positive about it. I guess you could quit if you really feel strongly, but in this economy? It would have to be more than a tooling decision you didn't agree with.
Matrixed organization: I had a functional (provide people to slots) role and separately a program management role (build and deliver mission-critical hardware with a completely different set of people.) I couldn't cheerlead a bunch of Ph.Ds in my functional role about the lack of raises, rising cost of healthcare for ever lowered coverage, perpetual layoffs, and ever-thickening bureaucracy. Similarly I couldn't lie to high performing technical staff on the program that the cutbacks in equipment, facilities, and training along with increased "oversight" by non-technical chumps were in their and the product's best interests. When you lie to good technical people, they will never trust you again and they will tell other good technical people. Without that trust, nothing good gets built.
I decided to put together the best team possible for the program and keep the nonsense away from them. The hardest part was realizing I would not be an intellectual force but rather the bozo deflector. We succeeded but bozos have thin skins and long memories. At that time, I gave up all management roles and went back to being a technical guy looking for technical growth. This was over a dozen years ago and it has been difficult as technical work gets more and more offloaded but I'll never accept another management role again.
This was one of the hardest things for me as a manager too. You have to own the company’s message to your reports (and others) even if you disagree with it or don’t know how it came to be.
In the one bit of company management training I got, the company lawyer explained: As a manager, you represent the company and its interests 24/7. You can try to help an employee but only so far as it doesn't affect the company's bottom line.
When the company lawyer is teaching management how to manage, the company culture has lost all positive vitality. As a first-line manager, my reports and my boss understand that my job is to align in both directions. We're in this together. At times I have to help our team understand that they need to make some sacrifice for the sake of the business, and at times I have to help my management understand that the business needs to make some sacrifice for the sake of the team members.
I'm trying to build a culture of loyalty where we take care of each other and where people can stay and continue growing for a decade or more. The day my management tells me the company's bottom line matters more than the people who deliver that bottom line is the day I'm out the door, and my team with me if I can swing it.
Others have flagged the legal obstacles. More practically, not doing so can affect your own perceived performance and career trajectory. There's also the problem that reports don't take the following message very well: "you're getting screwed. It's not my fault. It's the system."
There's a reason I said this was in the past. I felt like you had to become dead inside to succeed.
Good managers I had did not pretended orders from up above are their own nor that they agree with them. They just told us to do it anyway, but validated our concerns.
I recently naturally grew into a management role due to seniority and churn. I cannot wait to get back to becoming an IC again. All these meeting are tiring and unrewarding. Growing team members is pretty rewarding, but I don't have to be a manager for that.
Disagree with OP on giving up control of the code base. You are still responsible for the quality the team delivers and in many companies your seniority will mean you'll still code review. You just no longer have the time to actively steer. Not a nice position IMO
I can resonate with this a lot as I am a newly minted Staff Engineer.
You really need to block the times to focus, so you hopefully still get to solve some interesting things.
Most of my time is spent on setting the direction, cross team collaboration, managing different stakeholders in the higher, backlog refinements and pre-refinements. I tend to pick up small 1 point story tickets which are not on the critical path to stay in touch with ground reality.
You also have to be an adult in the room, even though you are not wrt age. Got to deal with kindness and patience.
Loved your phrasing here around “ground reality”. I do the same partly because I miss coding but mostly because I don’t want the code base to get away from me.
Honestly, going from contributing actual results, you are now just measuring results and browbeating intelligent folk into producing more results.
Simultaneously you find yourself trying to maximize your budget and minimize your deliverables to make numbers look good, while understanding that both these things are bad for the customers and bad for the stockholders.
First level management is not a great place to be...these are the folks Zuck told to go back to IC or leave
At the first level, you have zero actual power. All you are doing is conducting perfunctory 1:1s and signing time-off forms. But you also aren't an IC and slowly fall out of the dev mindset and your skills atrophy
My boss has been a first level manager for years...if he's ever laid off he is in big trouble...he never really managed anything and he no longer codes
Fully agree. After getting to second and third level management at startups and larger companies, I chased the $$$ to a first-level management role at a FAANG. The pay was multiple of what I ever dreamed of making, but expectations were set making the assumption that I had literally nothing to offer other than to manage performance and to find ways to generate "org impact" by being on random committees. All of the other things I did, such as technical mentorship, helping my higher level ICs get greenfield projects off the ground (starting a new thing is a surprisingly uncommon activity at larger companies), etc. was not valued at all.
I eventually bailed out and am now getting paid 1/3 as much to deliver 10x the value to startup.
In many organizations (but not nearly all!) going to management is a relatively straightforward way to get more compensation than at your IC position.
But what applies in most organizations is that if you want to have influence on what the organization does, how it does it, and how your product or service will behave, that influence is mostly given to the management - so if you stay as IC, you'll be implementing the vision of others, and if you want others to implement your vision (or even to have a seat at the table where that vision is decided), you need to be at a management role; if you want freedom and decision-making ability and self-actualization in your job, well, in many large organizations ICs get limited opportunities for it, you have to climb the hierarchy until your views start making an impact.
There is a advantage I see very few people talk about publicly but saw all the time: no more pressure to run the dev skills treadmill. No more need to keep up with the latest JavaScript frameworks, or the latest micro-weave clustered engine architecture fad of the day. No more signalling technical superiority for promotions.
Many dev managers breathe a sigh of relief since they feel they "no longer need to keep up" and let their skills atrophy.
Being a manager in a company with more than 25 developers is a new arena that is often even more competitive, but the rules are totally different. No one gives a shit if you're the best engineer in the room, but if you still want promotions you need to learn all the new ways to show your value. It becomes about telling the most compelling stories, doing great research to prove your points, using charisma to charm the right people, and being clever or lucky to lead projects you can turn around or have a big impact. The things that will get you promotions as a manger are rarely tied to team performance, and often tied to people's _perception_ of their performance. I realize this sounds cynical, but it's just the reality of how politics is played, and management almost always is playing politics.
I was a manager for many years, and then director of several teams for a few years. I was next in line to be CTO of a 1000+ developer company when I walked away to become an IC again.
I just missed it too much.
However, I'm very social and love people. I love scheming new ways to do things or improve things. I really enjoyed one on ones with most employees (which was good, at one point for a year I was managing 25 people, and one on ones took 15-20 hours of my week!). Sometimes it was terrible, mostly with high performers who resented the process or people who were quiet quitting. Most of the time it was people who just wanted to get better, and I loved helping them scheme out how I could help. I did everything I could to help my people succeed and get promotions, and they often were loyal and hard-working in return.
I love building a team of people who are gelled together, who feel a real sense of belonging. I very much missed the fast dopamine feedback of TDD, but I learned to enjoy slower metrics like:
- reducing WIP limits (down to 0.5 stories per dev, started at 3.1 per dev when I started)
- increasing dev retention rates (my teams were up to 6 years average! It was 2.3 when I started!)
- reducing dev weekly meeting minute averages (my teams down to 3 hours of meetings per week average! It was 15 hours when I started!)
- prioritizing technical debt payoff (it was 50% of the time when I left, up from 20%)
- ensuring all devs had unstructured research time (10% weekly)
- ensuring teams prioritized high value efforts like CI/CD, one button deployments, etc
- making my product high profit margin (it was 100% ROI three years running, up from 30% when I started)
Building a place devs loved to work and wanted to stay was extremely rewarding.
Ultimately, the politics of the boardroom and upper management really ground me down. Eventually, the company wanted to move development to India, with me managing larger teams there while reducing my American staff, and I just got burnt out and left.
There's a universe where I manage a team again, and possibly will be doing so this year, but for now I'm loving getting to play with tailwind, digging into vite, and cranking out out CRUD forms.
many companies see it as a natural progression and you begin to get pressure to make the jump. I don't want to bring up the ageism boogieman but as you get older the expectation to be a manager goes up as well. Being a good manager is very hard though and a vanishingly small subset of the skills that make a good swe or even team lead apply in management. It's almost like starting a new career.
I'm in the process of making the jump, my title is even Sr. Manager which at the consulting firm i'm at is pretty high up the food chain. I still serve as architect, TL, and the last point of escalation for dev teams in projects though.
For me, it's just the pay increase that keeps me climbing the ladder. It's all management form here on up where i'm at unfortunately. However, my firm has very VERY nice golden handcuffs so it's not so bad. I still write tons of code with my hobbies and kids so i get to scratch that itch.
>Unfortunately, I also needed to unblock my team so that progress wouldn’t grind to a halt whenever I decided to work on a new feature. Eventually, I figured out that I couldn’t take on projects in the “critical path,”
This is a important lesson. As an IC, it's hugely frustrating to be blocked on your own work because the gatekeeper is busy working on something more important. If the manager is the only person you can trust with the important work, something is broken.
There's just not enough time in the day to do 8 hours of IC work if you're also responsible for reviewing 8 hours of work from N reports. You are a thread consuming a queue.
If you draw a Venn Diagram, with one circle being technical skills and the other circle being leadership skills, the intersection is engineering management. Unfortunately this is not a natural combination for most people, and it’s why there are so many bad engineering managers out there.
It's not really. Good management is really hard. That being said, lots of other functions (sales especially) have a bunch of senior people who want to manage, so it's easier to pick the good ones.
In engineering/more technical fields there are less people who actually want to manage, so you end up picking from a smaller pool.
I've actually given up all of these things years ago, and I'm an IC. Maybe I'd be fine as a manager. I give zero shits about placating my ego by being the smartest person in the room. I want everyone else on the team to make their own decisions, learn lessons, and be actively contributing in all ways. And honestly, most problems and imperfections are fine. Let people do something in a crappy way. It will eventually help the entire team, as counter-intuitive as that seems.
Speaking as someone who has held senior management roles: judging strictly from this comment, you would make for an excellent management candidate. Assuming you survive the disillusionment upon seeing how other managers and senior leaders actually operate.
I moved from IC to manager for four years before moving back, and can agree with the points made here. Including the one about it being fairly easy to move back.
Some ICs may find they are actually better managers, and some will find out they were better at being an IC.
Others will find both satisfying in different ways, and may work out well on either ladder.
I may go back to being a manager some day, but for the time, I’m enjoying being an IC again.
If you’re fortunate enough to work at a company that affords you the flexibility, and you’re given the opportunity, I recommend trying it out, after you’ve read and ack’ed the tradeoffs in this article.
But if these tradoffs sound miserable to you, don’t bother; there are plenty of good opportunities as an IC — if not at your current gig, then at another one. And if not now, then later (when the economy improves).
I found this really hard in my career though - you move into an IC role and then the assumption is you won't be happy in a management role ever again. You move into a management role and somehow there's an assumption that you have been lobotomized and know nothing about the hands-on work any longer. It's not fair, but it can really create complications as you attempt to move your career into new directions or attempt to move to new employers.
I've been trying to counter that effect by saying "have you heard about the pendulum model?" and showing that article to as many people in influential positions as possible.
Eh, people will find a reason to judge you anyways. I am jarred to the point of thinking none of it matters, usually the person has an opinion of me before I even meet them anyways.
Conversely, trying to move into relatively in demand things where supply / demand curve is bent out of shape helps. You can't discriminate for willy nilly reasons if you can't find enough candidates.
I wonder if we should do it as a matter of course the same way some executives and managers do line work to better understand and appreciate their employees.
This pretty much summarises my experience, especially the fragmented days and the lack of short feedback cycles. As someone who TDDs as much as I can, the dopamine rush of seeing a piece of code go from nothing to complete is something I found tough to replace in management.
I thoroughly enjoyed the mentorship and relationship building aspects though and it is really great to get to know people on a deeper level. I switched back to being an IC about a year ago, and I do miss the 1:1s with the team.
I moved back to being an IC due to the sheer amount of other things going on in my life (moving countries, having a kid etc). I needed the comfort of doing something I felt deeply familiar with. Definitely like the idea of swinging back to management at some point in the future though.
I have a good friend at the Fortune 100 company we work for who move into engineering management. He hated it. Unfortunately, he was very good at it so it took years for him to convince them to let him move back to an IC role. Even after that, they kept looking to him to make management level decisions, which he had to flat out refuse to do until they finally learned that he really was an IC again. It was so much stress trying to get back into an IC role that he has been looking for new jobs outside the company.
As a side note, I have noticed that sometimes people that move into management from a technical position seem to not be fully aware that management is not only about managing projects and keeping track of people timely executing a project, and/or giving some guidance when a project gets a bit blocked, but also about growing people to their fullest potential and trying to understand how to integrate these people's unique abilities into a more cohesive whole, instead of different parts who do exactly what you want them to do, not holistically at all.
There's also a big empathic component to the job that I have noticed some people with technical backgrounds seem to lack. It's almost as if there's a tradeoff pattern of sorts: "Good Technically, Bad with People" vs "Good with People, Bad Technically." I would even dare say that I think the second version is better, since it's easier for people to grow technically than it is for them to grow emotionally... At least that's what I've perceived in the past...
I've met people who are technically magnificent, were amazing individual contributors, and who can plan a project perfectly but who just seem to me to not be able to properly handle the more human side of the equation. They treat people more like tools than actual complex humans... This leads to just "good enough" workgroups that get the job done, but not fully fledged integrated teams that can innovate and actually grow in a more efficient manner.
I urge everyone who is either a manager or is thinking about moving into a managerial position to check out:
Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration
by Ed Catmull, co-founder of Pixar. He is the perfect example of how a technical person can become a great manager in every single way, and the book gives really clear guidance on how to follow the same path.
Most ICs in the organizations I’ve worked on have to fight for focus time, have long feedback cycles, have to deal with conflicts, etc. At least with a manager you’re getting paid more! The risk is slightly higher but the reward is significantly higher; you’re taking credit for a larger amount of work, but doing the same amount of work yourself (maybe sometimes more, but also often significantly less than an IC).
Management is easier than coding unless you really hate working with other people.
Indeed. I've never been interested in management at all, because it would take me away from doing what I actually enjoy doing.
I've done it when necessary, though, in my own companies. But it's No Fun. I see many jobs around me and think "I don't understand why anyone would want to do that, but I'm happy that someone does", and management positions are among them.
one things that's missing is the ability to ignore politics. you have to know what hills to die on, when to enforce boundaries, when to back off, etc. also, having to make decisions, argue for them, and be accountable to them, without fully understanding all the details. I found these things to be far and away the most stressful parts of management.
i also read that Manager's path book, when finaly moving into managerial role, and the thing that struck me was: you cannot be friends with (your) people anymore.
initialy i thought - WTF?
Sadly, it is true.
Any friendship you form - or had - would be misinterpreted, by someone.
Good relationships with people. Compared to engineers, managers have mostly bad relationships between them. And engineers will be under you, so you cant be friends the way you used to be either.
surprisingly I didn’t see anything in here about managerial responsibilities of big decisions involving company $$. budgeting, vendor & contract negotiation, build vs buy, etc. I found this to be one of the starkest differences and all a bit unnerving when I made the transition from staff IC to manager. will say that having a good boss and mentor helped a lot with the feelings of imposter syndrome.
As a manager you deal with people. As an IC you also deal with people but to a smaller degree. If you can handle dealing with people you stand to make more money. It’s a job.
Luckily management is not the requirement for more money nowadays.
Most Staff/Principle and even Senior engineers are on equal footing (and often more) with managers in terms of salary.
As an engineer on those level you are also mostly dealing with how to align a huge group of people - you are just not required with hiring, compensation, etc.
I'd argue that being accountable for technical decisions, and losing touch with the codebase and your own technical skills, is just plain dangerous.
All of the greatest managers that I've reported to were able to (1) call "bullshit" when work was subpar, and (2) drop in, right down to the codebase, when it was clear that something was at risk. This whole culture of "accepting that different people will do things in different ways, so you should let go of your will to stay close to the tech/PRs" just seems overly sensitive to the elephant in the room: manage your time better, so that you can stay technically relevant.
How are you supposed to be accountable for technical deliveries, if you've got no expertise in the field and the codebase? How can you break up your vision into a set of executable subtasks, if you have not the faintest idea where one subtask should start and the other should end? And therefore, how can you enable your team to deliver on your or the organisation's vision? How do you come up with even remotely plausible timelines? Of course you need the people-centric managerial skills too, else, nobody is going to be motivated to work under you and help you execute. But, the key is, the people under you need to respect your technical skills as well as your empathy and managerial skills.
I'm concerned that the perpetuation of this trope of "you're _encouraged_ to lose your technical acumen as an engineering manager, it's OK!" is going to result in MORE of a common failure I've observed: the non-technical pure manager. They were recognised for good people skills amidst a sea of purely introverted coders, and are now tasked with managing junior to mid-level developers. They jumped on it, because writing code was always something they struggled with, and management is "prestigious".
This is a recipe for disaster. Unrealistic promises made to stakeholders. Deadlines inevitably get pushed down to the developers. And of course, these managers will (a) NOT be capable of noticing broken windows in the codebase or delivery/CI processes, and (b) NOT be able to suggest pathways out of them. So guess what happens? Shortcuts are taken. The codebase suffers more. The shortcuts are then relied upon for critical functionality, and you can't unwind them easily. Oh joy.
So there's the "engineering manager", who maybe was good at coding at some point, but has since "needed" to lose their edge. Hopefully they have a good tech to delegate most of the major decisions to. There's the "IC", who is still busily coding...
...But there's a 3rd path here that's not often mentioned: the "scout/squad leader" team lead. It's a great blend of hands-on work, leadership and management. You're, at most, one level up from the actual developers. You're the person in the squad that runs first, not the Army General shouting orders over intercom.
You're management. You're also IC (for non-critical path items!). You'll use your experience to explore the terrain before your comrades. You'll know when you need to scaffold prototypes, and even suggest initial stubs and interfaces for your team to implement. You'll also know when this is in good hands, and can stand back. You'll be able to offer meaningful advice to unblock your team, beyond "just pair with Jill, she's done this before, I'll make sure she's free". The point is: you _can_ drop in when you need to, if "Jill" isn't free and is doing something super-important. You'll know exactly where the gaps in the team are, and therefore who to hire.
You've seen the pitfalls before. You've seen what a good engineering process looks like. You'll be able to come up with target state for technical problems, but (unlike your pure-IC friends), you'll have both the influence and the necessary skills to break that down into sub-tasks that can be _executed by a team_. You are where you are because you have (1) good technical skills, (2) good people and comms skills, and (3) at some point in your career, realised that your visions cannot be executed in a timely manner by a single individual.
Your time management needs to be bulletproof. If your schedule is fully booked with meetings, (i.e. you've got 7 hours of meetings booked in an 8 hour day), then that's on you. Personally, if I have more than a few hours of meetings booked a day, I am re-scheduling, rejecting, or suggesting alternate times. I owe it to the other members of that meeting to give it my 100%. Also, every time I make a commitment to either myself or someone else, I'm blocking out time in my diary to actually _make through on that commitment_ (whether its "Review John's latest PR" or "Pre-refine tickets for next sprint"). This (1) makes it look like my diary is fully booked (like a "good manager" is supposed to have), and (2) makes it clear if it's a realistic commitment (so I can manage expectations), and (3) makes it clear to me what will slip if I have to accept some "bullshit" meeting, so I can manage expectations accordingly.
All of this can be learnt, and it doesn't blunt your coding skills. I just don't buy this "Engineering Manager or IC - choose your adventure!" myth that our industry seems to perpetuate.
You start using corporate jargon. You become more authoritarian. You embrace careerism (a term I invented to describe people who erroneously conflate rising in corporate rank with happiness). You quickly learn that no one understands anything about the people or the business--and that all decisions are made by gut, cherry picked data, and story-telling. Suddenly, you'll be afraid to disagree.
Your only job as a manager is to protect and develop the team under you. You must actually like people and have a fundamentally benevolent worldview. You must be willing to say "I don't know" 10x more than as an IC. You must believe deep down in your core that ordering a human being to do something is a sign you must introspect about your failure as a manager, and commit to fixing the problem.
You must be prepared to tell your own manager to go kick rocks. Ambiguous situations are one thing, but you must never, ever knowingly do the the wrong thing. Everyone will know when you do it, and that will be the beginning of the end of your own happiness.
All other approaches will lead to you failing to deliver results, failing to retain, and a drag on the org.
The error I have seen most engineers-turn-manager make is they had a deep dissatisfaction with other terrible managers, so now its their chance to make the right decisions and do things their way.