13 ms·

Things I've learned in my 10 years as an engineering manager

577 points by jampa 9mo ago

bravetraveler 9mo ago
Whoa an EM that talks to clients? A rare treat. I just got a browbeating because I (an IC) didn't jump at the chance to do more (that) for ~free~ growth. Ahem. Mind you, we have piles of both kinds of PMs: product, project. Best I can tell, they play video games between calls/status updates. Forgot the blur on more than one occasion. Clownshow, myself included.
- deleted 9mo ago
  [deleted]
andreidbr 9mo ago
I wholeheartedly agree with point 7 Your goal is for your team to thrive without you. I spent a lot of time also playing a Scrum Master role in addition to my regular duties. So much so that some managers asked me to pursue this full time. I always explained that my goal is to be there just as a point of contact and that the team should be able to manage itself. Sadly, I see so many managers, scrum masters, or even regular engineers consider this as a dumb approach to make yourself replaceable. If you don't hoard knowledge then you'll be laid off when the company's numbers look bad.
- soulofmischief 9mo ago
  I've always told my engineers that their job is to get me fired for redundancy.
  - pjbster 9mo ago
    I always say that a job without an end date is a lifestyle.
    - OhMeadhbh 9mo ago
      I'm stealing that one.
- DevKit 9mo ago
  Agreed, I was fortunate enough to learn this lesson early in my management career when I was passed over for a promotion I felt I deserved for someone who's team was able to operate without them. Looking back, I know this is why he got the role rather than me, my team couldn't live without me whereas his could and therefore he could take on the expanded role.
jofzar 9mo ago
Damn, this person looks like a good manager. These are all things I have seen in my good managers over the years when I had them.
- andros 9mo ago
  Yes, he has a lot of accumulated experience!
  - OhMeadhbh 9mo ago
    If only all experienced managers could have developed the same amount of understanding.
- lloydatkinson 9mo ago
  I've had one good manager and I concur. As valuable as gold.
andros 9mo ago
I completely agree with point 9
- pplonski86 9mo ago
  Maybe point 9, trust but verify, should be extended to AI coworkers as well. I would love to have tools to verify AI code by quantity.
  - jrflowers 9mo ago
    Whatever human that is in charge of the chat bots is your coworker. That person that is responsible for the output of the bots is the one that you would trust but verify with.
junon 9mo ago
This is clearly a good EM. Agreed with pretty much everything, being on the engineering side. Stuff that seems trivial and obvious but that a lot of EMs miss.
satisfice 9mo ago
Why do people espouse goals like “not to be needed?” I never understood that. It sounds like LinkedIn virtue signaling. It’s a capitalist talking point along the lines of “I seek to be good and inexpensive capital for my corporate masters.” My goal is to help my team succeed in such a way as to keep my job or else get a better one. Being “not needed” hardly serves that goal. Look around you. We are in a world that is turning away from middle managers. Don’t play into their hands.
- mulmboy 9mo ago
  Because it's a good heuristic for a functional and resilient team. People don't usually means it literally, more like "if I disappeared it should be pretty painless for the team to continue along for a month or so and to find and onboard a replacement".
- Keirmot 9mo ago
  The way I read it is not to be needed for normal functionality of the team, not to "not be needed" at all. Akin to a ship's captain - for the most part a ship works without a captain just fine, but that doesn't make the captain's job redundant, it's just he's needed for specific occasions, otherwise, he's just making sure the crew works as a well oiled machine.
- Rainbooow 9mo ago
  I think the points made at mostly for a front-line manager though, not so much for a middle manager.
- skirge 9mo ago
  cause it means: I lead them so good that I do nothing and still get my salary.
  - mcapodici 9mo ago
    the coder's equivalent is not get paged (or bug reports). the system run's itself with no dramas, so I get to work on improving it.
  - 9mo ago
vasco 9mo ago
> People above you have limited time to focus on your specific issues. You can’t info dump on them. If they take a misguided action based on what you tell them, it will be your fault This bit is useful to everyone, and many people never learn it and get jaded about work itself! They paint themselves into a dilbert strip without realizing. And then of course there's also bad bosses, but any work advice is like relationship advice, it really depends on the specific people involved.
oldpersonintx 9mo ago
[dead]
20260126032624 9mo ago
11. What works in one country doesn't necessarily work in another.
palata 9mo ago
> That’s why lying or withholding information that affects them causes irreversible damage. They might not leave immediately, but they will resent you. [...] I have a friend who still resents a manager for a lie told three years ago. Oh yeah. To be fair, it's not only the case for managers. If a colleague lies to me, they lose my trust. But I have never had that... why would a colleague lie to my face or withhold information? That's a thing bad managers do. When a manager lies to me (or withhold information), it's never one time only; it's the way they work. And when they work like this, they are not in my team. They play against me, so I play against them.
- snarf21 9mo ago
  There is an old saying that rings true here: "People don't quit jobs, they quit bosses."
vachina 9mo ago
All these properties of a good manager will come naturally with humility. Because being humble makes you more receptive.
- CBLT 9mo ago
  I've had great experiences being managed twice by very humble engineers who've made the transition to EM. Both were sacked within the year by their boss because they didn't play the corporate politics game.
  - Schlagbohrer 9mo ago
    It's so disheartening to learn that one works for a manager who doesn't care about having the most skilled team, or best product, but rather someone who has selected for "Who will kiss up to me no matter what? Who will never tell me anything I don't want to hear?"
