The unseen work of engineering management

Estimated reading time: 7 minutes

Key takeaways:

• Engineering managers should try to spot quiet tension early and ask whether high performers can sustain their pace.
• Good managers give stretch projects to engineers who haven’t led one.
• The goal is to fix ‘people problems’ before they reach dashboards.

---

Years ago, when I became an engineering manager leading a team, I had a pretty naive idea of what the job actually was.

Like a lot of developers moving into people leadership, I thought an engineering manager’s main responsibility was to become a human-shaped communication cable between the team and management. You give regular updates, rearrange tasks around absences, run agile meetings, assign tasks, and sit in meetings so developers don’t have to. That was pretty much how I imagined the job when I was new to all this.

I’m slightly ashamed to admit how naive that was, but it didn’t take long for me to realize some of the hardest parts of engineering management had almost nothing to do with Jira boards, status updates, or assigning tickets. They were the things that were hardest to see.

When you start leading people

When you start leading people, this isn’t your developer job with a few extra meetings. Now you’re responsible for people as well as systems. I know that sounds obvious when you say it like that, but it changes the type of problems you spend your time thinking about.

As a developer, a difficult day might mean a production problem or a tough technical decision. As an engineering manager, the difficult problem might be something nobody else has even noticed yet.

In engineering, people tend to separate technical work from people work. The technical work is code, tickets, deadlines, releases, and production metrics. Then there is the other bucket for one-to-ones, communication, culture, and leadership.

As I spent more time in this role, I stopped thinking those things were so separate.

Poor communication creates rework. Too much pressure decreases quality. A lack of psychological safety causes people to stop speaking openly. Problems can then stay hidden until they become a missed deadline, a bad technical decision, somebody wanting to leave the team or company, or a production incident.

Watching for these signs and taking small precautions against them isn’t separate from delivery. It is directly linked to team performance. You often only see the value of this work when it’s ignored. By then, you’re dealing with burnout, conflict, or a team that has stopped working well together.

A big part of leadership is noticing these earlier. So here are three situations where I’ve seen that matter most.

Identify quiet tension before it turns into conflict

Just like in any team sport, it’s natural for engineering teams to have internal conflicts and tensions. Tuckman’s Stages of Group Development describe this as the storming stage. However, not every conflict starts with a big argument. Sometimes it starts with two people talking to each other less.

When I was a young and enthusiastic junior, I used to work closely with two very experienced developers. They would put their heads together on matters of architecture and implementation, and I made it a point to listen in. In those early days they set the standard for how a brainstorming session ought to go, and I learned a lot from listening to their discussions.

Over time, however, the dynamic shifted. Their disagreements stopped feeling normal and eventually they started avoiding each other. Instead of speaking directly, they would sometimes go through somebody else (me being that person on occasion).

Decisions took longer. The conversations grew short and defensive, and getting a decision made took its time. Other people in the team could feel something was wrong even though there hadn’t been one big argument or obvious incident.

For quite a while, it was easy to dismiss it as two senior engineers with strong opinions. Eventually, it became a much bigger ‘people problem’ and HR had to get involved.

As engineering managers, we watch delivery signals: missed deadlines, blocked tickets, production problems, and quality issues. People give you social signals too. Two engineers stop asking each other for reviews. Somebody becomes quiet whenever a particular person speaks. People start working around each other instead of with each other.

None of these things tells us there is a huge conflict brewing. Technical disagreements are normal and useful.

The crucial part is whether the disagreement has started changing the way people work together. Are they avoiding each other? Arguing about almost everything? Communicating indirectly through Jira comments, colleagues, or group messages?

Sometimes you just need to say: “I’ve noticed something seems to have changed in the way you two are working together. Am I reading that right?” You might be wrong and that’s fine, but sometimes you find a problem while it is still small enough to do something about it.

Recognize when high performance becomes unsustainable

Most teams have someone who is incredibly dependable. The one who volunteers. The one willing to take on difficult work. They help other people and still get their own work finished. As a manager, you appreciate somebody like that, but a dependable engineer can slowly become overloaded without anybody noticing exactly when it happened.

I once worked with a mid-level developer who had recently been promoted from junior level. He was fast, eager to learn, and hungry for more responsibility. He volunteered constantly. At first, it looked great, but he was also staying late often and taking on more and more.

I’d noticed it and we’d talked about working sustainably. He had also just been promoted and understandably wanted to prove that he could operate at the next level. Less than two months later, he came to me completely exhausted. Soon after, he asked for two weeks away because he simply couldn’t look at a screen or code anymore.

You could say he took too much on and should have managed himself better. There is some truth in that, but managers also have to pay attention to how somebody is performing, not just whether the work is getting done.

A junior engineer might take too much on because they want to prove they belong. A mid-level engineer might be trying to show they’re ready for promotion. A senior engineer might have slowly become the person everyone relies on. Different reasons, but similar outcomes.

One dangerous assumption is that people will tell us when they’ve got too much on. Some won’t. Is somebody working late all the time? Have they become the reliable person in the team who gets every urgent problem? If they’re off for a week, does half the team suddenly not know how something works?

Engineering culture has always had a slightly unhealthy relationship with heroes: the person who saves the release, fixes production, or knows that ancient critical system nobody else wants to touch. It’s great to have someone like that in your team, but if daily tasks depend on one person becoming the team’s hero, you’ve built a dependency.

So these days I’m less interested in asking only “are they delivering?” and more interested in knowing “can they keep delivering like this? Can they show others how to deliver like this?”

Help your teams grow beyond the next sprint

There is another management decision that can look bad if you only care about the next sprint. Sometimes a team gets slower because people are learning or taking on harder responsibilities. 

Imagine you’ve got a mid-level engineer who is ready to lead a project and a senior engineer who has already led similar projects several times. If your only goal is to get the task delivered as quickly and safely as possible, the obvious decision is to give it to your senior  engineers. However, if you make that same decision every time, when does the mid-level engineer ever learn?

Eventually, somebody has to get their first opportunity. They may stumble, make decisions you wouldn’t have made, or need you to step in and help. Yes, your project might take longer. Simon Sinek describes this through the concept of the “infinite game” in his book: the aim is not simply to win the next round but to continue to play. I think engineering managers should think very much the same way.

Six months later, you may have an additional engineer who can take on and manage a project. More than a couple senior engineers are available to take on new complex tasks․ That’s why I don’t think engineering managers should focus on one sprint at a time. They need to consider both short- and long-term team needs․

The invisible work behind healthy and sustainable teams

All of these and many more are probably what make a lot of this work difficult to measure.

When things go well, there may be no dramatic outcome you jump in to fix. You notice tension early and there is never an HR case you raise and handle collaboratively. You take work away from someone before they burn out. You give someone space to lead something for the first time and maybe delivery is a little slower than it otherwise would have been.

All those things don’t look particularly impressive on a dashboard. Perhaps they won’t impress your managers either. Yet by the time a problem does appear on a dashboard, it may have been developing for weeks or months.

A significant part of engineering management is doing the work early enough so that the bigger problem never has to appear.