Things I've learned in my 10 years as an engineering manager

Kinda like; You got to do, what you got to do.

Honestly, I’m not sure.

If I know what was going on transparently I am stressed. As an ordinary employee, I don’t need to know everything and therefore don’t need to worry about it.

> They protect the team from unnecessary stress and pressure, but don’t hide reality from them.

I was going to highlight this as well, but it is also one of the trickiest parts of the equation, because by definition this inevitably involves a lot of politics and social implications.

What I have learned over the years: let the overall direction, and also the overall competitive pressures, filter down through your umbrella. But shield them from the details and your specific efforts here, unless it is relevant.

Maybe even more important, though - recognize inflection points in your company and your group. How you manage during routine times and during stressful times may well be very different. If they're not, then you have a serious problem.

That's true for a junior engineer, but the more senior engineers should be given a view into the organization's priorities and business challenges.

I recall hearing that Google had a term similar to this:

A "shit umbrella" was a manager who protected the development team from all the politics, blame, and mismanagement coming from above.

A "shit funnel" was a manager who directed all the shit coming down, directly onto the team.

>> Being a "transparent umbrella" does require knowing the personalities of your reports, some people do get distracted when they think higher-up decisions or unhappiness are going to affect their team.

There is the expectation that the manager knows who will be distracted. This is a basic part of knowing your people. I know which of my colleagues is going to get distracted without having the level of communication that my manager has. On one extreme, they just forward information knowing a report can work with it. One the other, the manager has to translate and communicate every element.

Ideally, the manager is already working on a way to ensure their report can handle transparency because that means they can work autonomously. You can't have individual contributors lead, if they are going to run into issues as soon as they discover what is going on overhead. They may not understand it yet, but they should have coping and mitigation strategies.

Engineers can be the worst group you could deal with when it comes to overhead conversations when they expect things to be orderly. Your organization is failing when everything has to go through managers and people can't operate independently.

My favorite manager told me a similar analogy before I left, but with a caveat; a good manager has to provide cover for the team, but it's up to the team to hold the manager up - just like an umbrella.

> require knowing the personalities of your reports

I think this an underrated quality.

I am not an EM (anymore) but I see a lot of more junior engineers struggle with ambiguity and complex decision making in general.

It is not uncommon to end up in situations where there are not clear right answers and developing the techniques as an individual, and as a technical contributor to navigate these well is tricky.

I don't think this is an EM specific function at all though and is just something more experienced people should be doing for their team. I think the EM definitely has a role in making sure people identify that they could benefit from that kind of help and make sure they find it, but doing the actual coaching is optional.

Coaching doesn't imply superiority. Most coaching can be done with little to no context and the goal is to guide the other person in finding the right answer on their own. I think you might be confusing coaching with mentoring.

As an example, I attended a coaching training session and when we broke out in groups I played the coach role. The other individual brought up a concrete issue they were having and I was able to unblock them and I never met that person before. I was their guide even though I had no context (but I have experience mentoring and coaching).

I've been a manager for years and there's a lot outside of raw technical ability that a good coach and mentor can keep you honest on. Rarely will you find someone who's reached full potential or who doesn't want to improve at all (maybe surprisingly based on your comment but I have found seniors to be the most eager to grow)

Most of the job is noticing friction and clearing paths — which requires context and trust more than technical superiority.

In practice: Start a note for each engineer you manage. Fred Brooks called this a "career file". Start by writing down things that frustrate them enough to complain about publicly. Add hurdles that come up in their one-on-one. Identify problems you can solve, problems you understand but cannot solve right now and problems you do not understand.

Then put on your PM hat; sort by priority and execute.

I am an EM that manages several senior engineers currently. I find it super common for senior engineers to get promoted mostly on technical merit, we end up thinking the rest "can be coached". Or it's coaching to the next level. Here are some areas I coach them on:

- influencing without authority. Managing up. Leadership.

- getting work prioritized

- providing useful performance feedback (promos etc)

- coaching and giving feedback to early career engineers

- communicating ideas effectively

- developing 1YP+ plans for their areas.

- idk, there are a lot, senior engineers are rarely "complete"

In my experience, I have used coaches that don’t have more technical skill than me, but are able to provide insight, questions, and provoke me to think through my problems in ways I might not have otherwise.

I break things down into coaching vs training vs mentorship.

Training is when you need to learn a very specific skill from someone that knows more than you. A great example is learning how to drive - it requires training from someone who knows more than you.

Mentorship is when you need to grow more holistically and are learning from someone that is significantly more advanced in your chosen area of study than you. Usually this involves not just technical training, but also a mindset that you wish to learn. Examples of this are apprenticeships or when you seek out a mentor that you think has done well and wish to learn from.

