I think the article misses what I think is a vitally important part of the job: being a crap shield.<p>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.<p>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"<p>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.<p>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.
One thing missing from my recent engineering managers is lack of relevant coding experience.<p>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.
I guess I'm just cynical, but every time I see a post on "How To Be A Great Manager", I only see "Look At Me, I'm A Great Manager!".<p>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.<p>* Frequent one-on-ones! (yeah but everyone on your team is demoralized and trying to switch out)<p>* 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)<p>* 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?)<p>* 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)<p>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.
Few things I learnt so far:<p>1. Managers need to be human & kind.<p>2. Shielding their team from crap (as someone mentioned already)<p>3. Don't pitch one team member vs another - this is toxic. Instead nurture their strength. Our competitors are outside the team, not inside<p>4. Cheer lead/Sponsor for the team outside. Genuinely back your team.<p>5. Always expect your team members are smarter than you - give them that trust. Thank them for things they teach you.<p>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.<p>7. Learn to have tough conversations - This could be for their/team's improvement.
<i>Your company expects that you follow along the deliveries, setting quality standards, making sure the team has the support they need and upper management the feedback they need.</i><p>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".<p>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."
One thing I noticed is that a lot of managers create an environment they would not want to work in themselves. A good manager should not just pass on orders from above and report back but try to shape the work environment so their reports can work well.<p>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.
Lots of great comments so far, but I'd like to toss mine in: showing up. As an EM for a few years now, showing up consistently, being available, always making time to talk or hear someone out.
The best managers I've had also always told the unvarnished truth and empathized with what all the folks "in the trenches" had to do day to day.
I recommend all of the books referenced in the original post. They are all very good. But the expectation of an engineering manager is fairly simple:<p>Do whatever it takes.<p>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.
`A good way to think about hiring and growing your team members is to think that they can replace you.`
This is really wrong.
Manager is a path, but an IC shouldn't need to become a manager to keep growing in their career.
Article seems to omit one of the big issues I had with being an engineering manager and that was managing budgets (people/assets) and financial forecasts. I'll probably become a manager again, but I'm enjoying my break and doing "real work" again.
I bookmarked this comment on being a tech manager a while back:<p><a href="https://news.ycombinator.com/item?id=18826015" rel="nofollow">https://news.ycombinator.com/item?id=18826015</a><p>It's quite critical of the position, and perhaps a bit negative, but captures the core strengths an EM needs to be successful
Dunno, but as a dev lead, onboarding new devs is huge - easing them into the project, make sure they get to do challenging work but aren't stressed too heavily or beyond their capacity, etc. Huge time commitment just to write clean, understandable stories for them to work while they are new.
Why do articles like these make it seem like it was written by a guy targeted by an engineering manager?<p>"Like if I were in his shoe, this is how I would treat myself."
I appreciated the write and liked how some references back to high output management - excellent book. I wrote a similar contemplating piece, being in the role for some years now. Here: <a href="https://dev.to/solidi/what-is-an-engineering-manager-anyway-4and" rel="nofollow">https://dev.to/solidi/what-is-an-engineering-manager-anyway-...</a><p>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.<p>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.<p>It's a lot of meta and reflection while the delivering is or isn't happening.
Something which bothers me deeply is the disconnection between the fetishism of management which is the most apparent on this website and the endless misery caused by the outcomes of 20th and 21st century corporate culture.<p>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.<p>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.
Setting hard boundaries is completely absent from software management and so essential to productivity and job satisfaction. In the military we call this <i>staying in your lane</i> or <i>knowing your left and right limits</i>.<p>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.<p>The concept also sets hard business limits on what work a team performs without intermingling in the responsibilities of other teams.<p>I am amazed at how absent this concept is to software given that it is so foundational to project management.
How do you stay current on tech when you're doing mostly crap work and umbrella-ing and project managing, and your people are doing all the juicy innovative stuff?<p>That's my current struggle. I'm leaning on doing work for myself on the weekend and evenings, which will be brutal.
E. Kalliamvakou, C. Bird, T. Zimmermann, A. Begel, R. DeLine and D. M. German, "What Makes a Great Manager of Software Engineers?," in IEEE Transactions on Software Engineering, vol. 45, no. 1, pp. 87-106, 1 Jan. 2019, doi: 10.1109/TSE.2017.2768368.<p>> 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.<p>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.
Shielding your folks is important, but so is nurturing them. I really like Rands in Repose (<a href="https://randsinrepose.com" rel="nofollow">https://randsinrepose.com</a>) because he talks about both.
As someone who's spent a lot of time coaching new EMs, I agree with these bullet points. The thing that makes me sad is that this is only correct if the EM's director agrees with it. The true bullet point of what is expected of an EM: whatever the EM's boss expects.<p>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.
Surprisingly undermentioned and underrated:<p>An ability for (which primarily derives from an actual <i>interest in</i>) actually <i>solving</i> -- as opposed to masking / deflecting / re-routing / siloizing -- so-called "communication issues" within and across teams.<p>Essentially a subset of "being a crap shield" as another commenter mentioned.
Personally I would prefer that the manager is someone who is an active engineer on the project. And I know that is challenging and won't work in a lot of organizations.<p>But before you dismiss the idea, look at open source projects like Linux, the D programming language, or Nim.
Managing expectations up and down is hard.<p>Confining your knowledge of how you would do it, in a what/how functional separation is hard.<p>Time estimation is hard.<p>Under promise and over deliver is well known and you, the manager will get squeezed on it both sides.
Based on ostensibly well-known and successful companies I know, I would say: not much, and very little of positive value.<p>Technical leads and senior engineers, however, seem to add a lot of positive value.
Is the engineering manager expect to proactively find work for their team? Are they responsible to keep the work pipeline full for the next upcoming cycles?
anyone use anything besides the usual suite of software (google docs, slack, JIRA, etc.) to assist with management? When I was a line manager, I felt like there was a lack of tools for engineering managers...
>> Dealing with underperformance/letting people go is a tough subject (which I don't have much experience): I highly recommend asking your HR Business Partner and your manager to help with that.<p>Yet another article written by someone without the requisite experience to be opining on the topic at hand.