How I became a Lead Engineer

When people ask me how I became a Lead, I often give them the short story of “I'm not so sure myself”, then be a little modest, rambling how it wasn't 100% in my hands. But only recently I've noticed that there are other engineers aspiring to lead one day, and it's only fair to give a thorough explanation to how and why it happened. As I said previously, it's never 100% in your hands, but obviously you can drastically improve your chances by understanding what companies are looking for in leadership. Below is one story of a large corporate retailer, other companies treat leadership differently based on the culture they're trying to build. However, in software engineering, you'll find there's a lot of consistency in their processes for growth and what's expected of a technical leader.

Where it all started

When I joined Sainsbury's, I came in as a mid-level PHP Developer. I joined a small Scrum team on a Digital Media On-Demand platform, basically a website that serves a bunch of different digital products. It was fair to say it was quite a mature platform, some of the services behind it were labelled as ‘legacy’ and a lot of the teams that worked on it previously already left the team. I remember my first ticket and pull request; it was actually a front-end ticket to hide a view based on certain logic. Very small and not too taxing for my first task. I managed to fix it the same day on when I was assigned and poked my Lead at the time to say it's done and ready to be reviewed. His reaction was quite positive. He was impressed how quickly I picked up the code base, and getting it tested on the development environment. I just said it only about 5 lines of code and felt the praise wasn't really necessary. The key point in this process isn't that I just ‘got it’ quicker than my Lead would expect, it's the questions I asked throughout that ask and helping my understanding of how everything works.

• How would I be able to reproduce this problem?
• How can I test the problem?
• When I raise the Pull Request, what would you want to see on it?
• Who shall I speak to for the Code Reviews?

Above are some examples of the questions I asked (or at least from what I can remember, there could be more 🤔). I knew if I didn't have all the answers in front of me, I'd end up sitting there, more stressed and worried about what I don't know. I've seen this on a variety of occasion's where engineers (especially juniors) think they're expected to just sit there and figure it out themselves. These days you'll find job interviews where the behavioural competency of a candidate is just as important as their technical knowledge. You can be the most knowledgeable engineer in the company but if you can't collaborate on problems and ask the dumb questions to your fellow teammates, you will struggle.

Taking more responsibility

Months later down the line, and after I started understanding the code base more, people in the team started asking me more questions. I became an SME (Subject-Matter Expert) in parts of the codebase. If you're new to software engineering, this isn't an easy feat to reach. You will have to do your homework on your specialism. I was fortunate in my last role to gain a wider understanding of overall web and back-end architecture, but this personally took me years of training and learning. Sometimes it takes people months to gain a thorough understanding… don't rush this. Everyone learns at different paces and it's important to remember that it is not a race. Like any career, you should choose software engineering because you enjoy it, not because it's something you feel you have to do.

This is when it got interesting. I was the SME and people started relying on me to help them with their tasks. I was essentially leading on the areas of the code base I understood. I always remember wearing just one earphone and keeping the other open for anyone who came to my desk. I knew distractions would slow down my work, but I realised if I didn't help others, they'd be just as stuck. It wouldn't give a good impression if I just told them to speak to me later and keep putting it off. This was a first good indicator where leadership starts. You need to make time for people, regardless of the pressure or workload you have. And when I say people, I mean your team. If you work for a corporate company, you're probably aware that there's a variety of different teams and divisions you can manage your time for. Always focus on the team you're assigned to.

You have to accept that distractions and unexpected discussions will happen as a leader. If that's someone knocking at your desk every 5 minutes or asking you to go into a room. It will test your patience at times, and you may go home at the end of the day thinking what you've actually achieved. But it's important to remember that others around you should be on the forefront of your mind.

• Did Barry understand what this piece of code actually does today?
• Have I done everything I could to prepare Sophie for her task?
• What more could I do to share this knowledge?

Leaders are there to serve others, especially ones they're responsible for. Holding onto vital information or misguiding others will undoubtedly come to bite you in the end. Contractually as a Lead, part of your workload is enabling others to do better, not just improving yourself.

It's important to remember that you can be a Lead Engineer without having the job title too. Getting promoted should be based on evidence that you're already doing the job, not on gut feel or belief. If this is done well, you're essentially rewarding the individual on their strengths they already enjoy doing and they'll be more grateful for it. Promotions can also go horribly wrong, the responsibility may be too much for them to handle or the expectation of their role is something they just never wanted to do. Having a career path that prepares individuals for those responsibilities is key and making sure they have a manager or mentor that can offer advice and guidance.