Coaching is when someone may not have more technical skill than you, but is still able to help you improve by probing, prompting, reflecting, or observing. A great example are sport coaches, who are not necessarily more skilled than many of the players they coach.

These are loose and blurry definitions, but I hope it helps frame another perspective on coaching.

Dude, soft skills. 80% of any job, software development especially, is messy human problems. Engineers more than anyone can generally benefit from improving these skills.

I think the biggest thing I've found myself teaching my younger colleagues is basically the internals of the systems or in what ways some of the things they've written might fail.

I haven't written any production C++ in about 2-3 years and honestly lost track of all the language updates since c++14. But when I explained how the code they write gets translated to assembly and runs on the machines, that's what i felt demystified the large codebases to my younger colleagues.

Same with many other topics - the event loops behind the JavaScript async/await, memory mapped io behind every read/write calls their operating system syscalls, basic data structures/algorithmic complexity behind their DB queries, scenegraphs and graphics APIs behind user interfaces etc... especially when pair programming.

I don't think I'm superior to them in any of these areas. I feel I'm fairly slower than them when writing code in any of these things. I definitely haven't kept up with all the changes in web frameworks or CLI tools or vim plugins. But sharing the behind the scenes knowledge helps them write better code is what i felt.

Top tier sports people still have coaches. Some even have multiple coaches. Musicians have managers.

Unlike coaches for kids/ novices these folks aren’t necessarily better at the craft.

Yet, they (ideally )have a outside perspective that would improve an individual in their craft.

Coaching in my role is mostly about seeing the person up for promotion and helping them focus on the right stuff for the teams success. Even great senior engineers sometimes lose focus or miss the sentence in s career ladder that doesn’t mesh with what they want to be doing.

I’ve got a senior IC who is always hesitant to reach out to non-engineers, so to coach him I’m constantly asking him to reach out directly. It will improve his impact if he does so.

The mindset shift from IC to EM is very complex. And the newly appointed managers don't always know how to not be a programmer when in that role. It sometimes bleeds into the reports' work and damages than helping.

I guess the "coaching" is to understand that mindset shift.

How does a football coach do their job if they can’t run or throw or block as well as the players?

Not an EM, but definitely think a strong technical EM can provide valuable feedback when it comes to system design and data modelling.

There are already some great responses, but I want to add that one effective way to coach senior employees is to give them responsibilities one level above their current role and then provide feedback.

For engineers aiming to move into management or staff engineering, you can assign them a project at the level they aspire to reach and give feedback once they complete it. For example, for an engineer aiming to be an EM, I expect them to lead not only meetings but also all communications related to this project, while I act as their director. Afterwards, I provide feedback.

It doesn't have to be that extensive right away. You can start small, like asking them to lead a roadmap meeting, and then increase responsibilities as they improve. Essentially, create a safe environment for them to grow.

Here are a couple more things: - holding people accountable to their own goals - like getting a certification or learning about a particular, new topic. This benefits the company by having more highly trained people, and the individual benefits from higher success rates or more depth of learning accomplished. - setting expectations for promotions. Often, it’s a squishy guessing game about when a promo will come, but if you’re able, you can set the bar and hold the person to that to set them up for success. - one tangible example of coaching is just noticing bad behaviors — like, being late to meetings, lazy code, missing deadlines… and letting the person know you’ve noticed it, understand what’s going on, and hold them accountable to stopping the bad behavior.

Coaching does not imply superiority. I doubt any sports coach could substitute any player in a competitive game, yet they can coach them to become better version of themselves.

What engineers usually struggle with as they grow into more senior roles is the transition from being primarily a technologist to being a leader. This is such a huge shift for a lot of engineers and requires soft skills and communication style adjustments. The more senior you are the more your focus shifts from coding to listening, networking, influencing, selling the technical vision, building trust relationships, understanding what other engineers need and want, to mentoring, to raising the quality of the team around you through influence to motivating others as well. Being able to influence the product direction, being able to express in business terms why something has to be done or should be a higher priority etc. Also, understanding the organization and becoming organizationally savvy is important.

All of these skills take time and practice to achieve, and good managers can guide their people through the journey.

> the word "coaching" implies one party is superior to the other in one very concrete area.

The opposite seems obvious to me. After all, your manager isn’t writing the code. He’s not your boss because he’s a better coder than you are, but because he’s a better boss.

(If this does not fit your experience, I’d recommend quitting your job as soon as practicable).

I sympathize with keeping one's mouth shut for political reasons. Having a boss who angrily shouts at anyone who dared use their own brain and offer an idea, I learned to keep my mouth firmly shut even if i saw countless problems coming down the road.

