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

Principles of Engineering Management

acjay.com

Post reply on HN
Print view View original

51–60 of 134 posts

Re: Principles of Engineering Management

#51

Post by bumby »

tschellenbach wrote: post #45

Lot of misconceptions here that cause teams to underperform. 1. Managing comes first. (Nope, as a manager your are primarily responsible for ensuring a good outcome. As your title goes from manager, senior, higher to VP etc this becomes more important. Lower job titles you get paid to "do the work", higher titles are about "achieve outcome".) In the current market you'll often run into team members that don't perform…

I suspect you're right and the article conflates the means (managing) to the end (achieving an outcome). It's not unlike the military priority of 1) mission accomplishment and 2) troop welfare.

But in fairness, "achieving outcome" is equally vague and it seems most leaders know they want Outcome X, but falter because they don't know how to get from their current state to that end state.

Can you elaborate on how you'd fill those gaps of "achieve outcome"?

Re: Principles of Engineering Management

#52

Post by broast »

deeptote wrote: post #14

This is typical, MBA armchair psychology. Here's the real Principals of Engineering Management, according to pretty much every middle manager, director, and vp I've ever worked with: 1. Be caviling and pedantic, so you can reinforce your position of petty power. 2. Contribute exactly zero code, infrastructure, etc. Basically, anything that actually provides value to the engineers or the customers, you don't touch. 3.…

As an engineer, I have never worked under a manager who wasn't previously an engineer. YMMV

Re: Principles of Engineering Management

#53

Post by deeptote »

nealabq wrote: post #46
deeptote wrote: post #14

This is typical, MBA armchair psychology. Here's the real Principals of Engineering Management, according to pretty much every middle manager, director, and vp I've ever worked with: 1. Be caviling and pedantic, so you can reinforce your position of petty power. 2. Contribute exactly zero code, infrastructure, etc. Basically, anything that actually provides value to the engineers or the customers, you don't touch. 3.…

I think it's helpful to consider these points, and try not to be put off by the bitter tone. As an employee you have to consider the workplace culture, and your manager's attitude towards his/her "resources" (employees). This is a list of danger signs. You want to be watch for dysfunctional behaviors like this creeping into your work environment, and either combat them if you can, or find a new position. Or, you can…

It's not preachy at all! You're more eloquent than I am and yes, I'm a tad bitter about some of my recent work experience.

I'm grateful to report that I'm in an awesome situation now and my manager and I get along swimmingly.

Re: Principles of Engineering Management

#54

Post by chrsig »

havkom wrote: post #36

As an engineering manager myself I concur with all the points. Some of them are difficult though, for example: “optimize the dual objectives of delivering value to the organization and giving individuals problems that build their skillset, impact, satisfaction, …” and “ Managers with excellent execution skills and deep domain knowledge must resist the urge to present solutions to their reports.” To what extent should…

As a non-manager, I find that having a company wide policy for what tech stacks are supported really helps with that particular concern. It should be a pretty easy "tap the sign" sort of thing. And engineers should be able to understand that technology spread has a very real cost that's hard to quantify. It also has that cost over time as long as the software they produce needs to be maintained.

For things that are much more personal -- allowing suboptimal solutions for example -- those are teaching moments. You don't dictate the solution, you educate on the problems that the chosen solution exhibits and provide resources. Make requirements clear. There's a decent chance that if they're presenting a solution that you find suboptimal, then you haven't communicated the requirements properly. Surface them and re-scope the project as needed. Be sure to double check that the things you're finding as suboptimal are actually important as well. That is, don't be arrogant -- there's plenty of room for the error to be on you, and that you're assuming something may be suboptimal. Also consider that the person in the weeds may have more context than you, and there may be factors you're not considering.

Rely on concrete things like tests and metrics to guide those discussions, so you're not evaluating on subjective matters. Don't put value judgements on solutions, frame things as decisions with trade offs. Those trade offs have ramifications that you can discuss, and together you can navigate to a workable solution.

Ultimately remember that even though you could give into the urge to present solutions, it is not your job. Focus on your job, and help your reports do theirs. If you don't like that, get a different job.

Re: Principles of Engineering Management

#55

Post by chrsig »

havkom wrote: post #42
havkom wrote: post #36

