Loneliness in Engineering Leadership

Overcoming isolation through peer support

Photo by Chris Nagahama on Unsplash

Peer Connections

I caught up with a peer earlier today, another Engineering Manager leading a close proximity squad. We’re both fairly ruthless with pruning our diaries, but these meetings have stuck - a sure sign they’re proving valuable to us both. It’s a recurring meeting we’ve kept for the past few months to get feedback, vent, get a second opinion, or exchange ideas.

What’s most striking about these sessions is that more often than not, we’re working on the same problems without realising. I’ll come to the session with a challenge, expecting it to be unique to my context, only to find we’re facing the same thing. For example, today I started a conversation about balancing the pace of delivery with collective team knowledge and up-skilling. The challenge is that teams often default to pace, working through tickets quickly and dishing out instructions to less experienced team members, solely to get work delivered to the required quality. In isolation, it’s an admirable feat.

Hidden Costs

The missed opportunity here is the long-term inefficiency it breeds in the team. Those leading the work, the pace setters, work tirelessly to keep things moving. In doing so, they solve multiple problems, anticipate issues, and get to know the codebase intimately, growing their expertise. However, as a collective team, we're suffering. Less experienced team members find it hard to keep up. They lose confidence, take instructions they don’t fully understand, which leads to mistakes and further erodes confidence (note to self, write an article on confidence in software engineering!). Over time, the knowledge gap widens, and the roles people play in the team become more rooted. Without intervention, the problem grows until either (a) someone leaves and norms are challenged/reset, or (b) someone is brave enough to speak up, momentarily slowing the pace and affording a chance to up-skill others.

"In practice, I’ve rarely seen teams perform these practices in their strictest sense, instead adapting them until much of the intended team benefit is diminished."

There are well-established methods for handling at least part of this problem: pair programming, where two people work on a problem with one driving (writing the code) and one directing (thinking ahead), with regular rotations; and mob programming, where the whole team focuses on a single problem collectively. In practice, though, I’ve rarely seen teams stick to these practices strictly, instead adapting them to their environment and gradually watering them down until much of the intended team benefit is diminished. These practices take discipline, huge amounts of commitment and energy and work well when the environment is setup to support them, which is rarely a universal norm.

Slowing Down

Returning to the peer discussion, we debated the role we as leaders play in this scenario. We concluded that ultimately, given the context we’re in (meaning this isn’t always the right answer everywhere¹), our role is to ‘slow the team down’. It sounds counterintuitive, but it’s a founding principle of a good team: sustainable delivery as a team, not at the expense of the team. As Managers and Leaders, this is a lever we can pull and a responsibility we must handle. As long as we observe and accept an unsustainable pace without comment, we’re setting that bar of expectation for the team.

Finding Support

This brings me to the headline of this post: Loneliness in Engineering Leadership. Team pace is just one of many challenges a team could be facing at any time. Not all are immediately visible to the team—if they were, they’d likely self-heal. As an Engineering Manager at the squad level, it can often feel like you’re a team of one. You wear the manager hat, so whilst you’re ‘in the team’, you aren’t necessarily ‘in with the team’. You’re responsible for challenging team norms, nudging the team forward, calling out problems, and providing feedback even if it’s unpopular. There will be times when the team celebrates your ideas and appreciates your insights, and other times when you question whether what you’re doing is helping, whether your diagnosis of a situation is correct, or whether you could have phrased feedback differently.

In these scenarios, having another Engineering Management/Leadership peer to share your struggles with helps immensely. It can be incredibly fulfilling just to know that you’re working on similar problems, or that the approach you took is one they align with or would have taken themselves.

It highlights the importance of remembering that whilst you might be leading a squad, your 'first team' are your leadership peers—the group collectively leading the teams that make up your Engineering group. It’s unnecessary to experience loneliness when there are others just like you feeling the same way, facing the same struggles, and ready to support one another. 

1. It’s rare an answer is ‘one size fits all’ - although in my experience the ‘slow down to speed up’ approach is often fitting.