Live data from Hacker News

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

jampa.dev

101–110 of 148 posts

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

#101

Earlier quoted context omitted.

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 g…

I'm sorry, but if a senior engineer needs coaching on getting work prioritized, they are not a senior engineer.

I worked with someone who had 30 years of experience, and would routinely go down rabbit holes of minimal value that they thought were valuable. Days spending on local environment setup and configuration scripts, for multiple platforms, when it only took a few commands to start everything up in a few seconds. Or making custom patterns to "improve maintainability" of the code base, that were brittle, overly abstract, and confusing.

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

#103
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.

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

#104

Earlier quoted context omitted.

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 c…

As a former Naval Flight Officer, it's somewhat ironic how the private sector is more "sir, yes sir" command and control than the military ever was, and they're the ones who stereotype servicemembers for being drones who can only follow orders. The other thing I've seen incredibly less of in software than in uniform is a bias for action at all levels. Combined with understanding the mission, a mentality that "in the…

> So many people in the private sector just wait for the boss to push them around like chess pieces, and I can't understand how they're OK living like that.

I think a lot times, office workers will be reprimanded for taking action if they don't realize their chain of command are not supportive. Have this happen a couple of times, and you will quickly move into this mode of "I'm not going to do anything I'm not told to do." I can recall more than one former company where taking the initiative to perform some action independently was very risky to your career there.

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

#105
Lots of good advice there. I did pause on the "Be risk adverse". My take is

- Be Risk Aware - know them, quantify them, manage by mitigating or having contingencies

- Don't be Risk Averse - Averse means being avoidant of risks or disinclined, it's safer, but it means risks aren't taken.

- Don't be Risk Paranoid - Protecting against unseen risks wastes time and efforts.

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

#106

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…

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.

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

#107
post #79

> 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,…

I recall hearing that Google had a term similar to this: 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.

Not that it originated with me, but I was using that metaphor long before Google showed up.

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

#108
post #34

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 experienc…

[deleted]

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

#110
post #93

Earlier quoted context omitted.

I agree, but I think that input is limited to unopinionated information about the technical impact or user-facing impact of each task. I don't think it can be said that senior engineers persuade their leaders to take one position or the other, because you can't really argue against a political or financial decision using technical or altruistic arguments, especially when you have no access to the political or financi…

In my 30 years in industry -- "we need to do this for the good of the business" has come up maybe a dozen times, tops. Things are generally much more open to debate with different perspectives, including things like feasibility. Every blue moon you'll get "GDPR is here... this MUST be done". But for 99% of the work there's a reasonable argument for a range of work to get prioritized.

When working as a senior engineer, I've never been given enough business context to confidently say, for example, "this stakeholder isn't important enough to justify such a tight deadline". Doesn't that leave the business side of things as a mysterious black box? You can't do much more than report "meeting that deadline would create ruinous amounts of technical debt", and then pray that your leader has kept some alternatives open.
Post reply on HN