Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jampa.dev

Post reply on HN
Print view View original

81–90 of 148 posts

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

#81

Post by gedy »

hnthrow0287345 wrote: post #69

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

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.

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

#82

Post by ghaff »

AndrewKemendo wrote: post #72
hnthrow0287345 wrote: post #69

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

There’s a reason you never see posts like: “My jump from BD to software engineer” I’ve never met a sales person as broadly capable as your average engineer. The curse of competence is organizational as well

Because your average engineer is so good at creating customer relationships and generating revenue.

Customer relationships are certainly more important in some categories than others but sales is certainly key in a lot of B2B organizations.

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

#83

Post by Aurornis »

hnthrow0287345 wrote: post #69

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

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

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

#84

Post by ratorx »

_tlo4 wrote: post #75
djb_hackernews wrote: post #42

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…

> Influencing without authority > Getting work prioritized > Developing 1YP+ plans for their areas I was a little surprised by your list. Aren't these normally the responsibilities of a team lead or a manager? If I were hired as a senior engineer, I'd expect to be involved in group decisions about cross-cutting technical concerns (architecture, choosing languages and frameworks, the code review process), but changing…

Team lead manages the overall direction of the team (and is possibly the expert on some portions), but for an individual subsystem a senior engineer might be the expert.

For work coming from outside the team, it’s sort of upto your management chain and team lead to prioritise. But for internally driven work (tech debt reduction, reliability/efficiency improvements etc) often the senior engineer has a better idea of the priorities for their area of expertise.

Prioritisation between the two is often a bit more collaborative and as a senior engineer you have to justify why thing X is super critical (not just propose that thing X needs to be done).

I view the goal of managers + lead as more balancing the various things the team could be doing (especially externally) and the goal of a senior engineer is to be an input to the process for a specific system they know most about.

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

#85

Post by addaon »

saidinesh5 wrote: post #46
tmarice wrote: 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…

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

Are you at a company that tends to hire from non-traditional backgrounds? The topics you mention -- the underlying "how it works" of the tech we use to build things day to day -- should be, and in my experience are, the areas where juniors have the clearest understanding relative to more senior engineers, since they just finished 4+ years learning about it five days a week in detail.

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

#86

Post by AndrewKemendo »

ghaff wrote: post #82
AndrewKemendo wrote: post #72

Earlier quoted context omitted.

There’s a reason you never see posts like: “My jump from BD to software engineer” I’ve never met a sales person as broadly capable as your average engineer. The curse of competence is organizational as well

Because your average engineer is so good at creating customer relationships and generating revenue. Customer relationships are certainly more important in some categories than others but sales is certainly key in a lot of B2B organizations.

I guarantee I’ll be more successful with a group of engineers doing sales than I would a group of sales people trying to do engineering

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

#87

Post by jampa »

tmarice wrote: 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…

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.

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

#88

Post by _blk »

gambutin wrote: post #54
crjohns648 wrote: post #48

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

Honestly, I’m not sure. If I know what was going on transparently I am stressed. As an ordinary employee, I don’t need to know everything and therefore don’t need to worry about it.

As a leader, it's important to provide not just the meat but also the veggies. What people end up eating is up to them, but serve the full course! If as a ME, I start deciding who needs to know what, information will be perceived as incomplete because people always talk and engineer are often smart enough to read between the lines. So the transparent umbrella is a great analogy. Communicate bad news as fast and coherently as possible - group meeting with open questions works well for me but be ready to address the potential fears: "In my current assessment, that's not going to be a problem, I'll let you know if that changes." and of course "Thanks for asking, I didn't consider that and I don't know yet. I'll clarify" is a valid answer, if you do indeed clarify.

If you're genuinely stressed with that, talk to your lead about it and they'll find a way to filter a little more while not giving you the feeling of being left out.

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

#89

Post by doctaj »

tmarice wrote: 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…

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.

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

#90

Post by djb_hackernews »

_tlo4 wrote: post #75
djb_hackernews wrote: post #42

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…

> Influencing without authority > Getting work prioritized > Developing 1YP+ plans for their areas I was a little surprised by your list. Aren't these normally the responsibilities of a team lead or a manager? If I were hired as a senior engineer, I'd expect to be involved in group decisions about cross-cutting technical concerns (architecture, choosing languages and frameworks, the code review process), but changing…

I work at a large software company, senior engineers here are essentially technical leads for a team or a subsystem. They are my equals when it comes to level, often getting paid a lot more than me for high performers.

I'm here to help the team make decisions, but I delegate as much of the opinion having to my senior engineers. To have an opinion they need a bunch of inputs, sometimes getting those inputs isn't as natural as the technical inputs, that's where I come in.

Senior engineers are still involved in cross cutting technical concerns but for any work that is bounded by our team I'd be working with them scope out the work as requirements or use cases we give to mid level or early career engineers on the team to disambiguate with the senior engineer as a consult/negotiate.

Post reply on HN