Traster 9mo ago
>I wondered, “Who is this feature even for? Who will use it?” No one on my team knew. I think there's another key here - Don't assume someone else knows something. If you don't know why something is done some way, find out who does and make sure they do. I've been in so many situations where the organization gets complex - person A is loaned over here or person B is working on project X because team Y needed feature Z. So frequently you'll find out that core assumptions have been made because everyone involved was only half-involved and either kind of assumed someone else was taking care of it, or (more frequently) knows the assumption is wrong but is choosing not to say so for political reasons.
- Schlagbohrer 9mo ago
  I sympathize with keeping one's mouth shut for political reasons. Having a boss who angrily shouts at anyone who dared use their own brain and offer an idea, I learned to keep my mouth firmly shut even if i saw countless problems coming down the road.
  - arendtio 9mo ago
    It is one thing to do that while you have that boss, but something completely different to keep acting that way even when you have a different boss. The more people you have on a team who keep their mouths shut, the less effective it will be.
  - Traster 9mo ago
    It's totally understandable, but it would have been good to have been given a heads up - I'm totally new at the company (new to the industry), assume one of these people knows what they're doing. In the end I got a new boss and convinced him to take a different approach once the first approach failed, but I would not have blamed my new boss for just binning the entire project and getting rid of me.
- OhMeadhbh 9mo ago
  When I was in the Marines, we had a rule of thumb that every Marine needed to know their own mission and the mission of units two or three echelons above them. So individual Marines needed to know their mission, their platoon's mission and their company's mission. Company commanders needed to know their mission, their battalion's mission and the division's mission. More specifics for echelons closer to you. This is complicated by the fact that Marines deploy as MEUs, MEBs and MEFs [1] which aren't "pure" echelons, but it's a rule of thumb and guiding principle more than a hard and fast requirement. I've ALWAYS been annoyed by engineering organizations that don't think developers at the leaf nodes of the org chart need to know what's going on. Devs may not do anything with the info, but letting people in on what's happening seems to send the message that "management thinks you're important enough to hear what we're working on" and every now and again, individual devs need to make decisions that depend on these more abstract / higher-level goals. 1. https://en.wikipedia.org/wiki/Marine_air%E2%80%93ground_task_force https://en.wikipedia.org/wiki/Marine_air%E2%80%93ground_task...
Schlagbohrer 9mo ago
Good advice in the last point about interviews. "While you're scheduling the seventh round, good hires are already accepting a job elsewhere." I gave up on a job I was lukewarm about when, after flying me there for an all day site visit and hours and hours of technical interviews, they then wanted me to do 3 days of video calls with various groups around the company! People i could have simply met for 15 minutes in person when I was there. In all the time this took I accepted a much better job closer to home.
MarginalGainz 9mo ago
[dead]
OhMeadhbh 9mo ago
> "Most engineers prefer feeling appreciated over having a ping-pong table." Truer words have never been spoken. Note the OP put the word "Most" in there. Sure... there are a few ping-pong fanatics, but not as many as there are humans who like an emotionally fulfilling work environment. A related sentence I've uttered is "Most engineers prefer more control over their daily tasks than cash bonuses." But again, the word "Most" is doing a lot of heavy lifting here. My experience is no more than 25% of devs will trade cash for micro-management. YMMV.
tmarice 9mo ago
This kind of EM-focused articles often mention "coaching" and "career growth" -- I always wonder what does this concretely mean. Are they all managing teams of juniors straight out of college? What can a career EM, or even an engineer-to-EM convert who has been out of the coding game for more than a few years, teach a non-junior engineer on their team? I understand we can talk and exchange our concrete life experiences, same as I would talk to and listen to any other person, but the word "coaching" implies one party is superior to the other in one very concrete area.
- __alexs 9mo ago
  I am not an EM (anymore) but I see a lot of more junior engineers struggle with ambiguity and complex decision making in general. It is not uncommon to end up in situations where there are not clear right answers and developing the techniques as an individual, and as a technical contributor to navigate these well is tricky. I don't think this is an EM specific function at all though and is just something more experienced people should be doing for their team. I think the EM definitely has a role in making sure people identify that they could benefit from that kind of help and make sure they find it, but doing the actual coaching is optional.
- GabriDaFirenze 9mo ago
  Coaching doesn't imply superiority. Most coaching can be done with little to no context and the goal is to guide the other person in finding the right answer on their own. I think you might be confusing coaching with mentoring. As an example, I attended a coaching training session and when we broke out in groups I played the coach role. The other individual brought up a concrete issue they were having and I was able to unblock them and I never met that person before. I was their guide even though I had no context (but I have experience mentoring and coaching). I've been a manager for years and there's a lot outside of raw technical ability that a good coach and mentor can keep you honest on. Rarely will you find someone who's reached full potential or who doesn't want to improve at all (maybe surprisingly based on your comment but I have found seniors to be the most eager to grow)
- tl 9mo ago
  Most of the job is noticing friction and clearing paths — which requires context and trust more than technical superiority. In practice: Start a note for each engineer you manage. Fred Brooks called this a "career file". Start by writing down things that frustrate them enough to complain about publicly. Add hurdles that come up in their one-on-one. Identify problems you can solve, problems you understand but cannot solve right now and problems you do not understand. Then put on your PM hat; sort by priority and execute.
crjohns648 9mo ago
> A good manager is more like a transparent umbrella. They protect the team from unnecessary stress and pressure, but don’t hide reality from them. I'm absolutely going to steal this metaphor going forward. Being a "transparent umbrella" does require knowing the personalities of your reports, some people do get distracted when they think higher-up decisions or unhappiness are going to affect their team. Most people, however, really appreciate the transparency. It helps them feel more in control when they know what is happening around them, and when things do change they can tie it back to something that was said previously.
- fidansin 9mo ago
  Kinda like; You got to do, what you got to do.
  - ghaff 9mo ago
    The basic question is how much context do you actually want if you can't really affect it and it's therefore more of a distraction than useful input. Some is almost certainly useful but it probably varies by individual and situation.
- gambutin 9mo ago
  Honestly, I’m not sure. If I know what was going on transparently I am stressed. As an ordinary employee, I don’t need to know everything and therefore don’t need to worry about it.
  - _blk 9mo ago
    As a leader, it's important to provide not just the meat but also the veggies. What people end up eating is up to them, but serve the full course! If as a ME, I start deciding who needs to know what, information will be perceived as incomplete because people always talk and engineer are often smart enough to read between the lines. So the transparent umbrella is a great analogy. Communicate bad news as fast and coherently as possible - group meeting with open questions works well for me but be ready to address the potential fears: "In my current assessment, that's not going to be a problem, I'll let you know if that changes." and of course "Thanks for asking, I didn't consider that and I don't know yet. I'll clarify" is a valid answer, if you do indeed clarify. If you're genuinely stressed with that, talk to your lead about it and they'll find a way to filter a little more while not giving you the feeling of being left out.
