What is expected of a engineering manager?

Absolutely. This is especially relevant, these days, when HR departments are basically taking an actively adversarial role towards employees.

I used to get crap from HR, if I chose to resolve personnel issues without involving them.

The problem was, they had only two speeds: Do Nothing, or KILL ALL THE BABIES. Nothing in between; despite their constant harping about how they were "on our side." Their job was to keep the C-suite happy. It was absolutely amazing how many rules that were "hard and fast," and "applies to everyone here," would suddenly fail to be implemented, when it was a C-suite doing the rulebreaking.

There were also companywide policies, meant to appease union employees, that would also apply to the other 90% of the company that wasn't union (and thus, did not have the mitigating benefits), or that were in place to manage hourly employees, but also applied to exempt (from a life) employees.

It was my job to try to mask that kind of crap from my employees, and I got called on the carpet a few times, because of it. I would do it all over again, if I had to.

Additions:

* the crap shield is made of Gor-tex so you need to protect the team but also expunge the toxins that build up within. Not all crap is generated outside of the team but you need to get ride of it.

* the crap shield is transparent so the team can see what's happening outside without being covered in it

* the crap shield is retractable so you can let some into the team's atmosphere. Not enough to cause harm, but keep them grounded in the imperfect world in which their work will live.

* the crap shield has a window lock, and you the manager are in control of it. This is for the same reason the driver of a car can lock the windows in the back seat to stop the kids from opening them when you're in the car wash.

Totally. I sometimes made the mistake of "venting downwards" or wanting to be more transparent with the team and it wasn't a good experience.

Individual Contributors usually do not want ambiguity or to have a lesser impression of the company or of someone, it isn't good for anyone.

They also lack the context you have and jump to a lot of conclusions that are usually unfair.

It's a hard job!

Agreed. The end goal is usually to make developers as productive as possible, which means a) giving them large contiguous blocks of coding time, and b) removing roadblocks (i.e. crap)

The "crap" can be politics, legal, ancient IT practices, useless meetings, constant demands for status/updates, bickering around cost/budgets, hiring, buying time to fight tech debt, and a whole bunch of other things.

The #1 job of a manager (in all fields) is to keep his people working. It doesn't matter if it is engineering, manufacturing or the local burger joint. A managers #1 job is to keep his people working.

Absolutely! A manager can either be an umbrella to shelter under, or they can be a shit funnel.

Great work gets done when you can give your engineers a hard problem (or a long list of easy problems) and let them put their nose to the grindstone to get it done, while deflecting the rabble of inane ideas for new features, shifting deadlines, office politics, customer/supplier relations, etc. etc. etc. If a manager sidesteps all those, and passes them to the engineer, there will be have no time or energy for the actual work. If they are a single point of contact where an engineer can pull in a prioritized task list and push out questions and results, that's an ideal environment to get things done.

Unfortunately, other managers which interact with these EMs can sometimes have a hard time telling the former from the latter, and have a hard time evaluating the quality of the work/difficulty of the problems being solved, so the only visible difference is the happiness of the engineering team and the accomplishments that were made.

I used to think that then I burnt out. When the manager does nothing but the crap, the manager is going to leave. The proper way is to distribute the crap evenly.

> I think the article misses what I think is a vitally important part of the job: being a crap shield.

One of my first jobs, it was described colourfully (it was in the UK) as being the team umbrella. i.e. Protects the team from the ever circling pigeons from above that like to frequently 'deposit'. :)

I wouldn't call that being a crap shield. I'd call that executing on the non-technical aspects of your team's strategy.

When teams don't see (and/or frame) those things as key part of achieving their goals the results aren't gonna be great for anyone.

All of the managers I’ve worked with on the “great” end of the quality spectrum have excelled at being sh*t umbrellas. Perhaps that speaks also to the quality of the orgs I’ve been in, as well...

This is a (the?) differentiating quality between effective management and not.

