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.
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.
Reach out and tell him that. I'm sure he'd appreciate it.
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?
"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
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.
The biggest thing they give up is having to do leetcode interviews.
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.
The called me back and said sorry, and I interviewed with their dev manager.
Hiring managers perogative.
does not sound like any manager i ever knew
One of the signs of a healthy culture is that people are not afraid to acknowledge knowledge gaps.
To be honest, if anyone, in any role, never says "I don't know", I begin to question their abilities.
> 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.
>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.
Giving direction and context is different from giving orders.
You most certainly didn't invent the term "careerism."
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.
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 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".
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.
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’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
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.
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).
And man, have you ever considered coding again as a side gig? maybe start your own business on the side?
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.
It's not a big consolation because, esp. in larger organizations, managers spend most time speaking to other managers, not to their team.
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.
Why?
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.
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.
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
I eventually bailed out and am now getting paid 1/3 as much to deliver 10x the value to startup.
Why do people need to convince each other _not_ to move into management by content like this?
To get a balanced view - what are the advantages of becoming a manager? What are the rewarding parts of managing people?
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.
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.
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.
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.
In engineering/more technical fields there are less people who actually want to manage, so you end up picking from a smaller pool.
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.
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 really like that: in my experience, ICs who have been managers make better ICs and vice-versa.
https://charity.wtf/2017/05/11/the-engineer-manager-pendulum...
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.
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.
Last thing: A bit more technical, but the following article/paper is a bit connected: https://necsi.edu/a-mathematical-theory-of-interpersonal-int...
Management is easier than coding unless you really hate working with other people.
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.
initialy i thought - WTF?
Sadly, it is true. Any friendship you form - or had - would be misinterpreted, by someone.
ah
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.
At least in my country.
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.