As an engineering manager myself I concur with all the points. Some of them are difficult though, for example: “optimize the dual objectives of delivering value to the organization and giving individuals problems that build their skillset, impact, satisfaction, …” and “ Managers with excellent execution skills and deep domain knowledge must resist the urge to present solutions to their reports.” To what extent should…

My approach so far is to be very very allowing —- until any failure becomes apparent and it can “naturally be discussed” (or it causes problems with colleagues in the group). This can be quite stressful though — I do not think the people reporting to me understands how much energy is spent as a manager negotiating with others in order to give the team and team members the most space/maneuverability that is possible.

> I do not think the people reporting to me understands how much energy is spent as a manager negotiating with others in order to give the team and team members the most space/maneuverability that is possible

Speaking from experience as an IC -- managers do an absolutely terrible job of surfacing what they're working on.

What are you doing to broadcast your efforts? If you don't tell them what you're doing, you can't expect them to know if you don't tell them.

Re: Principles of Engineering Management

#56

Post by TameAntelope »

hitekker wrote: post #32
TameAntelope wrote: post #28

Earlier quoted context omitted.

I think "facilitate wellbeing" is more than just a feel-good aphorism, because it really does help when there's a difficult decision on your desk, at least for me. My instinct is to push hard, let "the most correct" idea win, and not really give a shit about how it impacts others. All, as you know, awful, very bad, no good ways of managing. Being reminded that one of my primary jobs is to "facilitate wellbeing" helps…

What you're speaking of is "Prioritize Wellbeing" which is a worthy belief to hold and to remind ourselves as engineering managers. However, the specific word used by the OP is "Facilitate" which gives managers the leeway to be weak and lazy. A manager can say "I let my team take PTO a few days each quarter, I facilitated their well-being!" while they passively allow their stakeholders to dictate the workload of thei…

I just don't see how you can read "facilitate wellbeing" and be this upset about it, especially given how you feel about "prioritize wellbeing".

Re: Principles of Engineering Management

#57

Post by higeorge13 »

deeptote wrote: post #14

This is typical, MBA armchair psychology. Here's the real Principals of Engineering Management, according to pretty much every middle manager, director, and vp I've ever worked with: 1. Be caviling and pedantic, so you can reinforce your position of petty power. 2. Contribute exactly zero code, infrastructure, etc. Basically, anything that actually provides value to the engineers or the customers, you don't touch. 3.…

For some reason they downvote you, but your post has some truth. I really wish EM wasn’t only about people management, hiring and goals but actual technical leadership. I want my manager to care for my wellbeing, be empathetic etc. as the post and common sense suggest, but i prefer he could provide some technical direction to the team (not let the team leads figure it out themselves), collaborate closely with product and leadership, make time for engineering to solve hard problems and tech debt and not just deliver d2d features and so on. I would expect EMs coming from IC roles to have this mindset, but most of the time they are stuck to non technical responsibilities and i really cannot understand why this role has become like this.

Re: Principles of Engineering Management

#59

Post by superzadeh »

jahbrewski wrote: post #26
PragmaticPulp wrote: post #21

I consumed a lot of blog posts like this before becoming a manager. It feels satisfying to read vague principles like this: > Facilitate wellbeing > Personal safety, dignity, and wellbeing of every team member are paramount. Team success is only success if team members feel good about it. But then you become an actual manager and realize that these are largely just feel-good aphorisms that don't really help navigate…

Good feedback here. Do you have any example “smaller forums” that you have found particularly helpful?

teams at work is a good one: https://bunch.ai/slack-community

Re: Principles of Engineering Management

#60

Post by kqr »

PragmaticPulp wrote: post #21

I consumed a lot of blog posts like this before becoming a manager. It feels satisfying to read vague principles like this: > Facilitate wellbeing > Personal safety, dignity, and wellbeing of every team member are paramount. Team success is only success if team members feel good about it. But then you become an actual manager and realize that these are largely just feel-good aphorisms that don't really help navigate…

> The hard work often involves making unpopular decisions, or telling someone "no" when their pet request wouldn't be in the best interests of the team

I realise I'm just plucking a small point out of a large comment here, but I'd like to drill down into this one a little.

My very limited experience is that teams can generally self-manage this sort of thing. You tell them what you're trying to optimise, under what constraints, and lay down some ground rules for equal and fair participation, and then the team can make their own tough decisions and tell each other when they're not acting in the best interest of the team.

What am I missing?

Post reply on HN