When I was in the Marines, we had a rule of thumb that every Marine needed to know their own mission and the mission of units two or three echelons above them. So individual Marines needed to know their mission, their platoon's mission and their company's mission. Company commanders needed to know their mission, their battalion's mission and the division's mission. More specifics for echelons closer to you.

This is complicated by the fact that Marines deploy as MEUs, MEBs and MEFs [1] which aren't "pure" echelons, but it's a rule of thumb and guiding principle more than a hard and fast requirement.

I've ALWAYS been annoyed by engineering organizations that don't think developers at the leaf nodes of the org chart need to know what's going on. Devs may not do anything with the info, but letting people in on what's happening seems to send the message that "management thinks you're important enough to hear what we're working on" and every now and again, individual devs need to make decisions that depend on these more abstract / higher-level goals.

1. https://en.wikipedia.org/wiki/Marine_air%E2%80%93ground_task...

Yes, he has a lot of accumulated experience!

I've had one good manager and I concur. As valuable as gold.

I've always told my engineers that their job is to get me fired for redundancy.

Agreed, I was fortunate enough to learn this lesson early in my management career when I was passed over for a promotion I felt I deserved for someone who's team was able to operate without them. Looking back, I know this is why he got the role rather than me, my team couldn't live without me whereas his could and therefore he could take on the expanded role.

There’s a reason you never see posts like: “My jump from BD to software engineer”

I’ve never met a sales person as broadly capable as your average engineer.

The curse of competence is organizational as well

I was wondering about that for a while now - it feels in my last few jobs as an EM, the major part of my work (or rather the most influential one?) was managing, coaching and guiding product. The realization was actually quite simple for me: while hiring in engineering is defined by an sometimes absurd number of interviews, code challenges and so on, product is a case study and you're good: and that doesn't seem to be doing the trick.

This is one of the reasons I think the "replace developers with ai" doesn't really fly in reality, as devs/engineers are typically the smartest people in any company I've worked for in a few decades. I don't see how the other folks could pull the weight via prompting.

I think dividing responsibilities across so many different managers has become too much of an anti-pattern for small and medium sized companies.

The least productive tech companies I worked for in the past decade had a nearly 1:1 ratio of engineers to different manager types. Our teams of 3-4 engineers had to work with our engineering manager, a product manager, a project manager, and a program manager at minimum. If you did UI work you would work with another UI/UX manager.

The minimum timespan to get anything done was measured in quarters. You could expect to have to spend more time scheduling meetings and following up with all your different managers by a factor of 10X or more than time spent doing anything related to code.

Contrast this with another employer I had who was very clear about the fact that we were not a big tech company and we were not going to structure our teams like one. We kept team units small and made them work together as a unit, not a disparate collection of managers that had to be appeased. We shipped a lot and we shipped fast.

We need to stop trying to use complicated and divided management structures everywhere. Companies with small teams and clearly unified management structures will always perform better than the management styles where responsibilities are divided across 5 different people and even basic work requires coordinating all of them through meetings

As someone who did get on the management track a couple of years ago myself, I think it’s great you have that perspective. I miss being able to turn on some tunes, code for a few hours, and call it good for the day. At the same time, I have always naturally fell into leadership positions I think mainly because I like helping people make better decisions. As an IC, I despised broken processes, bad decisions from product, and overall poor management. As an engineering manager, I have some amount of control over these things and I hope those I manage, as well as our users, have benefited from me being in this role.

A few examples of things I heavily influenced:

- reduction in investment of time, effort, and cost going to offshore engineering. We’ve reduced bugs and effort from our engineers in coordinating between disparate time zones.

- advocacy of a design system shared between design and dev teams. We now have one.

- reduction in the amount of meetings our devs are expected to attend weekly, increasing time they can spend building

- heavily advocating to reduce number of clicks for our users to get where they need to be, benefit UX greatly

- better defined incident management process

It’s not perfect though, the amount of control I have is still limited, and I am in meetings basically all day sometimes.

While I will say that would have sounded like hell to me a couple of years ago as an IC, I have been able to sway the direction of the company meaningfully in ways that feel ultimately more impactful than what I could have done jamming on some code in the same amount of time. The cost of doing so is a little more stress, but hey I get to do so from the comfort of my home and I’m allowed a good amount of schedule flexibility outside of some specific meetings each day. It’s definitely not for everyone though!

And most the meetings end up with the same people in them where we're just repeating the same shit to an additional 1-2 people per each meeting

At the end of the day, the goal is to make a product that people find useful. How that ends up happening is almost completely irrelevant to the people actually using the product.

If you consider product as a proxy for customer, I think it gets a bit easier to understand. Customers don’t care about architecture (unless you have a technical product where they do actually need to know architecture). They don’t care about many of the details. They just want their problem solved.

