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

61–70 of 134 posts

Re: Principles of Engineering Management

#61

Post by chrsig »

ttoinou wrote: post #23
skeeter2020 wrote: post #12

Earlier quoted context omitted.

It is, but I think it's the manager's job to be the first to take the emotional risks, and continue to do so even when they're not immediately reciprocated.

If the other doesn't know you moved forward, why would he/she change his behavior ? It looks like the relationship will continue as it began forever - one sided.

Well, if you're doing a good job of treating the person...y'know, as a person, then you can ask them to change their behavior. And generally they'll be amenable to reciprocate.

Also: Why doesn't the other person know you've "moved forward"? Try communicating that you have.

Re: Principles of Engineering Management

#63

Post by lifeisstillgood »

We are putting too much into the word "management"

- supervision (did you turn up on time, are you capable of doing the basic functions needed)

- coaching (this team needs someone to do X, but I have two Ys. One goes or one changes)

- administration (budgets, projects, scheduling etc). Certainly the part most at threat from software - looking at you Project Manahers

- strategic decision making (yeah that's the part everyone wants to do because it's the big bucks with years before anyone can judge you. It is also oddly under threat - not from software but from voting - my guess is most strategy is going to be voted for in twenty years. don't like the strategy - binding vote at the AGM for new Board. would save Elon the effort of buying twitter)

All four of these (and I am sure MBA text books have better selections) are wildly different, at different levels of an org and need different skill sets and people. just thinking we could ever ask one person to get on with it all is crazy.

Re: Principles of Engineering Management

#64

Post by nickff »

hintymad wrote: post #40
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…

Similar feeling. These principles somehow do not help me make decisions or build mechanisms for my teams. On the other hand, the principles in the book Turn the Ship Around, the book No Rules Rule, and Amazon's 14 leadership principles helped me a lot because they give clear guidelines on how to make trade-offs. In particular, Turn the Ship Around advocates pursuing excellence instead of minimizing errors. Netflix ad…

I was a bit skeptical of "Turn the Ship Around" because of its title, and despite all the positive reviews, but it's one of the best management books I've ever read. It's definitely worth a read, even if you're not a manager, as it applies to any team-related activity, and provides a useful toolkit for improving your team, whether you're the leader or not.

Re: Principles of Engineering Management

#65

Post by [deleted] »

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…

[deleted]

Re: Principles of Engineering Management

#66

Post by pkaye »

willturman wrote: post #30
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…

> Again, not because the advice is bad or wrong, but because it's just a lot of text around the basics of being a decent human being. Judging by the trends observed in the Great Resignation [1] and the popularity of forums like /r/antiwork, it seems that the basics of being a decent human being are often being overlooked by management. I took a very different interpretation of what facilitating wellbeing looks like t…

There are a lot of shitty employers and employees around and the rest are trying to avoid them by different means.

Re: Principles of Engineering Management

#67

Post by brianhorakh »

As an introverted high iq nominal eq person with an execution bias I routinely find companies that are keen to move me into senior leadership roles. This post reinforces why I want to work for a good manager but also how I have zero desire to become one.

Re: Principles of Engineering Management

#68

Post by pkaye »

chrsig wrote: post #55
havkom wrote: post #42

Earlier quoted context omitted.

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…

Maybe use your one-on-one to discuss those things.

Re: Principles of Engineering Management

#69

Post by daok »

pkaye wrote: post #68
chrsig wrote: post #55

Earlier quoted context omitted.

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

Maybe use your one-on-one to discuss those things.

I don't think 1-1 is the right time. If you have a team of 15 people, you would need to repeat the same thing 15 times. Better to give an update of what you are working on (as a manager) for the whole team once.

Re: Principles of Engineering Management

#70

Post by and-not-drew »

bumby wrote: post #51
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…

> It's not unlike the military priority of 1) mission accomplishment and 2) troop welfare.

I hear what you're saying, but I would be careful taking a military type model and applying it to a team of software US engineers mainly because I think the power balance is so different.

If I'm in the military and I tell one of my subordinates that they need to dig trenches in the rain all weekend for the next 6 weeks, they may bitch and moan, but they've signed a contract so they're just kind of stuck. If I tell one of the engineers on my team that they need to work weekends for the next 6 weeks, they can probably have 3 interviews with other companies lined up by Monday.

I agree that achieving results is still priority #1, but the distance between that and #2 is very different.

Post reply on HN