How am I doing boss?

Sometimes when I'm modest about my work, I've learnt to pick up body language and facial expressions from people's reactions. Some people hate it more than others, they want me to just say that I am doing a good job and give myself more credit. What they don't realise is I do, I just won't announce it to the world because my actions are saying more than words. Talk is cheap, especially when you're responsible for a whole team. Ultimately any evidence or data will solve an argument, it's important to remember that your pay grade or seniority will never top the facts.

Back to the story, my line manager at the time booked bi-weekly one-to-one's with me. Most of them were fairly casual, occasional feedback on how I was doing and making sure I was happy with how the team was doing. My relationship with my boss was pretty strong, I felt comfortable revealing my bad days to him and sometimes let off some steam with emotional charged statements on how others weren't performing.

We're all human but it's important to note that there's always 2 sides to any story. Some of my criticisms may of come across unfair but I made sure I tried to understand the other side to why my colleague wasn't performing at their best. Humans have good days and sometimes really bad days. I went to a great conference last year that boldly stated “99.9% of people aren't bad”. It's crazy how something so simple like that didn't resonate with me after so many years of my career. No one is trying to be malicious and plot against you personally. If they were, someone would of probably made a stop to it by now. Seeing the other side of the story, trying to empathise with the other shows great leadership. You're doing an intelligent assessment and trying to find the root cause to why these issue are happening. Not simply blaming the individual because they're bad or failing to sort their own problems out.

Another point I learned after becoming a leader in those one-to-one's, is that your manager isn't the punching bag you think he/she is. Yes they have the experience to deal with complicated situations but remember they're learning too. Having incredibly high expectations of your manager is unrealistic. Ultimately they are taking more responsibility than you probably see, cutting them some slack and taking tasks off their shoulders builds trust between you and your line manager. I'm not saying you shouldn't share some of your burden but don't expect them to have all the answers. Good manager's often use techniques like coaching, questioning your emotional thought process and letting you decide on what the best decision is, rather than them deciding for you.

The Opportunity

Nearing the end of my story, there was a organisational shuffle, that opened a Lead Engineer role on the project I was already on. Mike Coupe, an ex-CEO of Sainsbury's did a Q&A session from a variety of different divisions and discussed 3 key areas that helped him become successful in his career.

• Technical Ability
• Personal & Communication Skills
• Luck

And this ladies and gentlemen was just luck. I can't decide or choose when the next vacancy for a role will be open, it's completely out of my control. Furthermore, there's a decision my manager had to make to see who was capable for that role. But the areas that were in my control increased my chances. I practiced my technical ability and make sure I could collaborate with my teammates effectively.

The headline is I didn't actually expect or want the role in the first place. I knew I wanted to take a step further in my career but I never knew it would be management. When my manager approached me I was a little shocked at first and did contemplate if it was the role I wanted to pursue. I had an internal interview to test me on some scenarios on what to do when people approach me with difficult and personal questions. They were tricky, they even threw in some technical questions to make sure I hadn't forgotten my craft.

Fortunately I persevered and all went well. The exciting stuff came next and I signed the paperwork 📝.

My first few months as a Lead

When you first get a promotion, often it can be quite a gradual transition. Your responsibility will grow but won't be immediate. Day #1 as a Lead and I was just writing code and carrying on my tasks. I threw in some meeting invites for the engineers I was now responsible for and to be honest they were pretty casual and introductory. If I didn't have the answers for my team, my manager could always jump in to support the newbie Lead.

As I mentioned earlier in this post, it's not all about the job title and the piece of paper you signed. You should measure your success on how valuable you are as a team member. Remember that I was already supporting others in the team on areas of the codebase I owned. I was already doing the technical part, working on tasks and delivering value for the product. As time went on, I gradually got introduced into new responsibilities such as recruitment and contributing to the technical strategy.

Where I am now

Almost 4 years later writing this blog post, I'm still a Lead and still going through that gradual responsibility increase. There's been bumps in the road, where I've looked at my calendar and looked back to what life was like as just an engineer. I've seen some leaders stand down from management and pursue a career in purely engineering. I'll be honest that I've also thought that, but there are so many different parts of being a Lead that I'll miss if I did stand down. Just like getting into software engineering, you need to enjoy your day job. You need to enjoy the constant change in conversation, planning, strategy, measuring performance and most of all, the people. You need to enjoy their company, be curious less about the technical solution and more curious from where those solutions come from… the engineers.

Thanks for reading!

Here's a picture of me now after a successful Sainsbury's Google Hackathon to kick off 2020!