The real rules:
1) fuck your team.
2) look good to your superior.
Principles of Engineering Management
101–110 of 134 posts
Re: Principles of Engineering Management
#102Earlier quoted context omitted.
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.
Jim Keller (helped design the spec for x86-64, was in management during Apple, AMD and Tesla's ultra successful periods) said when he was interested in management he just read like 100's of books on it, and turned out there was lots of really useful information that he applied and got great results from.
Re: Principles of Engineering Management
#103Lot 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…
> hold people accountable to an acceptable level of performance
> end up having whole teams being fired since your manager didn't set the right pace
Whatever work exists where a manager can control such things as "pace" and "performance level" it aint engineering.
Re: Principles of Engineering Management
#104I 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…
Author here. I think the lack of specificity is a fair criticism of what I wrote in the piece, but this is also something I was very aware of when I wrote it, which is why this caveat is included: > The management principles below reflect lessons I have learned the hard way. These are things I wish I would have known and internalized when I first became a manager. By keeping this brief, I hope that it will be easily…
Eh, there are literally thousands of manuals on being a good manager. Still I hope people find your contribution helpful!
Re: Principles of Engineering Management
#105As 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…
> To what extent should one allow suboptimal solutions, failure or allow employees to do things inefficiently with their “favorite tech stack” (in cases where it does not add business value) ?
All solutions should be put out on the table as business tradeoffs. "It will cost X; we will get Y; we might run into unexpected problem Z". We all need to agree that we want to choose the best solution for the company, we lay out the solutions naked and vulnerable, we pick them apart, and then we make a decision. If we still can't make a decision, we let someone take the sword - potentially making a bad decision in the process - because we agree that forward progress is more important than total consensus. Will we always pick the best solution? No, but hopefully we've come to agreement as to what the pros and cons of each solution. We likely had to make a decision on several shades of grey. Still, we should be held accountable for our decisions regardless of how difficult they were
Re: Principles of Engineering Management
#106I 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…
Author here. I think the lack of specificity is a fair criticism of what I wrote in the piece, but this is also something I was very aware of when I wrote it, which is why this caveat is included: > The management principles below reflect lessons I have learned the hard way. These are things I wish I would have known and internalized when I first became a manager. By keeping this brief, I hope that it will be easily…
Alan, nice to see you on the front cover of HN. Life has been good for you post-Arena, eh?
Most of those critical of what you wrote haven't had an article like this happen. Don't sweat it.
Re: Principles of Engineering Management
#107Earlier 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…
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?
Re: Principles of Engineering Management
#108Lot 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…
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 manager and am guessing this would probably be bad for my sanity.
Re: Principles of Engineering Management
#109I 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…
Author here. I think the lack of specificity is a fair criticism of what I wrote in the piece, but this is also something I was very aware of when I wrote it, which is why this caveat is included: > The management principles below reflect lessons I have learned the hard way. These are things I wish I would have known and internalized when I first became a manager. By keeping this brief, I hope that it will be easily…
I'm sad to see parent post at the top of the page. It nitpicks the one most abstract bullet and calls the whole thing unactionable. I think that's silly. I enjoyed your article and agree with many points.
Re: Principles of Engineering Management
#110Earlier quoted context omitted.
I really wish. But it is the standard. 90% of jobs I see involve building some online service. On call is as part of the job as writing code is.
Everywhere I've worked has had on call rotations. Literally everywhere. Nowhere have devs been the first line of support (i.e., not "instead of" per the parent post, but "as well as"), but they've been in the mix. Quite frankly, I wouldn't want to work somewhere that didn't. I have a huge problem with the idea of "my team wrote the code, and now isn't responsible for it". I intentionally optimize against "avoid 2 AM…
It all makes sense and I don't have much in the way of an argument against it fundamentally.
But it does make this career path rather miserable to me.