Engineer to Leader - Part 1

Around 2014, I was working as a contractor for a telematics business in Altrincham. I was pretty happy doing that, but then two things happened in the space of a week:

• I found out that in about 9 months I was going to become a Dad.
• The engineering manager handed his notice in, and the operations director offered me his job on a permanent basis.

I’d always liked the idea of running my own team, and now things like paternity pay, pensions and paid holidays felt a lot more important to me. So I decided to take the role, and all of a sudden I was the boss of a group of people I’d been working with for the past few months.

I didn’t have any other technical leaders in the business to learn from, and as a result I made pretty much every mistake you can think of. I’ve been doing various engineering leadership roles for the best part of ten years now, I like to think I’ve learned some lessons along the way. I’ve decided to do a series of blog posts that cover some of the things I’ve learned, partly to share with the reader, partly to solidify my own learning, and partly to encourage discussion.

I’m not, nor should I ever be, the best engineer on the team

Anyone who’s worked with me and is reading this will probably laugh now, as I tend to come across as confident (perhaps overly confident at times), but the reality is that I’ve always struggled with imposter syndrome. I’ve had the privilege to work with dozens of people over the years who’s technical capability, people skills and/or organisational ability leave me in awe, and I constantly compare myself to them. This was manageable as an individual contributor, as I’d have my own wins and felt I could lean on other people if needed.

As soon as I was the BOSS, it felt like a spotlight had been shone on this particular insecurity. All of a sudden I felt like everyone would be coming to me with their technical problems and expecting me to have the answer. And every time I could see someone on my team struggling with something and I couldn’t tell them the answer straight away, I felt like I was failing at my job.

So that was the first thing that I had to wrap my head around: just because I’m the team’s leader, I don’t need to be the strongest technical person on the team. Once I’d accepted that, I realised I needed to learn how to be an effective boss, because it is a totally different job.

Transitioning from Do-er to Enabler

This was the next difficult lesson I needed to learn. Working as an engineer, the fruits of your labour are very tangible. You can see working software, you can look at your commit history, you can fix a bug, the list goes on and on. It’s fairly easy to write out a list of things you’ve done at the end of the day and feel like you’ve earned your money. What you contribute as a team leader can feel like more work, but it’s much harder to pinpoint what you’ve actually done.

Whilst I’ve always found ways to remain hands-on technically in some small capacity, the role of a leader is very much more an operational one. The focus of that isn’t doing the work, it’s enabling other people to do their work as best they possibly can, and even then there’s definitely a wrong way of going about it.

My initial approach on this was trying to be a “shit shield”. The team had their main objectives they were working on, so I saw it as my role to deflect away the small stuff that would distract them. Things like ad-hoc requests from customers, reports that needed running, investigations into data issues, small bug fixes. So I filled my time with all of this, but that wasn’t leading the team. The net result of this was:

• I wasn’t making any time to understand how I could support my team doing the things they’re actually working on
• I didn’t have any time to do all the people management stuff that people rightly expect of their boss
• The team felt like they were being kept in the dark about issues with the software they are responsible for, and in some cases, emotionally attached to.

From speaking to other people who have been in my situation, they’ve done exactly the same thing, so if you’re doing this then don’t beat yourself up over it. You’ve recognised what the responsibility of the role is (to enable your team), and you’re trying to solve that problem using the technical skills and experience you’ve picked up in your years as a software engineer.

When these things come up, as they inevitably do, then it’s your job as the team leader to ensure your team have the capacity to handle them, and you have to depend on your people to resolve those issues for you.

You can talk to your team about what the root causes of the issues are, and help them to find the capacity to resolve the root causes to minimise the disruption. For example, if you’re getting repeated requests from customers for data extracts, you could work with the team to design a self-serve capability. If you’re seeing a large number of bugs raised by a certain area of the system, you can lead some root cause analysis and work out a plan for reducing the number of bugs, perhaps by improving test coverage in that area of the code.

The key message here is that it’s the team’s job to do the work, and it’s the leader’s job to figure out how to best enable the team to do the work.

There is plenty more that I’d like to share from this journey, so watch this space for further posts in this series…