A lot of the work of an EM is wading into the slurry pit with a shovel so your team are free to get the job done: bashing your head against InfoSec teams stuck in the '80s so the CI/CD toolchain can deploy to production, negotiating freedom with a CTO who wants to specify everything to the level of individual data structures, convincing HR that no, we really do need to pay for a good senior and not hire someone with 2 years experience in a configuration galley because they're cheap.

On top of that there's the process battles; in older firms, all those interminable "but can't they just use Waterfall?" meetings that go on for hours and are spawned every time there's a minor project manager reshuffle. In newer ones, the ongoing fight of, "you can't address debt or build foundations for the future, we need features, if it can't be done in less than a week it's not MVP enough"

There's a fine balance in that I think a good EM lets their team know this is going on and get involved where they want without dumping all the crap downward. Not least because they should be coaching their team leads in that responsibility, so they can take the career step when they want.

Going back to the article, as others mentioned it does read a little bit more like a "why I'm frustrated with my manager" than a "how to be a good EM", but it's easy to misconstrue the meaning of text.

You don't need to be an great engineer to be a good manager, but it definitely helps when your manager knows enough about the battles fought in the trenches and can offer actual feedback/support instead of nodding for 30m, then going to another 1:1.

Why the cynicism? Because in my career across many companies and many teams, I can count the good managers on one hand, but have seen people "playing manager" everywhere -- and these are the ones who like to espouse theory.

* Frequent one-on-ones! (yeah but everyone on your team is demoralized and trying to switch out)

