Reflecting on my journey to becoming an engineering manager, I share the challenges and lessons learned in balancing technical expertise with the essential people skills needed for effective leadership. This post explores how my experiences shaped my management style and approach to team-building.
Jump to heading How typically do you become an engineering manager?
Becoming an engineering manager often seems to follow a common path where the role is awarded to those who have been with the company the longest or who possess the most technical expertise. Unfortunately, this approach frequently overlooks the importance of people skills, which are crucial for effective management. Many companies fail to provide training for aspiring managers, leaving individuals to transition into these roles without the necessary preparation. As a result, managers often struggle with fundamental people skills, such as fostering positive team cultures, giving constructive feedback, and navigating difficult conversations. This can lead to teams that are made up of technically strong individuals but lack cohesion, morale, and clear direction.
This is just my take, but I feel it's a fair summary. I've been fortunate to have some really good managers, but I've also been managed by individuals who, despite having many years of experience, didn't possess the skills to work effectively with me. Having a poor manager is the one of the most common reasons why people leave a role.
Back to the question at hand, it’s usually because you have the most years under your belt, either at that company or in engineering experience.
Jump to heading How I became an engineering manager
TL;DR: I believe I was given the role partly due to my soft skills, partly because of my passion for discussing engineering, and also because I had "enough years under my belt." I've alternated between management and individual contributor roles over the last six years. It took about three years for me to start feeling comfortable in management and around five years to truly gain confidence in my abilities.
Jump to heading 2018 - First management opportunity
In 2018, I returned to Bath, England, after spending a year in Canada. After exploring various opportunities, I accepted a position at a small creative agency in Bath called Ready, which had a team of just 11 people. I quickly built a positive working relationship with the owners, and they soon asked me to manage the two engineers we were planning to hire. Having mentored engineers in the past, I felt ready to take on the challenge of management.
I’ve always believed that I have strong people skills and the ability to explain technical concepts to non-technical audiences. My passion for engineering processes and coding standards, areas where the engineering team had limited experience, likely set me apart as a candidate for management. I was grateful for the opportunity.
Unfortunately, we eventually had to let one of the engineers go. This was a challenging process for me, both emotionally and in terms of questioning my abilities as a manager. While I believe we made the right decision—it wasn’t the right role for the individual, and we provided ample opportunities for improvement—I struggled with asking for support early on, delivering direct feedback to my report, and safeguarding my own well-being. These challenges made me hesitant about continuing in a management role. So when it came to looking for my next role, I opted to return to an individual contributor position.
Jump to heading 2019-2020 - Individual contributor and management take 2
I was thrilled to take on my first full-time role at a start-up, at Studee, an education. Our engineering team was small at the start, with just four of us: a BE engineer, a QA engineer, a lead engineer who also handled middleware, and myself on the FE. The engineering team and the broader company team were fantastic, and I was thrilled to be coding full-time again. About 10 months in, as the engineering team began to grow, the leadership team (CEO/COO/Lead engineer) approached me about taking on the role of lead FE engineer. Initially, I declined quickly, as my previous experience in management had left me hesitant, and I was thoroughly enjoying coding. However, Lee, our lead engineer, had created an excellent environment that allowed me to grow into a more well-rounded engineer and deepened my front-of-the-frontend skills. After some time for reflection and further discussions with Lee, I decided to give management another shot, encouraged by his belief in my potential.
A few months later, we had to let go of the first hire I made. They were not contributing as expected, and the process was drawn out, affecting me personally once again. With the added pressures of the COVID-19 pandemic and my wife’s pregnancy, it all became overwhelming. I needed to take some time off after the dismissal. However, the company provided excellent support, and I believe we made the right decisions for everyone involved. Although it was a bit easier to address poor performance this time, I was still far from feeling comfortable in the role.
I continued in the position and made some progress. I believe I improved at running one-on-one meetings, became more confident in giving direct feedback, and gained valuable experience in making architectural decisions alongside the other lead engineers.
Despite this growth, when it came time to look for a new role, I was eager to return to being an individual contributor. I wanted to focus more on coding, and I found managing to be draining.
Jump to heading 2021 - A break from management, a horror show experience of being managed, and then back to it again
By now, you might be wondering, "Why do you keep returning to management if you don't enjoy it?" A fair question, dear reader, and the only answer I can give is that I am highly competitive with myself. I take on challenges that seem daunting because the satisfaction of overcoming them drives me.
I took on a new role writing FE code with Vue.js 2, which was my favourite JS framework at the time. However, after about six weeks, I left the role due to the Lead FE Engineer being a poor manager. I've learned as much from bad managers as I have from the good ones. This individual was a classic example of the "first in the door gets promoted" mentality. I don't blame anyone; on paper, it made sense—they had plenty of experience and wanted to manage. However, they were neither a good communicator nor were they interested in collaborating. After completing a task where my brief was given via Slack "make a show/hide password input button", the feedback I received was, "This component makes me want to poke my eyes out with glass." From that point on, I tried to improve the situation, but ultimately, working with them was negatively affecting me. Coupled with a ruptured Achilles tendon and a five-month-old baby at home, I had enough.
What I can say is that the Lead Engineer and CEO were amazing. They truly supported me, and in the end, the manager I had left, and I returned. The way the senior leadership backed me up has always stayed with me as an example of good management. They arranged a call between my manager and me to discuss how we could work together, focusing on collaboration rather than finger-pointing. The CEO also made it clear to me, stating, "No one in my company will behave like this," reinforcing that the company values were more than just words from the executives.
When I returned, we brought on two FE contractors, and over the next four or five months, I naturally transitioned into the leader of our small team. Strangely enough, I found myself wanting to manage again and communicated this to the lead engineer. We regularly caught up, and he gave me clear objectives to prove I could handle the role before officially appointing me.
The key lesson from this period was learning both effective and ineffective management, particularly in handling toxic situations. Observing others provided very valuable for both.
Jump to heading 2022 - Starting to get the hang of it
I was given the opportunity to lead the FE team, which was growing rapidly. We partnered with a company called Intellias to help us scale, and soon we had a remote team of four engineers in Ukraine. Then the war in Ukraine began. I will never forget the stories the team shared about fleeing conflict and their incredible resolve under unimaginable stress. Kosta, Yurii, Vadym, and Oleh were not only great engineers but also incredibly resilient individuals. I'd like to write more about working with them in the future.
Managing a remote team in another country presented new challenges, including navigating cultural differences and building relationships without meeting in person. The real learning curve for me was managing a team where the engineers had a deeper knowledge of our tech stack than I did. Initially, I didn’t handle this well—I was too dictatorial in my approach. It took me a few weeks to realise that not only were the team’s suggestions better than some of mine, but also that I would have hated being managed by someone who lacked deep technical knowledge and wasn’t open to listening to my ideas.
I changed my approach. Instead of dictating ideas, I began running workshops where, as the manager, I set the objectives for the meeting. Rather than offering my own ideas, I facilitated group discussions, summarized actions, and then followed up to ensure our approach was implemented. This isn't to say I didn’t contribute to the solutions, but rather that it was about collaborating as a team and exploring ideas together, rather than me, as the manager, having all the answers. This shift allowed me to spend less time giving feedback on specific pieces of code and more time focusing on higher-level decisions. I spent my time enabling the team by spending more time in Jira/Confluence rather than giving feedback on merge requests. This coincided with working with an excellent consultancy company, and I began collaborating with a now mentor of mine, Darren West, who was a strong advocate for this approach. He instilled confidence in me by providing clear, early feedback on both what I was doing well and where I could improve.
The combination of adopting a servant leadership approach, having an excellent engineering team, and wider product/design support, made me feel like a real leader for the first time. I was no longer the anxious over-thinker I had been; I was developing my own management style, which is the foundation I use today.
I believe that empowering the team is significantly more effective than dictating its function. I plan to delve into this philosophy in more detail in the future.
Before I close out this chapter of my career, I’d be remiss if I didn’t mention the greatest squad name of all time from this time: Archie’s Fan Club. Archie is Kosta’s legendary dog, who kept him company during some of the most challenging times of the war. Archie is a hero to me and everyone who was part of our team.
Jump to heading 2023 - First time I felt comfortable as a manager
I was approached about a job opportunity that was too good to pass up, so I moved on to my first role at a large company, Hargreaves Lansdown, where I was tasked with leading the design system team. This was the first time I started a new role as a manager from day one, which was a significant milestone for me. Unlike previous experiences, I felt confident that I could be an effective manager.
I had learned a great deal from my previous role, which helped me integrate into an existing team as a manager. We had experienced several changes in engineering leadership and had engaged consultancy firms to assist with our progress. The most successful leaders I observed were those who focused on listening and asking questions. Shout out to Matthew Cohan, Mario DeCristofano, and Darren West, who exemplified this approach for me.
Instead of dictating from the start, I spent the first two weeks primarily listening and taking notes rather than making comments. I’m sure I made some suggestions, but my primary focus was on gathering information. I then shared my findings with the leadership group (product owner and delivery manager) as part of a high-level plan, which we began to implement. I ran several workshops to start to facilitate change, from documenting the state of complex components to visualizing technical debt, combined with regular one-on-ones to understand the engineers' biggest pain points.
What followed was a six-month period of significant change. As a team, we refined our processes, coding standards, and culture. While I might have initiated some conversations, especially early on, most changes occurred because someone on the team suggested them. For example, we had many discussions in PRs about the best way to consistently order our React components code. To reduce this back-and-forth, we updated ESLint to enforce our coding standards. My role was to facilitate the opportunity for everyone to have a voice, identify blockers, and work with the team to prioritize tasks according to our goals. My role was not to have all the answers or dictate every task.
We started with a good product and made it excellent. Everyone was committed to being part of the incremental improvements to our processes. This led to very positive outcomes. We led the company in DORA metrics. After I gave a brief presentation about our team, the new CEO provided feedback, stating that we were "one of the most mature engineering teams in the company," despite having been together for only six months.
As a manager, I believe I played a role in this success by driving standards and facilitating change. I received some great support from various people to make this happen, including excellent mentorship over the past twelve months. I approached Darren West at the end of 2023, and he has kindly been helping me improve as an engineering manager outside of my day job. I've participated in my companies internal mentoring program, and the wonderful Kate Spalding has generously given her time to listen to me and discuss life as a manager at HL, away from my day-to-day responsibilities. I've always had the support of my manager, Nick Laws, and we've faced several interesting challenges together over the past twelve months, with the many changes we've undergone.
Jump to heading Conclusion
This is my journey. I'm not claiming it was the right way or the same as everyone else in software engineering, but it’s likely similar to many others in engineering. It's common to "move up the ranks" as an individual contributing engineer. I've never heard of someone starting as a "junior manager." It's a role you're expected to be able to do, but how can you if you haven't had the chance or the training?
If I could start over, I would engage in more volunteering and coaching outside of my work role. The work I did at Codebar and mentoring bootcamp students provided valuable opportunities to learn away from the pressures of work. Having mentors myself has also been instrumental in my development. I believe there is a difference when you have a mentor who isn't your direct line manager—it provides space to work with someone who isn't involved in the day-to-day aspects of your job. I consider this self-development time crucial to my growth as a manager.
If you have any comments, feedback, or questions about this article please get in touch! I'd love to hear about your management journeys or, if you're looking to get into management, what your approach will be.
Finally, I'd like to dedicate this post to my Dad. I've been very fortunate to have my him as my long-suffering business coach/accountant advisor/mentor but to name a few of the roles he's helped me out with. He's someone who's handled huge management responsibilities, the likes of which I'll likely never take on. He always makes time to listen to my problems and offers ways to approach them. Moreover, he has always lived by his own values, and this, as with the best managers I've had, is the most powerful way to empower someone.