v_CodeSentinal 9mo ago
The point about 'no such thing as a free lunch with processes' is something I wish more junior EMs understood. I've seen so many teams treat process as a pure 'fix', ignoring that it's always a trade-off: you are explicitly trading velocity for consistency. Sometimes that trade is worth it (e.g., payments), but often for internal tools, you're just paying a tax for consistency you don't actually need.
talkingtab 9mo ago
Enough already. The way to determine what kind of manager a person is, is to listen for the context they use. For an extreme hypothetical example, if you hear a manager talk about locking their team in their cells every night, you will know something about their context. If the manager says "They look to you for leadership and clarity", you know something. It they quote Jeff Bezo, that provides more definition. The lesson to learn from this article is not the words, but the context. What is the context you find in this article? How does this person talk about other people? What assumptions are inherent in this article? If you find this normal, what does this say about your assumptions? What I have learned from my years of being an engineering manager is that the corporate model of software development is fubar.
- PlatoIsADisease 9mo ago
  > How does this person talk about other people? I find myself referring to my contractors as: Workers. What does that mean about me? I can't call them employees. I read the communist stuff a while ago and decided I didn't want to be exploited, so I thought this was just the proper terminology. But people on the internet loath being called a worker and have called me out on this. Meanwhile I yoyo between to nice and too hard... I think I'm naturally too nice to the point of failure. I seem to only be 'too hard' for a few months before I go back. Thank god my industry is high demand, I think even with bad management we will survive. (I got a masters in Engineering Management + read 10 books, but management/supervision orthodoxy is diverse and contradictory.)
- deleted 9mo ago
  [deleted]
videogreg93 9mo ago
> Everyone needs to care about the Product This isn't the first time I hear this, but I always have a bit of trouble with this one. It's one thing to take a step back and think about the actual product and how it'll be used, but I think it's presumptuous to think that software engineers know what makes a product good or not. We don't say "Everyone needs to care about software architecture, even Product", so I'm not sure why we think the flip side of that is true.
- 1980phipsi 9mo ago
  At the end of the day, the goal is to make a product that people find useful. How that ends up happening is almost completely irrelevant to the people actually using the product.
- SkyPuncher 9mo ago
  If you consider product as a proxy for customer, I think it gets a bit easier to understand. Customers don’t care about architecture (unless you have a technical product where they do actually need to know architecture). They don’t care about many of the details. They just want their problem solved. For software engineers, our goal isn’t to necessarily know what makes good product or not - but we do need to make sure that what we’re building solves an actual customer problem or need.
- tristor 9mo ago
  > We don't say "Everyone needs to care about software architecture, even Product" We absolutely should say that. I was an engineer for 13 years and have now been in Product for 8 years. I work on a highly technical Product team, and it is absolutely an expectation for myself, my peers, and my reports that we should ensure we fully understand our Product, including its software architecture, and have an opinion about it. Engineering ultimately decides the "How", but they cannot do that effectively if Product cannot articulate an opinion about the architecture guided by an understanding of things like expected scale, potential future integration decisions, and other cross-organizational expectations that may not yet be codified. In general, Product should have an educated opinion on anything that is a one-way door, and so should Engineering. It should not be a unilateral decision, and if either party is unable to form an informed opinion, that's an organizational miss.
hnthrow0287345 9mo ago
>The most common reason companies fail is creating products that don’t deliver value to users, causing them not to pay. >“Oh, but I have a PM for that,” you might say. But having a PM is not enough. It should be, that's literally their job. Developers and EMs shouldn't be doing that part for them. In the same way developers need to know how to ifs and loops, Product Managers need to find out which features to build and user pains to fix. Maybe, just maybe, we need to stop raising the bar for interviewing developers and start raising the bar for the other people working with developers, instead of getting developers to compensate for shortfalls.
- AndrewKemendo 9mo ago
  There’s a reason you never see posts like: “My jump from BD to software engineer” I’ve never met a sales person as broadly capable as your average engineer. The curse of competence is organizational as well
  - ghaff 9mo ago
    Because your average engineer is so good at creating customer relationships and generating revenue. Customer relationships are certainly more important in some categories than others but sales is certainly key in a lot of B2B organizations.
    - AndrewKemendo 9mo ago
      I guarantee I’ll be more successful with a group of engineers doing sales than I would a group of sales people trying to do engineering
      - ghaff 9mo ago
        Both would generally be crap in isolation. (Assuming non-overlapping skill sets such as solution/system engineers.)