> crap shield

In Office Space, one thing that makes Lumbergh the manager so distasteful is you just know he would never do one thing to help anyone reporting to him.

> configuration galley

I like that. "Ramming speed."

> configuration galley

What does this mean?

At my last job I had an interesting (nice) experience. My boss wasn't an engineer, he was a project manager, but that didn't hinder him. I think what made him successful was that he cared. He'd say over and over, "I'm not a developer, I need help understanding." We would sit in a meeting and walk through problems. He was very calm and patient and acted genuinely interested in what the problem was. He would ask questions about what he didn't understand, and trust us on the things that we would say. It was a great experience. When we said we had a problem, he tried to understand and relay that to the necessary people. When he couldn't we'd accompany him to explain the details.

Companies really struggle with this, and in both directions. Startups and scale-ups tend to overcompensate to the point management hires get interviewed as super-ICs, where they'll be expected to answer technical stages at (or even above) the company's top IC standard, but only get a couple of basic scenario questions about management that anybody could answer. Sometimes you get lucky and they're good at both, but it's a big source of the "management by yelling at people" and "I can't have a 1:1 with you, I'm fixing a production issue" schools prevalent in such environments.

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)

I think that would be covered under the idea "Lead by example". When the manager is competent to understand, console and provide guidance to the team when they're struggling - even slight slivers of technical skills and knowhow, the rapport they build is unbreakable.

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.

I've had EMs who who really well versed in the team's technical work, because they were an IC on the team, and the complete opposite: EM was external hire

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.

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

You don't have to (and shouldn't) tell them you are doing this - word will get back to them.

I agree with your points.

I think it's the wording like you mention, in Lat-Am countries it is common to say "darle seguimiento a las entregas" or "rastrear entrega" as a way to signal that the person is responsible of making sure that things workout well including handling or helping out with any technical or communication roadblocks for the team.

I think this is because in most cases, the "when" is what their bonuses/promotions are based on. Managers don't get promoted because the code is great or the architecture was elegant, they get promoted for raw delivery and being able to say "my team delivered X in only Y days".

I recently told my manager ‘we have literally never delivered a project on time because of process deficiencies, you expect me to believe the next project will be any different?’, only to be told that we had to deliver this one on time, because it was for a client (all our previous projects were too).

I just don’t follow how that logic works..

The whole team needs to work together to create an environment that incentivizes the desired behaviors while being an enjoyable experience.

Setting in place and maintaining a system like that is hard. Telling people what to do is easy.

I once had a report who demanded, snarkily, all the things be listed on the whiteboard (as opposed to just getting them in Jira) and the meeting was set for the next day...

Knowing the team was one of those that is constantly using nearly-depleted markers and hating life, I thought to check. Sure enough... all empty, nothing to replace them with.

I thought to just let said report arrive at next day's meeting, ready to whiteboard it up only to look woefully unprepared, but I waited. I waited until about an hour before the meeting to see if they might have clued-in and sorted the problem for themselves...

An hour later I returned from a slushy 2km walk, soaked, with a box of markers that I just placed in the drawer, unbeknownst to all.

What other books would you recommend regarding management of SWEs?

> Manager is a path, but an IC shouldn't need to become a manager to keep growing in their career.

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.

Depends on the organization, some places managers don't have any involvement in anything technical, but at a lot of places they do. Managers are often involved with architecture/design decisions, resolving internal disagreements about technical matters, improving dev processes, negotiating with PMs to translate product requirements into concrete engineering tasks, etc.

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.

+1 - I had a discussion with one of my directs today as they were considering becoming an SDM. There are so many days as a manager where every moment of my time is filled with meetings and admin tasks and at the end of the day you feel like to accomplished nothing. Where as with coding you can feel like you built something and have something to show for your hours of time. I certainly miss being an IC, more and more each day..