For software engineers, our goal isn’t to necessarily know what makes good product or not - but we do need to make sure that what we’re building solves an actual customer problem or need.

> We don't say "Everyone needs to care about software architecture, even Product"

We absolutely should say that. I was an engineer for 13 years and have now been in Product for 8 years. I work on a highly technical Product team, and it is absolutely an expectation for myself, my peers, and my reports that we should ensure we fully understand our Product, including its software architecture, and have an opinion about it. Engineering ultimately decides the "How", but they cannot do that effectively if Product cannot articulate an opinion about the architecture guided by an understanding of things like expected scale, potential future integration decisions, and other cross-organizational expectations that may not yet be codified. In general, Product should have an educated opinion on anything that is a one-way door, and so should Engineering. It should not be a unilateral decision, and if either party is unable to form an informed opinion, that's an organizational miss.

> How does this person talk about other people?

I find myself referring to my contractors as: Workers.

What does that mean about me?

I can't call them employees. I read the communist stuff a while ago and decided I didn't want to be exploited, so I thought this was just the proper terminology.

But people on the internet loath being called a worker and have called me out on this.

Meanwhile I yoyo between to nice and too hard... I think I'm naturally too nice to the point of failure. I seem to only be 'too hard' for a few months before I go back.

Thank god my industry is high demand, I think even with bad management we will survive. (I got a masters in Engineering Management + read 10 books, but management/supervision orthodoxy is diverse and contradictory.)

I've had great experiences being managed twice by very humble engineers who've made the transition to EM. Both were sacked within the year by their boss because they didn't play the corporate politics game.

Because it's a good heuristic for a functional and resilient team. People don't usually means it literally, more like "if I disappeared it should be pretty painless for the team to continue along for a month or so and to find and onboard a replacement".

The way I read it is not to be needed for normal functionality of the team, not to "not be needed" at all. Akin to a ship's captain - for the most part a ship works without a captain just fine, but that doesn't make the captain's job redundant, it's just he's needed for specific occasions, otherwise, he's just making sure the crew works as a well oiled machine.

I think the points made at mostly for a front-line manager though, not so much for a middle manager.

cause it means: I lead them so good that I do nothing and still get my salary.

“Don’t be needed” isn’t “don’t be valuable.” The EM should not be a bottleneck. The EM should be able to take a vacation without being paged. (So should anybody on the team!)

My teams would slow down without me because I can due process tasks more efficiently, but nothing demands me to be in the loop.

The goal should be to have teams who want you to be supporting them, not need you to be supporting them. Getting teams to the point where they don't need you isn't actually that hard. They might be only performing at 50% effectiveness, but that's fine if the work is getting done. You should build a relationship with the teams so they want you to support them to get to 90% or even more.

If your teams fail to function without your help then you're clearly not supporting them well enough, and you can't take a vacation or go off sick or be promoted. That is not optimal for anyone.

You’re taking it too literally, it’s not saying don’t be useful, it’s saying don’t make yourself a bottleneck. It’s a very common failure mode for new engineers turned manager, leading to a frustrated team that feels micro-managed and the perception from leadership that you don’t have your shit together and can’t adequately handle the scope you’ve been given.

A really good book on this is "Turn the ship around".

Your role is to improve your staff to be better in their jobs. Ignoring the Manager/Engineer caste system, there is a lot general leadership in both roles.

You want your staff to be able to integrate and find information that allows them to make decisions, you don't lose accountability or responsibilty.

There is a big difference between

- "I've looked at the details, and I think we should do X, what do you think?"

and

- "What should we do about this?"

In the former, you can add extra context, and help your report understand details that may have been hidden or unknown to them. In the latter you are allowing your report to shift all the burden to you.

Its more about being a servant leader and not a bottleneck than literally being "not needed". Its a mindset of wanting your team to be able to operate without having to check with you (the EM) on every little thing. I've also heard it called having IC's be a "manager of one" where they can independently work on things, get work finished, etc. without needing constant nagging.

A good manager I had once had the approach of setting guidelines and "just getting out of the way" and I try to follow that, it works well for most people.

I think of it this way:

Is your goal for the software you write to need constant intervention, or would you say you'd aim for it to run smoothly with few bugs?

The team is akin to a piece of software architecture, only much more complex and comprised (partially) of humans.

You want someone to build that team and then have the team up and running, delivering value. When it breaks, or you want it to do new/different things, you need someone to step in to fix it or change it.

There is an old saying that rings true here: "People don't quit jobs, they quit bosses."

Maybe point 9, trust but verify, should be extended to AI coworkers as well. I would love to have tools to verify AI code by quantity.