- derwildemomo 9mo ago
SkyPuncher 9mo ago
This is a good article. In fact one of my favorites now (will be sending it to my peers). There’s a point buried in it that I increasingly come to believe is missed in nearly every single management book and management advice I’ve read. It’s almost there in point 1, but under “don’t have a PM”. None of these points matter if you’re not creating value for your company. That is the job of a manager - get your team to create value. I’ve been increasingly disgruntled with most management advice because it overlooks this key point. I felt like one of the biggest steps back I took in my career was when one of my companies had our management attend training that taught these skills and then the company emphasized these skills repeatedly. Suddenly my career stagnated. I had managed before, I had led before, I had delivered results before. But my growth came grinding to a halt. I was following all of these tips and tricks while overlooking the implicit thing - deliver value. In many, the same ways, I’ve become wary of any company beliefs, values, or guidelines that aren’t clearly working towards making the company money. They’re really just distractions for the underlying goal.
joshcsimmons 9mo ago
Correct on all points! Very well put - you sound like an excellent manager. As always the difficulty is in getting people outside your team to realize that the 60% cheerleading bit is crucial, many will see this as a waste of time that doesn't create "business value", as if the only business value was measured in lines of code.
bradley13 9mo ago
"Delegate everything" - delegation is hugely important. But not everything, obviously, as a team lead your responsibility as "transparent umbrella" cannot be delegated. It also sounds like he is talking mostly about external projects. For internal projects, you really do serve as a shield. One project, I spent my first months teaching the internal customers that they were not allowed to talk to my people. They had become accustomed to telling individual developers "I want feature X", which cause total chaos. I stood between the customers and my developers - at the beginning, sometimes literally blocking the office door - and said: my team, my job, you talk to me.
rendaw 9mo ago
> Never ask the interviewer what they expect from a manager. Some managers assume their experience is industry standard and might find that question odd. I was in an interview and asked this, and the interviewer got annoyed and wouldn't give me an answer. It sounds like this sort of experience may be more common than I thought.
gorpomon 9mo ago
This is all really good stuff, and thankfully I feel like I have been practicing a fair bit of this already (so, I could be biased here!). I like the umbrella callout especially, that one took me a few years to really internalize. "Protection" isn't as beneficial as "good stress" is. You don't just protect muscles, you use them in a responsible manner to get stronger. I've started trying to ensure my team gets a lot of "good stress" (so projects that grow careers, develop expertise, etc), while getting some concentrated down time after to rest, reflect and grow (often it manifests as time to fix bugs and just not be the star of the show).
highfrequency 9mo ago
> you need to stay off the critical path. As soon as you start handling essential tickets, you’ll block your team when managerial work pulls you away. Very well put
Insanity 9mo ago
Similar to the article, I always think of it as my job to make sure the team has the mechanisms in place to continually deliver high quality software, even without me. I once had a senior engineer blatantly say: “that means you’re just being lazy, your team should be dependent on you”. Scary to think that engineer was a manager earlier in his career.
mtippett 9mo ago
Lots of good advice there. I did pause on the "Be risk adverse". My take is - Be Risk Aware - know them, quantify them, manage by mitigating or having contingencies - Don't be Risk Averse - Averse means being avoidant of risks or disinclined, it's safer, but it means risks aren't taken. - Don't be Risk Paranoid - Protecting against unseen risks wastes time and efforts.
MORPHOICES 9mo ago
[dead]
dakiol 9mo ago
As an IC that's been in the industry for over a decade, I don't see myself jumping into the management track. I just can't. I see my calendar and I see few meetings, and typically I have the power to move some of them (because some of them are arranged by me). I see my manager's calendar and it's constantly packed with meetings he probably cannot move. Worse than that, I see for instance he has one meeting at 10, then another at 12, then another at 3 and then another at 5. Like, you cannot escape that hell. I start my work at 10, work solid 4-5 hours or so and then close the laptop. I cannot sacrifice that kind of freedom
- willio58 9mo ago
  As someone who did get on the management track a couple of years ago myself, I think it’s great you have that perspective. I miss being able to turn on some tunes, code for a few hours, and call it good for the day. At the same time, I have always naturally fell into leadership positions I think mainly because I like helping people make better decisions. As an IC, I despised broken processes, bad decisions from product, and overall poor management. As an engineering manager, I have some amount of control over these things and I hope those I manage, as well as our users, have benefited from me being in this role. A few examples of things I heavily influenced: - reduction in investment of time, effort, and cost going to offshore engineering. We’ve reduced bugs and effort from our engineers in coordinating between disparate time zones. - advocacy of a design system shared between design and dev teams. We now have one. - reduction in the amount of meetings our devs are expected to attend weekly, increasing time they can spend building - heavily advocating to reduce number of clicks for our users to get where they need to be, benefit UX greatly - better defined incident management process It’s not perfect though, the amount of control I have is still limited, and I am in meetings basically all day sometimes. While I will say that would have sounded like hell to me a couple of years ago as an IC, I have been able to sway the direction of the company meaningfully in ways that feel ultimately more impactful than what I could have done jamming on some code in the same amount of time. The cost of doing so is a little more stress, but hey I get to do so from the comfort of my home and I’m allowed a good amount of schedule flexibility outside of some specific meetings each day. It’s definitely not for everyone though!
- kaydub 9mo ago
throwaway8177 9mo ago
This is a great list! The biggest lesson for me was that your job as a manager is to be the soft power representing the authority of the investors. Everything else you hear about management is people rationalizing their role and figuring out how to tow the line. That's why it's so hard and stressful. The hardest lesson comes when you're ordered to fire someone from your team. HR has decided to implement a performance rubric and wants to maintain the company's position in the hiring market place as a competitive place to work. You must fire the poorest performing member of your team. Who do you pick? That's the essence of management. Who do you reward, who do you punish, how do you show that you're towing the line? Most folks, myself included, are promoted into an EM role. No training. No certifications. If you're lucky you get a few training videos from HR if the company you work for is big enough to have an HR department. As an EM you are now in charge of the careers of the people who work under you. This is why you get such a high variation in the quality of EMs. Some people are a nightmare to work with. If they get a bad impression of you there's nothing you can do. You're cooked when it comes time for that manager to let someone go. There are no objective metrics. They have to pick someone and they will find the reasons. I left management because I couldn't handle it. Too stressful.
nitwit005 9mo ago
> Everyone needs to care about the Product > A few times in my career as a developer, I wondered, “Who is this feature even for? Who will use it?” No one on my team knew. We were doing it because we were told to. Morale was low. We felt we were working on things that didn’t matter - and we were. Eventually, our team disbanded, and engineers scattered across other projects. There's no way they had no idea what it was for. They thought the idea was dumb, and they wanted off a sinking ship.
Buttons840 9mo ago
I struggled as a team lead, a manager of sorts. I was expected to do some programming, and so the "failures" of the team (which were often just normal human limitation) I would deal with by personally doing all the work myself. Has anyone else experienced this?
FAFOAlex 9mo ago
[flagged]
michaelcampbell 9mo ago
One thing I learned in 30+ years as a software developer is a static blog site doesn't need to "time out".

