> 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.
>> 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.
There is the expectation that the manager knows who will be distracted. This is a basic part of knowing your people. I know which of my colleagues is going to get distracted without having the level of communication that my manager has. On one extreme, they just forward information knowing a report can work with it. One the other, the manager has to translate and communicate every element.
Ideally, the manager is already working on a way to ensure their report can handle transparency because that means they can work autonomously. You can't have individual contributors lead, if they are going to run into issues as soon as they discover what is going on overhead. They may not understand it yet, but they should have coping and mitigation strategies.
Engineers can be the worst group you could deal with when it comes to overhead conversations when they expect things to be orderly. Your organization is failing when everything has to go through managers and people can't operate independently.
My favorite manager told me a similar analogy before I left, but with a caveat; a good manager has to provide cover for the team, but it's up to the team to hold the manager up - just like an umbrella.
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.
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 does not imply superiority. I doubt any sports coach could substitute any player in a competitive game, yet they can coach them to become better version of themselves.
What engineers usually struggle with as they grow into more senior roles is the transition from being primarily a technologist to being a leader. This is such a huge shift for a lot of engineers and requires soft skills and communication style adjustments. The more senior you are the more your focus shifts from coding to listening, networking, influencing, selling the technical vision, building trust relationships, understanding what other engineers need and want, to mentoring, to raising the quality of the team around you through influence to motivating others as well. Being able to influence the product direction, being able to express in business terms why something has to be done or should be a higher priority etc. Also, understanding the organization and becoming organizationally savvy is important.
All of these skills take time and practice to achieve, and good managers can guide their people through the journey.
Here are a couple more things:
- holding people accountable to their own goals - like getting a certification or learning about a particular, new topic. This benefits the company by having more highly trained people, and the individual benefits from higher success rates or more depth of learning accomplished.
- setting expectations for promotions. Often, it’s a squishy guessing game about when a promo will come, but if you’re able, you can set the bar and hold the person to that to set them up for success.
- one tangible example of coaching is just noticing bad behaviors — like, being late to meetings, lazy code, missing deadlines… and letting the person know you’ve noticed it, understand what’s going on, and hold them accountable to stopping the bad behavior.
There are already some great responses, but I want to add that one effective way to coach senior employees is to give them responsibilities one level above their current role and then provide feedback.
For engineers aiming to move into management or staff engineering, you can assign them a project at the level they aspire to reach and give feedback once they complete it. For example, for an engineer aiming to be an EM, I expect them to lead not only meetings but also all communications related to this project, while I act as their director. Afterwards, I provide feedback.
It doesn't have to be that extensive right away. You can start small, like asking them to lead a roadmap meeting, and then increase responsibilities as they improve. Essentially, create a safe environment for them to grow.
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.
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 word "coaching" implies one party is superior to the other in one very concrete area.
The opposite seems obvious to me. After all, your manager isn’t writing the code. He’s not your boss because he’s a better coder than you are, but because he’s a better boss.
(If this does not fit your experience, I’d recommend quitting your job as soon as practicable).
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.
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.
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.
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.
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.
> 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.
"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.
>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.
I was wondering about that for a while now - it feels in my last few jobs as an EM, the major part of my work (or rather the most influential one?) was managing, coaching and guiding product. The realization was actually quite simple for me: while hiring in engineering is defined by an sometimes absurd number of interviews, code challenges and so on, product is a case study and you're good: and that doesn't seem to be doing the trick.
I think dividing responsibilities across so many different managers has become too much of an anti-pattern for small and medium sized companies.
The least productive tech companies I worked for in the past decade had a nearly 1:1 ratio of engineers to different manager types. Our teams of 3-4 engineers had to work with our engineering manager, a product manager, a project manager, and a program manager at minimum. If you did UI work you would work with another UI/UX manager.
The minimum timespan to get anything done was measured in quarters. You could expect to have to spend more time scheduling meetings and following up with all your different managers by a factor of 10X or more than time spent doing anything related to code.
Contrast this with another employer I had who was very clear about the fact that we were not a big tech company and we were not going to structure our teams like one. We kept team units small and made them work together as a unit, not a disparate collection of managers that had to be appeased. We shipped a lot and we shipped fast.
We need to stop trying to use complicated and divided management structures everywhere. Companies with small teams and clearly unified management structures will always perform better than the management styles where responsibilities are divided across 5 different people and even basic work requires coordinating all of them through meetings
This is one of the reasons I think the "replace developers with ai" doesn't really fly in reality, as devs/engineers are typically the smartest people in any company I've worked for in a few decades. I don't see how the other folks could pull the weight via prompting.
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).
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
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!
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.
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.
> 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.
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.
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.
> 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.
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'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.
> 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.
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.
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.
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.
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".
You’re taking it too literally, it’s not saying don’t be useful, it’s saying don’t make yourself a bottleneck. It’s a very common failure mode for new engineers turned manager, leading to a frustrated team that feels micro-managed and the perception from leadership that you don’t have your shit together and can’t adequately handle the scope you’ve been given.
“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.
A really good book on this is "Turn the ship around".
Your role is to improve your staff to be better in their jobs. Ignoring the Manager/Engineer caste system, there is a lot general leadership in both roles.
You want your staff to be able to integrate and find information that allows them to make decisions, you don't lose accountability or responsibilty.
There is a big difference between
- "I've looked at the details, and I think we should do X, what do you think?"
and
- "What should we do about this?"
In the former, you can add extra context, and help your report understand details that may have been hidden or unknown to them. In the latter you are allowing your report to shift all the burden to you.
Its more about being a servant leader and not a bottleneck than literally being "not needed". Its a mindset of wanting your team to be able to operate without having to check with you (the EM) on every little thing. I've also heard it called having IC's be a "manager of one" where they can independently work on things, get work finished, etc. without needing constant nagging.
A good manager I had once had the approach of setting guidelines and "just getting out of the way" and I try to follow that, it works well for most people.
Is your goal for the software you write to need constant intervention, or would you say you'd aim for it to run smoothly with few bugs?
The team is akin to a piece of software architecture, only much more complex and comprised (partially) of humans.
You want someone to build that team and then have the team up and running, delivering value. When it breaks, or you want it to do new/different things, you need someone to step in to fix it or change it.
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.
> 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.
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.
> "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.
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.
crjohns648|1 month ago
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.
Scubabear68|1 month ago
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.
zerkten|1 month ago
There is the expectation that the manager knows who will be distracted. This is a basic part of knowing your people. I know which of my colleagues is going to get distracted without having the level of communication that my manager has. On one extreme, they just forward information knowing a report can work with it. One the other, the manager has to translate and communicate every element.
Ideally, the manager is already working on a way to ensure their report can handle transparency because that means they can work autonomously. You can't have individual contributors lead, if they are going to run into issues as soon as they discover what is going on overhead. They may not understand it yet, but they should have coping and mitigation strategies.
Engineers can be the worst group you could deal with when it comes to overhead conversations when they expect things to be orderly. Your organization is failing when everything has to go through managers and people can't operate independently.
randoglando|1 month ago
Shalomboy|1 month ago
gramie|1 month ago
A "shit umbrella" was a manager who protected the development team from all the politics, blame, and mismanagement coming from above.
A "shit funnel" was a manager who directed all the shit coming down, directly onto the team.
jamesfinlayson|1 month ago
I think this an underrated quality.
gambutin|1 month ago
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.
fidansin|1 month ago
tmarice|1 month ago
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.
djb_hackernews|1 month ago
- 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"
GabriDaFirenze|1 month ago
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)
tv26101617|1 month ago
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.
tl|1 month ago
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.
saidinesh5|1 month ago
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.
0kl|1 month ago
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.
super_mario|1 month ago
What engineers usually struggle with as they grow into more senior roles is the transition from being primarily a technologist to being a leader. This is such a huge shift for a lot of engineers and requires soft skills and communication style adjustments. The more senior you are the more your focus shifts from coding to listening, networking, influencing, selling the technical vision, building trust relationships, understanding what other engineers need and want, to mentoring, to raising the quality of the team around you through influence to motivating others as well. Being able to influence the product direction, being able to express in business terms why something has to be done or should be a higher priority etc. Also, understanding the organization and becoming organizationally savvy is important.
All of these skills take time and practice to achieve, and good managers can guide their people through the journey.
doctaj|1 month ago
jampa|1 month ago
For engineers aiming to move into management or staff engineering, you can assign them a project at the level they aspire to reach and give feedback once they complete it. For example, for an engineer aiming to be an EM, I expect them to lead not only meetings but also all communications related to this project, while I act as their director. Afterwards, I provide feedback.
It doesn't have to be that extensive right away. You can start small, like asking them to lead a roadmap meeting, and then increase responsibilities as they improve. Essentially, create a safe environment for them to grow.
devdp430|1 month ago
I guess the "coaching" is to understand that mindset shift.
unknown|1 month ago
[deleted]
__alexs|1 month ago
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.
throwaway173738|1 month ago
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.
singleshot_|1 month ago
The opposite seems obvious to me. After all, your manager isn’t writing the code. He’s not your boss because he’s a better coder than you are, but because he’s a better boss.
(If this does not fit your experience, I’d recommend quitting your job as soon as practicable).
unknown|1 month ago
[deleted]
dasil003|1 month ago
parthdesai|1 month ago
idiotsecant|1 month ago
SkyPuncher|1 month ago
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.
Schlagbohrer|1 month ago
Traster|1 month ago
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.
OhMeadhbh|1 month ago
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...
Schlagbohrer|1 month ago
jofzar|1 month ago
These are all things I have seen in my good managers over the years when I had them.
lloydatkinson|1 month ago
andros|1 month ago
andreidbr|1 month ago
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.
DevKit|1 month ago
soulofmischief|1 month ago
junon|1 month ago
vasco|1 month ago
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.
bradley13|1 month ago
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.
hnthrow0287345|1 month ago
>“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.
derwildemomo|1 month ago
Aurornis|1 month ago
The least productive tech companies I worked for in the past decade had a nearly 1:1 ratio of engineers to different manager types. Our teams of 3-4 engineers had to work with our engineering manager, a product manager, a project manager, and a program manager at minimum. If you did UI work you would work with another UI/UX manager.
The minimum timespan to get anything done was measured in quarters. You could expect to have to spend more time scheduling meetings and following up with all your different managers by a factor of 10X or more than time spent doing anything related to code.
Contrast this with another employer I had who was very clear about the fact that we were not a big tech company and we were not going to structure our teams like one. We kept team units small and made them work together as a unit, not a disparate collection of managers that had to be appeased. We shipped a lot and we shipped fast.
We need to stop trying to use complicated and divided management structures everywhere. Companies with small teams and clearly unified management structures will always perform better than the management styles where responsibilities are divided across 5 different people and even basic work requires coordinating all of them through meetings
AndrewKemendo|1 month ago
I’ve never met a sales person as broadly capable as your average engineer.
The curse of competence is organizational as well
gedy|1 month ago
highfrequency|1 month ago
Very well put
gorpomon|1 month ago
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).
dakiol|1 month ago
kaydub|1 month ago
willio58|1 month ago
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!
throwaway8177|1 month ago
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.
videogreg93|1 month ago
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.
tristor|1 month ago
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.
SkyPuncher|1 month ago
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.
1980phipsi|1 month ago
rendaw|1 month ago
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.
talkingtab|1 month ago
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.
unknown|1 month ago
[deleted]
PlatoIsADisease|1 month ago
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.)
vachina|1 month ago
Because being humble makes you more receptive.
CBLT|1 month ago
nitwit005|1 month ago
> 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.
v_CodeSentinal|1 month ago
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.
mtippett|1 month ago
- 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.
joshcsimmons|1 month ago
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.
Buttons840|1 month ago
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?
satisfice|1 month ago
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.
Keirmot|1 month ago
mulmboy|1 month ago
dasil003|1 month ago
ebiester|1 month ago
My teams would slow down without me because I can due process tasks more efficiently, but nothing demands me to be in the loop.
mtippett|1 month ago
Your role is to improve your staff to be better in their jobs. Ignoring the Manager/Engineer caste system, there is a lot general leadership in both roles.
You want your staff to be able to integrate and find information that allows them to make decisions, you don't lose accountability or responsibilty.
There is a big difference between
- "I've looked at the details, and I think we should do X, what do you think?"
and
- "What should we do about this?"
In the former, you can add extra context, and help your report understand details that may have been hidden or unknown to them. In the latter you are allowing your report to shift all the burden to you.
matt_s|1 month ago
A good manager I had once had the approach of setting guidelines and "just getting out of the way" and I try to follow that, it works well for most people.
rglynn|1 month ago
Is your goal for the software you write to need constant intervention, or would you say you'd aim for it to run smoothly with few bugs?
The team is akin to a piece of software architecture, only much more complex and comprised (partially) of humans.
You want someone to build that team and then have the team up and running, delivering value. When it breaks, or you want it to do new/different things, you need someone to step in to fix it or change it.
onion2k|1 month ago
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.
Rainbooow|1 month ago
skirge|1 month ago
michaelcampbell|1 month ago
palata|1 month 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|1 month ago
Insanity|1 month ago
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.
OhMeadhbh|1 month ago
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.
20260126032624|1 month ago
andros|1 month ago
pplonski86|1 month ago
bravetraveler|1 month ago
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.
unknown|1 month ago
[deleted]
MORPHOICES|1 month ago
[deleted]
MarginalGainz|1 month ago
[deleted]
oldpersonintx|1 month ago
[deleted]
FAFOAlex|1 month ago
[deleted]