I would wager that very few engineering managers have significant formal training in management. While software engineers can hold a wide variety of degrees, the most common is a CS degree, and few of those include significant coursework specifically about engineering management.<p>Thus, unlike with IC-track positions, it is likely that an engineer promoted into a management role is coming in cold. And while there are a variety of helpful books and training materials about engineering management, in general new EMs are expected to mostly learn by doing.<p>“Learn by doing” can be tricky, however, because many of the issues a seasoned engineering manager is expected to be able to capably handle do not happen every day. They happen relatively infrequently, and sometimes only when you change teams, but you need to know how to handle them when they do occur.<p>Because engineering management is largely a “learn by doing” craft, and because it can take years in the role to experience even the half of what a seasoned EM is typically expected to be able to capably handle, I would argue that the best EMs are those who have had abundant opportunities to learn from their mistakes. But you can certainly speed that up at least a little bit by learning from other people's mistakes instead :)
Imho EM has become a lot more difficult because it has been split into Manager, PM, TPM, scrum master, and all kinds of other shit. It’s weird watching teams struggle so much because you have 3 or 4 people trying to do similar jobs and stepping all over one another and ownership goes out the window.
I bang on regularly about "software literacy" - that software is another form of literacy and will impact how companies orgise as much as actual literacy did.<p>And one important slightly snarky point I make is that often you will hear people say "I used to code before I got into management but now ...". Yet no one says "I used to read and write before I got into management..."<p>The editor of the new york times will be able to read every part of todays print. He will have sun editors who in total have read every part of the paper going out today. And checked it.<p>Do we think that every engineering manager has read every changeset going out the door today?<p>This checklist is good for people management - but has sod all to do with software management
It’s not wrong, but also checklist is not a practical way to approach this job, in my experience.<p>All the listed activities (and we could list 50 more) are situational and should build to the needs of your job goals. It’s not a hard job and trying to list every detail can be misleadingly overwhelming.<p>Aim to help people you manage grow, the team be a team, peers be better off than they would be without you, and your company make money or whatever it makes - and you’ll be doing well at the job.
This a nice checklist indeed! This point stood out to me as interestingly debatable:<p>> conflicts are resolved in a fair and respectful way<p>Over time, I think I've become less enamoured with the concept of 'fair' for specific engineering disputes, whereas 'respectful' seems like it would actually benefit from the decision being less fair. Here's how:<p>- In the context of an engineering decision, the informed opinion of just one engineer is usually preferable to a attempt at compromising within a group that doesn't have consensus. Of course, unanimous consensus would be even better, but that rarely happens in groups larger than about ten people (in my experience). With architectural decisions, you need a clear and cohesive vision, and with smaller decisions like style guides it's often down to personal preference.<p>- When a specific engineer is explicitly given authority for a certain topic (eg. "Bob gets the final say on anything related to user authentication"), the manager can follow that without being disrespectful to those who hold contrary views. Attempting to form a compromise usually ends up devaluing both opinions, as neither is completely satisfied.<p>- If there are serious concerns about the nominated individual's motives or qualification to make a certain decision (in my earlier example, for instance, maybe someone realises that Bob doesn't really understand important concepts in the field), that concern can be elevated privately to the manager, who can reshuffle the team without having to confront the issue in front of the team, which would be embarrassing and disrespectful for all involved.<p>In conclusion, I'd say that if you have a semi-hierarchical structure within an engineering team that is itself fair (not merely based on traditional seniority, that is, perhaps more like a meritocratic government cabinet rather than a strictly promotion-based military), you can omit fairness in detailed discussions for a more productive and respectful decision-making process.<p>Interested to hear what others think here!
Pretty good list.<p>I'd add some encouragement and priority for anything your team is doing that shows ownership of the product or process.<p>Often this comes from individuals, such as the "go to" person who hacks on the development environment the most, or the engineer who everyone seems to ask for help writing tests. If you can see the value in those activities, it would be much appreciated if you schedule time for them, taking the day-to-day pressure off the individual a bit.
Like so many other treatises on engineering management, this fails because it does not focus on people, it focuses on tasks and treats people as compute.
Always communicate clearly and directly without ambiguity and assume by default engineers are communicating that way.<p>I don't know what it says about me but it's a f@king nightmare trying to decipher what managers mean and always saying things clearly and specifically myself and yet that gets interpreted wildly wrong.
> 12 diversity is represented and embraced; a broad spectrum of views are considered<p>You know DEI has reached terminal velocity when this starts showing up on linux mailing group text emails archives.