577 points by jampa 9mo ago

Whoa an EM that talks to clients? A rare treat. I just got a browbeating because I (an IC) didn't jump at the chance to do more (that) for ~free~ growth. Ahem. Mind you, we have piles of both kinds of PMs: product, project. Best I can tell, they play video games between calls/status updates. Forgot the blur on more than one occasion. Clownshow, myself included.

deleted 9mo ago
[deleted]

andreidbr 9mo ago

I wholeheartedly agree with point 7 Your goal is for your team to thrive without you. I spent a lot of time also playing a Scrum Master role in addition to my regular duties. So much so that some managers asked me to pursue this full time. I always explained that my goal is to be there just as a point of contact and that the team should be able to manage itself. Sadly, I see so many managers, scrum masters, or even regular engineers consider this as a dumb approach to make yourself replaceable. If you don't hoard knowledge then you'll be laid off when the company's numbers look bad.

soulofmischief 9mo ago
I've always told my engineers that their job is to get me fired for redundancy.
- pjbster 9mo ago
  I always say that a job without an end date is a lifestyle.
  - OhMeadhbh 9mo ago
    I'm stealing that one.
DevKit 9mo ago
Agreed, I was fortunate enough to learn this lesson early in my management career when I was passed over for a promotion I felt I deserved for someone who's team was able to operate without them. Looking back, I know this is why he got the role rather than me, my team couldn't live without me whereas his could and therefore he could take on the expanded role.

jofzar 9mo ago

Damn, this person looks like a good manager. These are all things I have seen in my good managers over the years when I had them.

andros 9mo ago
Yes, he has a lot of accumulated experience!
- OhMeadhbh 9mo ago
  If only all experienced managers could have developed the same amount of understanding.
lloydatkinson 9mo ago
I've had one good manager and I concur. As valuable as gold.

andros 9mo ago

I completely agree with point 9

pplonski86 9mo ago
Maybe point 9, trust but verify, should be extended to AI coworkers as well. I would love to have tools to verify AI code by quantity.
- jrflowers 9mo ago
  Whatever human that is in charge of the chat bots is your coworker. That person that is responsible for the output of the bots is the one that you would trust but verify with.

junon 9mo ago

This is clearly a good EM. Agreed with pretty much everything, being on the engineering side. Stuff that seems trivial and obvious but that a lot of EMs miss.

satisfice 9mo ago

Why do people espouse goals like “not to be needed?” I never understood that. It sounds like LinkedIn virtue signaling. It’s a capitalist talking point along the lines of “I seek to be good and inexpensive capital for my corporate masters.” My goal is to help my team succeed in such a way as to keep my job or else get a better one. Being “not needed” hardly serves that goal. Look around you. We are in a world that is turning away from middle managers. Don’t play into their hands.

mulmboy 9mo ago
Because it's a good heuristic for a functional and resilient team. People don't usually means it literally, more like "if I disappeared it should be pretty painless for the team to continue along for a month or so and to find and onboard a replacement".
Keirmot 9mo ago
The way I read it is not to be needed for normal functionality of the team, not to "not be needed" at all. Akin to a ship's captain - for the most part a ship works without a captain just fine, but that doesn't make the captain's job redundant, it's just he's needed for specific occasions, otherwise, he's just making sure the crew works as a well oiled machine.
Rainbooow 9mo ago
I think the points made at mostly for a front-line manager though, not so much for a middle manager.
skirge 9mo ago
cause it means: I lead them so good that I do nothing and still get my salary.
- mcapodici 9mo ago
  the coder's equivalent is not get paged (or bug reports). the system run's itself with no dramas, so I get to work on improving it.
- 9mo ago

vasco 9mo ago

> People above you have limited time to focus on your specific issues. You can’t info dump on them. If they take a misguided action based on what you tell them, it will be your fault This bit is useful to everyone, and many people never learn it and get jaded about work itself! They paint themselves into a dilbert strip without realizing. And then of course there's also bad bosses, but any work advice is like relationship advice, it really depends on the specific people involved.

oldpersonintx 9mo ago

[dead]

20260126032624 9mo ago

11. What works in one country doesn't necessarily work in another.

palata 9mo ago

> That’s why lying or withholding information that affects them causes irreversible damage. They might not leave immediately, but they will resent you. [...] I have a friend who still resents a manager for a lie told three years ago. Oh yeah. To be fair, it's not only the case for managers. If a colleague lies to me, they lose my trust. But I have never had that... why would a colleague lie to my face or withhold information? That's a thing bad managers do. When a manager lies to me (or withhold information), it's never one time only; it's the way they work. And when they work like this, they are not in my team. They play against me, so I play against them.

snarf21 9mo ago
There is an old saying that rings true here: "People don't quit jobs, they quit bosses."

vachina 9mo ago

All these properties of a good manager will come naturally with humility. Because being humble makes you more receptive.

CBLT 9mo ago
I've had great experiences being managed twice by very humble engineers who've made the transition to EM. Both were sacked within the year by their boss because they didn't play the corporate politics game.
- Schlagbohrer 9mo ago
  It's so disheartening to learn that one works for a manager who doesn't care about having the most skilled team, or best product, but rather someone who has selected for "Who will kiss up to me no matter what? Who will never tell me anything I don't want to hear?"

Traster 9mo ago

>I wondered, “Who is this feature even for? Who will use it?” No one on my team knew. I think there's another key here - Don't assume someone else knows something. If you don't know why something is done some way, find out who does and make sure they do. I've been in so many situations where the organization gets complex - person A is loaned over here or person B is working on project X because team Y needed feature Z. So frequently you'll find out that core assumptions have been made because everyone involved was only half-involved and either kind of assumed someone else was taking care of it, or (more frequently) knows the assumption is wrong but is choosing not to say so for political reasons.

