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

121–130 of 134 posts

Re: Principles of Engineering Management

#121

Post by higeorge13 »

gkop wrote: post #79
higeorge13 wrote: post #57

Earlier quoted context omitted.

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…

If you have the energy and curiosity to be an EM, please do give it a try. The industry needs compassionate and highly technical EMs.

I was a data engineering em for a while, but it’s super tough to find open roles on the field. I just don’t understand how most em roles demand zero technical contribution.

Re: Principles of Engineering Management

#122

Post by NhanH »

throwawaythekey wrote: post #108
malfist wrote: post #50

Earlier quoted context omitted.

If you supplant your team and do the work yourself, you're not helping the team perform. Nobody is learning lessons and everyone, including yourself will just be more stressed and less satisfied with the job. If you can't trust your team to do the work, then you shouldn't be managing those people. Management is about being a force multiplier, and not the force.

What team size would you say this applies to? At the moment I have flexibility in how many people I hire underneath me and would like the team to remain small enough where I can be both a force multiplier and part of the force. The goal is to be an elite small squad. The other option is to hire a larger number of people, handle more of the project scope, and cease being an IC. However I'm new to being a formal manage…

You can't do that at any team size. The role you was looking for is generally called a "lead" role, which has different responsibility than manager role.

It's mostly because of conflicting mindset and commitment. As manager, meeting is your tool to get work done (source: High output management by Andrew Groove, I didn't make this up, and I didn't understand it until after I had to become a manager either). As an IC, meeting is a big giant distraction to you. You basically can't get the two type of works to mix together. You will always be blocking other members of your team in your IC task. And this doesn't get started with the different mindset yet (For example, you have to watch/ teach people fixing ugly code, as opposed to doing it yourself. And there will be some point you have to give up asking polishing certain piece of code, due to the members not interested, incapable or other reasons).

Being a manager and part of the force should only be a transitional period.

Re: Principles of Engineering Management

#123

Post by disgruntledphd2 »

kqr wrote: post #119
hintymad wrote: post #73

Earlier quoted context omitted.

Yeah, the book also passes Taleb's Skin in the Game test: the author is also the practitioner of what he wrote about.

Hm. That's a generous take. Marquet lived the experience once . Now he goes around and lectures people in it instead. I have all respect for Marquet and I agree with most of the things he says about leadership, as well as try to apply it daily myself. But my best reading of Taleb is that the sort of thing Marquet does (potentially get lucky, extract oneself from the situation, and then live off of the one experience)…

To be fair, that's pretty true of Taleb himself.

Re: Principles of Engineering Management

#124

Post by travisgriggs »

mgfist wrote: post #107
lifeisstillgood wrote: post #99

Earlier quoted context omitted.

I think the difference here is in "corporate structure". I mean Bezos and Musk are both extraordinary people - but say Bezos employees about 1 million people and is worth about 150bn - why is the world structured so that each employee "gives" Bezos 150 grand? There are other ways to structure our corporations, our tax and investment incentives. The Early Victoria British style of corporate structure worked so it got…

Simplicity, speed, responsibility, authority. A lot of reasons why having a clear hierarchy makes sense. How do you assign blame in a co-op that makes bad decisions?

I can’t tell if you’re doing /s or not.

If a group of people performs/delivers poorly, how effective is it to assign blame to one select member? It may be efficient, but I’m not sure it’s effective.

Re: Principles of Engineering Management

#125

Post by travisgriggs »

lifeisstillgood wrote: post #99
gkop wrote: post #78

Earlier quoted context omitted.

What does engineering leadership mean to you? What factors make it easier or harder to practice engineering leadership? For me, I like having a budget and a staff - it’s way easier to influence my organization with a budget and a staff, than without. I’m saying this only to encourage engineering leaders not to be afraid of formal management roles. You can make them your own. You might find what I found.

I think the difference here is in "corporate structure". I mean Bezos and Musk are both extraordinary people - but say Bezos employees about 1 million people and is worth about 150bn - why is the world structured so that each employee "gives" Bezos 150 grand? There are other ways to structure our corporations, our tax and investment incentives. The Early Victoria British style of corporate structure worked so it got…

Yes. Co-op was/is the word that I’m looking for. I love co-ops when they work.

Re: Principles of Engineering Management

#126

Post by moonhorse »

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…