This and also keep in mind that as mid mgr you become an IC to the business side of things, with its share of BS and politics. Now tell me, which one is "your team"... Mid mgr is not that much a position of power, more like a promise of decision control, but bureaucratic admin reality and twice expectations to meet.

Oh, well, there's some bright side to it too, it's all about the ppl sharing common goals, even if just for limited time. It can bring positive change.

I shifted from software engineering to technical program management because I was interested in the bigger picture of shipping software (after having been an engineer on a couple multi-year projects that floundered and failed due to mismanagement), but did not want to be personally responsible for hiring and firing people. I don’t have the constitution to make such big decisions impacting other people’s lives. :\

I was thinking the same thing. Plus, all the miscellaneous administrative tasks (HR, training, marketing, etc.).

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

This is a very healthy way to think about things as a manager. I like knowing why I have to do a task, to have the chance to give feedback, and to get leeway to push for what I think is best. I try every day to support those things for my team.

Growth is the greatest result of pain. I would especially listen to someone who learned lessons after having been burned themselves. I would take that over an armchair who was paid to write an article. Authenticity is an extremely valuable human resource.

As an aspiring manager of engineers, do you mean that it's far from the truth of real-life counterexamples?

I am not an manager, and this is something that puzzles me too. For an engineer to respect his manager, you expect the manager to be technically competent and in tune with recent technological developments. But as a manger you are most likely to be bit removed from technological changes given that most of the time is spent in meetings, talking, keeping people engaged etc. A few things I can think of but I don't know how effective they could be:

  * keep reading technical books, well-known/reputed engineering blogs with the intent of not understanding everything but atlas to get a gist of the technology changes

  * be engaged and attend some of the technical discussion meetings (not as an enforcer of some decision) but mostly as a keen observer.

But at some point, an engineering manager identified and hired those leads and helped to facilitate a path for growth for those sr. engineers?

This is a product/project management responsibility, and in some organizations or teams some or all of this can fall on the engineering manager side. Doing a lot of both at the same time is typically a crummy gig, as you don't have time to do both successfully for a right-sized team (you'll be either a bad manager, a bad product manager, or mediocre at both), Uou'll either be overworked or feel bad at your gig all the time.

Helping the team proactively scope and prioritize technical debt work, as opposed to product work, is almost always a critical function of managers.

I would say yes on two counts, one for his/her own growth/benefit and other for the team's benefit. If there is more work in the pipeline it keeps the team less worried about what are the future tasks they can focus on, and this becomes especially important if the company is going through a rough phase. In addition additional work also gives opportunity for the team members to work across different projects and rotate people who are driven and want to work on different projects/technologies a chance, and to retain them. Naturaally, when the team benefits and succeeds it helps the manager and improves his standing in the organiaztion.

However the ugly side of this is office politics, where some managers continuously try to expand their turf undercutting other teams so that they manage bigger teams and reap rewards. (say a bigger title).

Exactly.

HR tends to know nothing about solving "performance issues" -- especially since by and large, they tend to have next-to-zilch understanding of what the day-to-day work is actually about - let alone what constitutes good or bad "performance". So from there - their role pretty much boils down to:

"OK, so you've decided to start pushing this person out of the company's bowels. Let's make sure we do with with proper legal CYA and minimal side effects, otherwise. In fact we have system in place already - it's called PIP:"

https://en.wikipedia.org/wiki/Performance_improvement

"Ya see, you just gotta make up some quote-unquote 'goals' for the problem employee to 'agree to'. And then of course, don't actually support them (and just for fun, sometimes outright block them - subtly, of course) from reaching them. Whether they quit and/or have a nervous breakdown -- or inevitably fail at achieving the 'goals' we set out for them -- either way, in a month or two they'll be toast -- guaranteed."

The very essence of being a good manager, then -- is helping to resolve (or at least clarify) performance issues before they get "escalated" to that level (which is an ironic term, given that again, it pretty much always boils down to -- "how do we get rid of this person?")