Schlagbohrer 9mo ago
I sympathize with keeping one's mouth shut for political reasons. Having a boss who angrily shouts at anyone who dared use their own brain and offer an idea, I learned to keep my mouth firmly shut even if i saw countless problems coming down the road.
- arendtio 9mo ago
  It is one thing to do that while you have that boss, but something completely different to keep acting that way even when you have a different boss. The more people you have on a team who keep their mouths shut, the less effective it will be.
- Traster 9mo ago
  It's totally understandable, but it would have been good to have been given a heads up - I'm totally new at the company (new to the industry), assume one of these people knows what they're doing. In the end I got a new boss and convinced him to take a different approach once the first approach failed, but I would not have blamed my new boss for just binning the entire project and getting rid of me.
OhMeadhbh 9mo ago
When I was in the Marines, we had a rule of thumb that every Marine needed to know their own mission and the mission of units two or three echelons above them. So individual Marines needed to know their mission, their platoon's mission and their company's mission. Company commanders needed to know their mission, their battalion's mission and the division's mission. More specifics for echelons closer to you. This is complicated by the fact that Marines deploy as MEUs, MEBs and MEFs [1] which aren't "pure" echelons, but it's a rule of thumb and guiding principle more than a hard and fast requirement. I've ALWAYS been annoyed by engineering organizations that don't think developers at the leaf nodes of the org chart need to know what's going on. Devs may not do anything with the info, but letting people in on what's happening seems to send the message that "management thinks you're important enough to hear what we're working on" and every now and again, individual devs need to make decisions that depend on these more abstract / higher-level goals. 1. https://en.wikipedia.org/wiki/Marine_air%E2%80%93ground_task_force https://en.wikipedia.org/wiki/Marine_air%E2%80%93ground_task...

Schlagbohrer 9mo ago

Good advice in the last point about interviews. "While you're scheduling the seventh round, good hires are already accepting a job elsewhere." I gave up on a job I was lukewarm about when, after flying me there for an all day site visit and hours and hours of technical interviews, they then wanted me to do 3 days of video calls with various groups around the company! People i could have simply met for 15 minutes in person when I was there. In all the time this took I accepted a much better job closer to home.

MarginalGainz 9mo ago

[dead]

OhMeadhbh 9mo ago

> "Most engineers prefer feeling appreciated over having a ping-pong table." Truer words have never been spoken. Note the OP put the word "Most" in there. Sure... there are a few ping-pong fanatics, but not as many as there are humans who like an emotionally fulfilling work environment. A related sentence I've uttered is "Most engineers prefer more control over their daily tasks than cash bonuses." But again, the word "Most" is doing a lot of heavy lifting here. My experience is no more than 25% of devs will trade cash for micro-management. YMMV.

tmarice 9mo ago

This kind of EM-focused articles often mention "coaching" and "career growth" -- I always wonder what does this concretely mean. Are they all managing teams of juniors straight out of college? What can a career EM, or even an engineer-to-EM convert who has been out of the coding game for more than a few years, teach a non-junior engineer on their team? I understand we can talk and exchange our concrete life experiences, same as I would talk to and listen to any other person, but the word "coaching" implies one party is superior to the other in one very concrete area.

__alexs 9mo ago
I am not an EM (anymore) but I see a lot of more junior engineers struggle with ambiguity and complex decision making in general. It is not uncommon to end up in situations where there are not clear right answers and developing the techniques as an individual, and as a technical contributor to navigate these well is tricky. I don't think this is an EM specific function at all though and is just something more experienced people should be doing for their team. I think the EM definitely has a role in making sure people identify that they could benefit from that kind of help and make sure they find it, but doing the actual coaching is optional.
GabriDaFirenze 9mo ago
Coaching doesn't imply superiority. Most coaching can be done with little to no context and the goal is to guide the other person in finding the right answer on their own. I think you might be confusing coaching with mentoring. As an example, I attended a coaching training session and when we broke out in groups I played the coach role. The other individual brought up a concrete issue they were having and I was able to unblock them and I never met that person before. I was their guide even though I had no context (but I have experience mentoring and coaching). I've been a manager for years and there's a lot outside of raw technical ability that a good coach and mentor can keep you honest on. Rarely will you find someone who's reached full potential or who doesn't want to improve at all (maybe surprisingly based on your comment but I have found seniors to be the most eager to grow)
tl 9mo ago
Most of the job is noticing friction and clearing paths — which requires context and trust more than technical superiority. In practice: Start a note for each engineer you manage. Fred Brooks called this a "career file". Start by writing down things that frustrate them enough to complain about publicly. Add hurdles that come up in their one-on-one. Identify problems you can solve, problems you understand but cannot solve right now and problems you do not understand. Then put on your PM hat; sort by priority and execute.

crjohns648 9mo ago

> A good manager is more like a transparent umbrella. They protect the team from unnecessary stress and pressure, but don’t hide reality from them. I'm absolutely going to steal this metaphor going forward. Being a "transparent umbrella" does require knowing the personalities of your reports, some people do get distracted when they think higher-up decisions or unhappiness are going to affect their team. Most people, however, really appreciate the transparency. It helps them feel more in control when they know what is happening around them, and when things do change they can tie it back to something that was said previously.

fidansin 9mo ago
Kinda like; You got to do, what you got to do.
- ghaff 9mo ago
  The basic question is how much context do you actually want if you can't really affect it and it's therefore more of a distraction than useful input. Some is almost certainly useful but it probably varies by individual and situation.
gambutin 9mo ago
Honestly, I’m not sure. If I know what was going on transparently I am stressed. As an ordinary employee, I don’t need to know everything and therefore don’t need to worry about it.
- _blk 9mo ago
  As a leader, it's important to provide not just the meat but also the veggies. What people end up eating is up to them, but serve the full course! If as a ME, I start deciding who needs to know what, information will be perceived as incomplete because people always talk and engineer are often smart enough to read between the lines. So the transparent umbrella is a great analogy. Communicate bad news as fast and coherently as possible - group meeting with open questions works well for me but be ready to address the potential fears: "In my current assessment, that's not going to be a problem, I'll let you know if that changes." and of course "Thanks for asking, I didn't consider that and I don't know yet. I'll clarify" is a valid answer, if you do indeed clarify. If you're genuinely stressed with that, talk to your lead about it and they'll find a way to filter a little more while not giving you the feeling of being left out.