True. Recently one of the sales directors at my company threatens the CEO to make him a "co-founder" (which basically means granting him a lot of option), or he will quit. He is responsible for half of our revenue, and he has been empire-building in his org for a while, so that his team answers to him, not the company. If we cut him off, very likely he (and a few key leaders) would deflect to our main competitor with our sales pipeline, and do some real damage. Very brutal situation for the CEO. I can not imagine learning how to handle this in any water-downed advice.

Re: Principles of Engineering Management

#127

Post by NateEag »

kqr wrote: post #60
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 co…

I think what you're missing is that most humans are not what Netflix calls "fully-formed adults."

If your team consists of mature, kind, focused, skilled, honest, emotionally well-regulated people, then yes, the team can self-organize well.

That's very, very unusual, though. I don't think I've personally ever been on a team that consisted solely of such people (and, to be clear, though I strive for those things, I wouldn't say I've got them all nailed down perfectly).

Re: Principles of Engineering Management

#128

Post by AlwaysRock »

prmph wrote: post #13
AlwaysRock wrote: post #5

Earlier quoted context omitted.

100%. I've worked for a lot of bad managers and 2 good ones. 1 of the good ones wasnt a great human but an incredible teacher. The other was an okay teacher but an incredible human. The later I'm still in contact with and we've stayed in touch for 5 plus years. A lot of what I'm looking for in a boss is just someone who kind and understanding. It's shocking how low that is on most managers agendas.

Well, as an engineering team lead for years, and recently founder of a small gig, increasingly I've been shocked at how many people (employees, contractors, prospective business partners or co-founders) just want to take the easy way out, instead of putting in honest, conscientious, reflective work and effort, or are just plain incompetent at what they claim to be good at. Every once on a while you come across someon…

I guess I'm not really sure what your point is but it seems like you're saying being nice and delivering are not compatible.

You can have high standards and expectations and still be nice. In reality no one is going to be operating at 100% all of the time. They will have good days and bad days. I assume that others are doing their best. If their best is not enough for the role they were hired for than I made a bad hire. If I cant find a way to communicate expectations and standards without remaining nice than I'm the one taking the easy way out.

It's easy to be an ass and use emotion to make strong employees feel like they need to do better or deliver more. But at the end of the day your employees will leave once they have had enough.

I've left jobs I was highly effective at because my manager was constantly pushing for more and more. I would have stayed much longer if they would have had the EQ to recognize that I was operating at a high level and praise and kindness would be more effective in the long run. Who cares if someone delivers more of X when they leave in 6-12 months? Every gain will be canceled out by the amount of time you will spend finding their replacement and training them.

So to end my ramblings... If your point is that kindness can be abused... Sure. I agree. But is choosing to be kind and understanding, even if you feel like you are being abused at times, going to lead to you having significantly greater employee retention? Will choosing to act some other way cause your employees to leave which will drop their production from whatever % to 0% for an extended period of time?

Re: Principles of Engineering Management

#129

Post by kqr »

disgruntledphd2 wrote: post #123
kqr wrote: post #119

Earlier quoted context omitted.

Hm. That's a generous take. Marquet lived the experience once . Now he goes around and lectures people in it instead. I have all respect for Marquet and I agree with most of the things he says about leadership, as well as try to apply it daily myself. But my best reading of Taleb is that the sort of thing Marquet does (potentially get lucky, extract oneself from the situation, and then live off of the one experience)…

To be fair, that's pretty true of Taleb himself.

Sure it is. But, and this is a subtle point, he does not go around telling people specifically how they ought to invest, or how they ought to insure against tail risk.

He tells people how he invests, and some theoretical consequences of tail risk depending on input parameters.

It's a small difference, but, from what I understand, a meaningful one to Taleb.

Re: Principles of Engineering Management

#130

Post by fuzzfactor »

acjohnson55 wrote: post #117
gmfawcett wrote: post #104

Earlier quoted context omitted.

Eh, there are literally thousands of manuals on being a good manager. Still I hope people find your contribution helpful!

I could have phrased it better, but my point is that no single book on management can reliably make people into good managers, any more than a single book on engineering can make people into good engineers.

Some people may say some points are common sense, but when you condense your personal perspective it adds the depth of your experience without having to write a book.

When managers of unrelated industries come up with some similar preferred practices, that can show fair agreement that it's more likely to be worthwhile.

People need to realize there are lots of companies that fail on almost all of the eleven points you have here, and if the right key person were to just take your page to heart and follow it with action it would be like a breath of fresh air across the entire project environment.

Like they have never seen.

Post reply on HN