alt Hacker NewsThings I've learned in my 10 years as an engineering manager
Comments
>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.
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.
> 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.
> Everyone needs to care about the Product
This isn't the first time I hear this, but I always have a bit of trouble with this one. It's one thing to take a step back and think about the actual product and how it'll be used, but I think it's presumptuous to think that software engineers know what makes a product good or not. We don't say "Everyone needs to care about software architecture, even Product", so I'm not sure why we think the flip side of that is true.
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.
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.
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.
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 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.
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.
> 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.
> 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.
> "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.
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.
[dead]
[dead]
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.