v_CodeSentinal 9mo ago

The point about 'no such thing as a free lunch with processes' is something I wish more junior EMs understood. I've seen so many teams treat process as a pure 'fix', ignoring that it's always a trade-off: you are explicitly trading velocity for consistency. Sometimes that trade is worth it (e.g., payments), but often for internal tools, you're just paying a tax for consistency you don't actually need.

talkingtab 9mo ago

Enough already. The way to determine what kind of manager a person is, is to listen for the context they use. For an extreme hypothetical example, if you hear a manager talk about locking their team in their cells every night, you will know something about their context. If the manager says "They look to you for leadership and clarity", you know something. It they quote Jeff Bezo, that provides more definition. The lesson to learn from this article is not the words, but the context. What is the context you find in this article? How does this person talk about other people? What assumptions are inherent in this article? If you find this normal, what does this say about your assumptions? What I have learned from my years of being an engineering manager is that the corporate model of software development is fubar.

PlatoIsADisease 9mo ago
> How does this person talk about other people? I find myself referring to my contractors as: Workers. What does that mean about me? I can't call them employees. I read the communist stuff a while ago and decided I didn't want to be exploited, so I thought this was just the proper terminology. But people on the internet loath being called a worker and have called me out on this. Meanwhile I yoyo between to nice and too hard... I think I'm naturally too nice to the point of failure. I seem to only be 'too hard' for a few months before I go back. Thank god my industry is high demand, I think even with bad management we will survive. (I got a masters in Engineering Management + read 10 books, but management/supervision orthodoxy is diverse and contradictory.)
deleted 9mo ago
[deleted]

videogreg93 9mo ago

> Everyone needs to care about the Product This isn't the first time I hear this, but I always have a bit of trouble with this one. It's one thing to take a step back and think about the actual product and how it'll be used, but I think it's presumptuous to think that software engineers know what makes a product good or not. We don't say "Everyone needs to care about software architecture, even Product", so I'm not sure why we think the flip side of that is true.

1980phipsi 9mo ago
At the end of the day, the goal is to make a product that people find useful. How that ends up happening is almost completely irrelevant to the people actually using the product.
SkyPuncher 9mo ago
If you consider product as a proxy for customer, I think it gets a bit easier to understand. Customers don’t care about architecture (unless you have a technical product where they do actually need to know architecture). They don’t care about many of the details. They just want their problem solved. For software engineers, our goal isn’t to necessarily know what makes good product or not - but we do need to make sure that what we’re building solves an actual customer problem or need.
tristor 9mo ago
> We don't say "Everyone needs to care about software architecture, even Product" We absolutely should say that. I was an engineer for 13 years and have now been in Product for 8 years. I work on a highly technical Product team, and it is absolutely an expectation for myself, my peers, and my reports that we should ensure we fully understand our Product, including its software architecture, and have an opinion about it. Engineering ultimately decides the "How", but they cannot do that effectively if Product cannot articulate an opinion about the architecture guided by an understanding of things like expected scale, potential future integration decisions, and other cross-organizational expectations that may not yet be codified. In general, Product should have an educated opinion on anything that is a one-way door, and so should Engineering. It should not be a unilateral decision, and if either party is unable to form an informed opinion, that's an organizational miss.

hnthrow0287345 9mo ago

>The most common reason companies fail is creating products that don’t deliver value to users, causing them not to pay. >“Oh, but I have a PM for that,” you might say. But having a PM is not enough. It should be, that's literally their job. Developers and EMs shouldn't be doing that part for them. In the same way developers need to know how to ifs and loops, Product Managers need to find out which features to build and user pains to fix. Maybe, just maybe, we need to stop raising the bar for interviewing developers and start raising the bar for the other people working with developers, instead of getting developers to compensate for shortfalls.

AndrewKemendo 9mo ago
There’s a reason you never see posts like: “My jump from BD to software engineer” I’ve never met a sales person as broadly capable as your average engineer. The curse of competence is organizational as well
- ghaff 9mo ago
  Because your average engineer is so good at creating customer relationships and generating revenue. Customer relationships are certainly more important in some categories than others but sales is certainly key in a lot of B2B organizations.
  - AndrewKemendo 9mo ago
    I guarantee I’ll be more successful with a group of engineers doing sales than I would a group of sales people trying to do engineering
    - ghaff 9mo ago
      Both would generally be crap in isolation. (Assuming non-overlapping skill sets such as solution/system engineers.)
derwildemomo 9mo ago

SkyPuncher 9mo ago

This is a good article. In fact one of my favorites now (will be sending it to my peers). There’s a point buried in it that I increasingly come to believe is missed in nearly every single management book and management advice I’ve read. It’s almost there in point 1, but under “don’t have a PM”. None of these points matter if you’re not creating value for your company. That is the job of a manager - get your team to create value. I’ve been increasingly disgruntled with most management advice because it overlooks this key point. I felt like one of the biggest steps back I took in my career was when one of my companies had our management attend training that taught these skills and then the company emphasized these skills repeatedly. Suddenly my career stagnated. I had managed before, I had led before, I had delivered results before. But my growth came grinding to a halt. I was following all of these tips and tricks while overlooking the implicit thing - deliver value. In many, the same ways, I’ve become wary of any company beliefs, values, or guidelines that aren’t clearly working towards making the company money. They’re really just distractions for the underlying goal.

joshcsimmons 9mo ago

Correct on all points! Very well put - you sound like an excellent manager. As always the difficulty is in getting people outside your team to realize that the 60% cheerleading bit is crucial, many will see this as a waste of time that doesn't create "business value", as if the only business value was measured in lines of code.