* Shield the engineers from crap! (but you still let your team struggle to take care of everything while you're busy "aligning" with the other managers)

* Help the engineers grow! (are you actually giving them more responsibilities in a way they can deliver and actually get promoted this year, or just dispensing cheap advice every week?)

* Resolve conflicts! (do you personally take it upon yourself to settle issues with your peer managers, or do you co-miserate with your directs about how political everything is)

Really, there's dozens and dozens of things a good manager will need to do, and it's far from a solved problem. Drawing up a list of desiderata is not the hard part. The difficulty is how to actually enact them, how to actually impact the team, how to actually drive the project forward. You tell me your secret and I'm all ears.

1. Managers need to be human & kind.

2. Shielding their team from crap (as someone mentioned already)

3. Don't pitch one team member vs another - this is toxic. Instead nurture their strength. Our competitors are outside the team, not inside

4. Cheer lead/Sponsor for the team outside. Genuinely back your team.

5. Always expect your team members are smarter than you - give them that trust. Thank them for things they teach you.

6. Managing is more like parenting college kids (not toddlers/middle schoolers). You want them to survive worst and replace you if needed. So you too can grow. But avoid micro managing.

7. Learn to have tough conversations - This could be for their/team's improvement.

This part seemed a little weakly worded to me. An engineering manager should make sure their team gets things done. It isn't enough to "follow along the deliveries".

Sometimes that is things like setting standards and communicating. But it's also things like firing underperformers and hiring for open headcount. It's making sure you have enough budget and support from other teams to get the job done. Whatever it takes. It isn't enough to say "Well, communication was great, I gave the team a lot of support, but we didn't make very much progress."

A lot of managers in my company only ask “when” but never “how” or “why”. It doesn’t help to constantly remind people of deadlines without listening to and implementing suggestions for improving the work environment.

Do whatever it takes.

Way back in February or March, when we were still working from the office, I walked to the drug store on the corner and got Lysol wipes and hand sanitizer for everyone. Because, do whatever it takes.

https://news.ycombinator.com/item?id=18826015

It's quite critical of the position, and perhaps a bit negative, but captures the core strengths an EM needs to be successful

"Like if I were in his shoe, this is how I would treat myself."

The management role is challenging and has affected me to the part where I go on continuous daily walks, thinking about what to do next. I mess up and have broken down on numerous occasions about tackling challenging topics that play out for both the business and the individual in contra. I still care.

Some things I missed doing well: Being a shield. Do this more. But more importantly to me: to leave engineers better than I find them. Ratcheting is the metaphor. I understand that I'm always asking for more.

It's a lot of meta and reflection while the delivering is or isn't happening.

In most western developed countries (and most recently developing countries too) depression and anxiety is shooting off the roof in every possible survey and study (yes, that can be attributed to social media and others too). According to OECD data the 25% of the working age population of those countries struggle with mental health problems. That's about 166 million people.

If everyone believes that good management is possible and just the matter of willpower, while the numbers all point towards the opposite direction then we're doomed. Too many people are indoctrinated.

This concept is often easily achievable through automation by removing the flexibility to allow knowingly bad practices. Such techniques are code validation rules, interfaces, method removal/redefinition and so forth. It provides a clear sense of direction by removing distractions and bad conveniences as passable options.

The concept also sets hard business limits on what work a team performs without intermingling in the responsibilities of other teams.

I am amazed at how absent this concept is to software given that it is so foundational to project management.

That's my current struggle. I'm leaning on doing work for myself on the weekend and evenings, which will be brutal.

> We conducted a mixed methods empirical study of software engineering management at Microsoft to investigate what manager attributes developers and engineering managers perceive important and why.

Turns out that engineers want their managers more technical and less inspirational. This is different for sales or marketing managers, for example, so if these transfer it might turn out well.

I'm currently writing down a lot of the management lessons and coaching I usually give new directors as they learn their craft. It's mostly for my own sanity during startup building, since I miss coaching, but thinking of publishing it. There's a lot of EM guidance out there, but it's lacking for directors.

An ability for (which primarily derives from an actual interest in) actually solving -- as opposed to masking / deflecting / re-routing / siloizing -- so-called "communication issues" within and across teams.

Essentially a subset of "being a crap shield" as another commenter mentioned.

But before you dismiss the idea, look at open source projects like Linux, the D programming language, or Nim.

Confining your knowledge of how you would do it, in a what/how functional separation is hard.

Time estimation is hard.

Under promise and over deliver is well known and you, the manager will get squeezed on it both sides.

Technical leads and senior engineers, however, seem to add a lot of positive value.

It's rare to find a company balanced in the middle where they're looking for someone who clearly "gets it" and can talk about technical solutions, but also has the ability to solve the people problems. (Often good managers were also skilled ICs before they made the jump, but lack of everyday practical use leaves them with a layer of rust. In an hour interview with someone you've never met before it's hard to tell the difference between "rust" and "has heard of the concepts but doesn't really understand them" though)

The idea is to genuinely belong to a team, not just on an org chart. When troops are in the battle field, they form unbreakable bonds because they have trust, got each other's backs and there is absolutely nothing artificial about it - life is on the line. More often than not, I've seen managers appear genuine but are not internally so and it will surface in future if not now.

Also, corporations, midsized companies and even small companies have this idea of not speaking the mind. Instead, massive amounts of bullshit corp speak and lipstick is put on the pig to do a quick dog and pony show for the upper management. Managers that suck up to upper management lose their support from the troops. Once that's done, there is no going back.

One downside of relevant coding experience is that the EM will get involved in more and more little technical details, which bleeds into micromanagement territory.

I 100% agree with this, but have never really REALISTICALLY seen any of this methodology in the companies that I've worked at. Here's what I usually see instead: if someone is a staff engineer, then they worked their ass off to get there and are generally really good coders, and have wrapped their heads around the business/domain really well.

The managers I've seen are generally skewed towards incompetence, which to me, shows that interviewing to become an EM is MUCH easier than it is to become a staff engineer, yet the pay is identical. So you mostly have staff/principal engs that are VERY smart, and more often than not, have EMs/directors who have stumbled their way upwards by being lucky.

The question is -- do you want to be a principal engineer when you're 45, know the business, the code, the domain inside out, be paid well, but STILL have to answer to directors/managers who are 15 years your prior, who are entirely incompetent and have essentially lucked/bullshitted their way into their roles, and deal with all of that crap on and endless basis or do you become that person and attempt to fix it from the top?

A different angle: most companies have no idea what a staff engineer is, and how to promote from within. However, I've seen midlevel engineers do some decent work, maybe complete a major project, and be promoted to EMs. What's the point of trying to become a staff engineer (assuming part of your goal is to grow your wealth) when you can just easily become an EM at most places and make the same exact amount of money, and just do what you love (i.e coding), on the side. Of course, to each their own and all of that. But at the end of the day, it is much much easier to go into management and incompetence your way around to the top where goals are nebulous and not super calculable compared to being senior IC.

I should finally note that I have had a couple of EMs that were really good. However, those are far and few between IMO.

These are all things a senior IC should be doing as well, and as a manager these are the kinds of things you can and should start having your team replace you on if they're up for it.

And then of course, some of your ICs likely do want to transition to the manager path. So you can involve them in hiring conversations, phone screens, conversations about team mandate/goals, team structure and head count, etc.