> 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.
> They protect the team from unnecessary stress and pressure, but don’t hide reality from them.
I was going to highlight this as well, but it is also one of the trickiest parts of the equation, because by definition this inevitably involves a lot of politics and social implications.
What I have learned over the years: let the overall direction, and also the overall competitive pressures, filter down through your umbrella. But shield them from the details and your specific efforts here, unless it is relevant.
Maybe even more important, though - recognize inflection points in your company and your group. How you manage during routine times and during stressful times may well be very different. If they're not, then you have a serious problem.
I agree with that. It's useful for (most) people to understand the overall environment the company is operating in. Probably less every top-down decision the company is making.
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.
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.
I am an EM that manages several senior engineers currently. I find it super common for senior engineers to get promoted mostly on technical merit, we end up thinking the rest "can be coached". Or it's coaching to the next level. Here are some areas I coach them on:
- influencing without authority. Managing up. Leadership.
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)
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.
I think the biggest thing I've found myself teaching my younger colleagues is basically the internals of the systems or in what ways some of the things they've written might fail.
I haven't written any production C++ in about 2-3 years and honestly lost track of all the language updates since c++14. But when I explained how the code they write gets translated to assembly and runs on the machines, that's what i felt demystified the large codebases to my younger colleagues.
Same with many other topics - the event loops behind the JavaScript async/await, memory mapped io behind every read/write calls their operating system syscalls, basic data structures/algorithmic complexity behind their DB queries, scenegraphs and graphics APIs behind user interfaces etc... especially when pair programming.
I don't think I'm superior to them in any of these areas. I feel I'm fairly slower than them when writing code in any of these things. I definitely haven't kept up with all the changes in web frameworks or CLI tools or vim plugins. But sharing the behind the scenes knowledge helps them write better code is what i felt.
In my experience, I have used coaches that don’t have more technical skill than me, but are able to provide insight, questions, and provoke me to think through my problems in ways I might not have otherwise.
I break things down into coaching vs training vs mentorship.
Training is when you need to learn a very specific skill from someone that knows more than you. A great example is learning how to drive - it requires training from someone who knows more than you.
Mentorship is when you need to grow more holistically and are learning from someone that is significantly more advanced in your chosen area of study than you. Usually this involves not just technical training, but also a mindset that you wish to learn. Examples of this are apprenticeships or when you seek out a mentor that you think has done well and wish to learn from.
Coaching is when someone may not have more technical skill than you, but is still able to help you improve by probing, prompting, reflecting, or observing. A great example are sport coaches, who are not necessarily more skilled than many of the players they coach.
These are loose and blurry definitions, but I hope it helps frame another perspective on coaching.
Coaching in my role is mostly about seeing the person up for promotion and helping them focus on the right stuff for the teams success. Even great senior engineers sometimes lose focus or miss the sentence in s career ladder that doesn’t mesh with what they want to be doing.
I’ve got a senior IC who is always hesitant to reach out to non-engineers, so to coach him I’m constantly asking him to reach out directly. It will improve his impact if he does so.
The mindset shift from IC to EM is very complex. And the newly appointed managers don't always know how to not be a programmer when in that role. It sometimes bleeds into the reports' work and damages than helping.
I guess the "coaching" is to understand that mindset shift.
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.
Dude, soft skills. 80% of any job, software development especially, is messy human problems. Engineers more than anyone can generally benefit from improving these skills.
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.
>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.
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.
My dad is a retired Marine and I learned several things from the NCO system and Marines in general: good leaders (EM/Sergeant) will generally never ask you something they cannot also do (implies they are your peer, even if they are not), and Marine Corps manuals are able to take anyone who can read and make them operate technical things. Their manuals are written in a very direct stepwise way to get people up to speed in doing whatever task they are assigned which I learned early on is just plain good documentation.
Servant leadership works really well when you have high agency individuals, and can grow high agency individuals. I have definitely been on the other side of that with control freak machiavellian / nearly adversarial leaders as well.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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?"
> 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.
> "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.
> 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.
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.
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.
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.
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.
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".
“Don’t be needed” isn’t “don’t be valuable.” The EM should not be a bottleneck. The EM should be able to take a vacation without being paged. (So should anybody on the team!)
My teams would slow down without me because I can due process tasks more efficiently, but nothing demands me to be in the loop.
Someone I know used to be pretty senior at a major SV company. Over dinner one night, he told me that the CEO would take vacations with instructions to the effect of "handle it" if something comes up. (Assume it wasn't absolute but that was the basic gist.) Apparently, a new PR head came in and was like "I can't work under that condition" and quickly left.
The goal should be to have teams who want you to be supporting them, not need you to be supporting them. Getting teams to the point where they don't need you isn't actually that hard. They might be only performing at 50% effectiveness, but that's fine if the work is getting done. You should build a relationship with the teams so they want you to support them to get to 90% or even more.
If your teams fail to function without your help then you're clearly not supporting them well enough, and you can't take a vacation or go off sick or be promoted. That is not optimal for anyone.
> 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.
That's true for a junior engineer, but the more senior engineers should be given a view into the organization's priorities and business challenges.
> They protect the team from unnecessary stress and pressure, but don’t hide reality from them.
I was going to highlight this as well, but it is also one of the trickiest parts of the equation, because by definition this inevitably involves a lot of politics and social implications.
What I have learned over the years: let the overall direction, and also the overall competitive pressures, filter down through your umbrella. But shield them from the details and your specific efforts here, unless it is relevant.
Maybe even more important, though - recognize inflection points in your company and your group. How you manage during routine times and during stressful times may well be very different. If they're not, then you have a serious problem.
I agree with that. It's useful for (most) people to understand the overall environment the company is operating in. Probably less every top-down decision the company is making.
Kinda like; You got to do, what you got to do.
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.
[dead]
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.
I am an EM that manages several senior engineers currently. I find it super common for senior engineers to get promoted mostly on technical merit, we end up thinking the rest "can be coached". Or it's coaching to the next level. Here are some areas I coach them on:
- influencing without authority. Managing up. Leadership.
- getting work prioritized
- providing useful performance feedback (promos etc)
- coaching and giving feedback to early career engineers
- communicating ideas effectively
- developing 1YP+ plans for their areas.
- idk, there are a lot, senior engineers are rarely "complete"
I'm sorry, but if a senior engineer needs coaching on getting work prioritized, they are not a senior engineer.
1 reply →
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)
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.
I think the biggest thing I've found myself teaching my younger colleagues is basically the internals of the systems or in what ways some of the things they've written might fail.
I haven't written any production C++ in about 2-3 years and honestly lost track of all the language updates since c++14. But when I explained how the code they write gets translated to assembly and runs on the machines, that's what i felt demystified the large codebases to my younger colleagues.
Same with many other topics - the event loops behind the JavaScript async/await, memory mapped io behind every read/write calls their operating system syscalls, basic data structures/algorithmic complexity behind their DB queries, scenegraphs and graphics APIs behind user interfaces etc... especially when pair programming.
I don't think I'm superior to them in any of these areas. I feel I'm fairly slower than them when writing code in any of these things. I definitely haven't kept up with all the changes in web frameworks or CLI tools or vim plugins. But sharing the behind the scenes knowledge helps them write better code is what i felt.
In my experience, I have used coaches that don’t have more technical skill than me, but are able to provide insight, questions, and provoke me to think through my problems in ways I might not have otherwise.
I break things down into coaching vs training vs mentorship.
Training is when you need to learn a very specific skill from someone that knows more than you. A great example is learning how to drive - it requires training from someone who knows more than you.
Mentorship is when you need to grow more holistically and are learning from someone that is significantly more advanced in your chosen area of study than you. Usually this involves not just technical training, but also a mindset that you wish to learn. Examples of this are apprenticeships or when you seek out a mentor that you think has done well and wish to learn from.
Coaching is when someone may not have more technical skill than you, but is still able to help you improve by probing, prompting, reflecting, or observing. A great example are sport coaches, who are not necessarily more skilled than many of the players they coach.
These are loose and blurry definitions, but I hope it helps frame another perspective on coaching.
Not an EM, but definitely think a strong technical EM can provide valuable feedback when it comes to system design and data modelling.
Top tier sports people still have coaches. Some even have multiple coaches. Musicians have managers.
Unlike coaches for kids/ novices these folks aren’t necessarily better at the craft.
Yet, they (ideally )have a outside perspective that would improve an individual in their craft.
How does a football coach do their job if they can’t run or throw or block as well as the players?
Coaching in my role is mostly about seeing the person up for promotion and helping them focus on the right stuff for the teams success. Even great senior engineers sometimes lose focus or miss the sentence in s career ladder that doesn’t mesh with what they want to be doing.
I’ve got a senior IC who is always hesitant to reach out to non-engineers, so to coach him I’m constantly asking him to reach out directly. It will improve his impact if he does so.
The mindset shift from IC to EM is very complex. And the newly appointed managers don't always know how to not be a programmer when in that role. It sometimes bleeds into the reports' work and damages than helping.
I guess the "coaching" is to understand that mindset shift.
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.
Dude, soft skills. 80% of any job, software development especially, is messy human problems. Engineers more than anyone can generally benefit from improving these skills.
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.
>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.
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...
My dad is a retired Marine and I learned several things from the NCO system and Marines in general: good leaders (EM/Sergeant) will generally never ask you something they cannot also do (implies they are your peer, even if they are not), and Marine Corps manuals are able to take anyone who can read and make them operate technical things. Their manuals are written in a very direct stepwise way to get people up to speed in doing whatever task they are assigned which I learned early on is just plain good documentation.
Servant leadership works really well when you have high agency individuals, and can grow high agency individuals. I have definitely been on the other side of that with control freak machiavellian / nearly adversarial leaders as well.
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.
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.
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.
> 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.)
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.
Yes, he has a lot of accumulated experience!
If only all experienced managers could have developed the same amount of understanding.
I've had one good manager and I concur. As valuable as gold.
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.
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.
I've always told my engineers that their job is to get me fired for redundancy.
I always say that a job without an end date is a lifestyle.
1 reply →
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.
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.
All these properties of a good manager will come naturally with humility.
Because being humble makes you more receptive.
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.
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?"
> 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.
There is an old saying that rings true here: "People don't quit jobs, they quit bosses."
> "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.
> 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.
I completely agree with point 9
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.
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.
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.
11. What works in one country doesn't necessarily work in another.
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.
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.
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".
“Don’t be needed” isn’t “don’t be valuable.” The EM should not be a bottleneck. The EM should be able to take a vacation without being paged. (So should anybody on the team!)
My teams would slow down without me because I can due process tasks more efficiently, but nothing demands me to be in the loop.
Someone I know used to be pretty senior at a major SV company. Over dinner one night, he told me that the CEO would take vacations with instructions to the effect of "handle it" if something comes up. (Assume it wasn't absolute but that was the basic gist.) Apparently, a new PR head came in and was like "I can't work under that condition" and quickly left.
The goal should be to have teams who want you to be supporting them, not need you to be supporting them. Getting teams to the point where they don't need you isn't actually that hard. They might be only performing at 50% effectiveness, but that's fine if the work is getting done. You should build a relationship with the teams so they want you to support them to get to 90% or even more.
If your teams fail to function without your help then you're clearly not supporting them well enough, and you can't take a vacation or go off sick or be promoted. That is not optimal for anyone.
I think the points made at mostly for a front-line manager though, not so much for a middle manager.
cause it means: I lead them so good that I do nothing and still get my salary.
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.
[dead]
[dead]