bradley13 9mo ago

"Delegate everything" - delegation is hugely important. But not everything, obviously, as a team lead your responsibility as "transparent umbrella" cannot be delegated. It also sounds like he is talking mostly about external projects. For internal projects, you really do serve as a shield. One project, I spent my first months teaching the internal customers that they were not allowed to talk to my people. They had become accustomed to telling individual developers "I want feature X", which cause total chaos. I stood between the customers and my developers - at the beginning, sometimes literally blocking the office door - and said: my team, my job, you talk to me.

rendaw 9mo ago

> Never ask the interviewer what they expect from a manager. Some managers assume their experience is industry standard and might find that question odd. I was in an interview and asked this, and the interviewer got annoyed and wouldn't give me an answer. It sounds like this sort of experience may be more common than I thought.

gorpomon 9mo ago

This is all really good stuff, and thankfully I feel like I have been practicing a fair bit of this already (so, I could be biased here!). I like the umbrella callout especially, that one took me a few years to really internalize. "Protection" isn't as beneficial as "good stress" is. You don't just protect muscles, you use them in a responsible manner to get stronger. I've started trying to ensure my team gets a lot of "good stress" (so projects that grow careers, develop expertise, etc), while getting some concentrated down time after to rest, reflect and grow (often it manifests as time to fix bugs and just not be the star of the show).

highfrequency 9mo ago

> you need to stay off the critical path. As soon as you start handling essential tickets, you’ll block your team when managerial work pulls you away. Very well put

Insanity 9mo ago

Similar to the article, I always think of it as my job to make sure the team has the mechanisms in place to continually deliver high quality software, even without me. I once had a senior engineer blatantly say: “that means you’re just being lazy, your team should be dependent on you”. Scary to think that engineer was a manager earlier in his career.

mtippett 9mo ago

Lots of good advice there. I did pause on the "Be risk adverse". My take is - Be Risk Aware - know them, quantify them, manage by mitigating or having contingencies - Don't be Risk Averse - Averse means being avoidant of risks or disinclined, it's safer, but it means risks aren't taken. - Don't be Risk Paranoid - Protecting against unseen risks wastes time and efforts.

MORPHOICES 9mo ago

[dead]

dakiol 9mo ago

As an IC that's been in the industry for over a decade, I don't see myself jumping into the management track. I just can't. I see my calendar and I see few meetings, and typically I have the power to move some of them (because some of them are arranged by me). I see my manager's calendar and it's constantly packed with meetings he probably cannot move. Worse than that, I see for instance he has one meeting at 10, then another at 12, then another at 3 and then another at 5. Like, you cannot escape that hell. I start my work at 10, work solid 4-5 hours or so and then close the laptop. I cannot sacrifice that kind of freedom

willio58 9mo ago
As someone who did get on the management track a couple of years ago myself, I think it’s great you have that perspective. I miss being able to turn on some tunes, code for a few hours, and call it good for the day. At the same time, I have always naturally fell into leadership positions I think mainly because I like helping people make better decisions. As an IC, I despised broken processes, bad decisions from product, and overall poor management. As an engineering manager, I have some amount of control over these things and I hope those I manage, as well as our users, have benefited from me being in this role. A few examples of things I heavily influenced: - reduction in investment of time, effort, and cost going to offshore engineering. We’ve reduced bugs and effort from our engineers in coordinating between disparate time zones. - advocacy of a design system shared between design and dev teams. We now have one. - reduction in the amount of meetings our devs are expected to attend weekly, increasing time they can spend building - heavily advocating to reduce number of clicks for our users to get where they need to be, benefit UX greatly - better defined incident management process It’s not perfect though, the amount of control I have is still limited, and I am in meetings basically all day sometimes. While I will say that would have sounded like hell to me a couple of years ago as an IC, I have been able to sway the direction of the company meaningfully in ways that feel ultimately more impactful than what I could have done jamming on some code in the same amount of time. The cost of doing so is a little more stress, but hey I get to do so from the comfort of my home and I’m allowed a good amount of schedule flexibility outside of some specific meetings each day. It’s definitely not for everyone though!
kaydub 9mo ago

throwaway8177 9mo ago

This is a great list! The biggest lesson for me was that your job as a manager is to be the soft power representing the authority of the investors. Everything else you hear about management is people rationalizing their role and figuring out how to tow the line. That's why it's so hard and stressful. The hardest lesson comes when you're ordered to fire someone from your team. HR has decided to implement a performance rubric and wants to maintain the company's position in the hiring market place as a competitive place to work. You must fire the poorest performing member of your team. Who do you pick? That's the essence of management. Who do you reward, who do you punish, how do you show that you're towing the line? Most folks, myself included, are promoted into an EM role. No training. No certifications. If you're lucky you get a few training videos from HR if the company you work for is big enough to have an HR department. As an EM you are now in charge of the careers of the people who work under you. This is why you get such a high variation in the quality of EMs. Some people are a nightmare to work with. If they get a bad impression of you there's nothing you can do. You're cooked when it comes time for that manager to let someone go. There are no objective metrics. They have to pick someone and they will find the reasons. I left management because I couldn't handle it. Too stressful.

nitwit005 9mo ago

> Everyone needs to care about the Product > A few times in my career as a developer, I wondered, “Who is this feature even for? Who will use it?” No one on my team knew. We were doing it because we were told to. Morale was low. We felt we were working on things that didn’t matter - and we were. Eventually, our team disbanded, and engineers scattered across other projects. There's no way they had no idea what it was for. They thought the idea was dumb, and they wanted off a sinking ship.

Buttons840 9mo ago

I struggled as a team lead, a manager of sorts. I was expected to do some programming, and so the "failures" of the team (which were often just normal human limitation) I would deal with by personally doing all the work myself. Has anyone else experienced this?

FAFOAlex 9mo ago

[flagged]

michaelcampbell 9mo ago

One thing I learned in 30+ years as a software developer is a static blog site doesn't need to "time out".