The different stages of an engineering management career (to date!)

I’ve recently had conversations with some engineers who want to know more about what my day-to-day looks like, and what my path has been to get here. I thought I’d write a post in case it’s useful to others.

If you want to get a good general understanding of what different roles entail at different levels (outside of my individual journey, which isn’t necessarily typical!) the best book I’ve read is the classic ‘The Manager’s Path’, by Camille Fournier. This takes you through some fairly standard industry archetypes, including those for people who enjoy being hands on, or focusing more on people. I found this really useful in helping to give myself an understanding of the attributes of roles that I was most interested in. If you want another personal story, Lara Hogan’s Work at Different Manager Levels is also a great read.

Roles vary in different situations

Despite there being some commonalities enough for books to be written on the subject there’s also a lot of variety! When you’re planning out your future path, try to keep in mind that that:

1. Different companies do things differently, and in particular different titles mean different things in different places. CTO at a small agency is very different to CTO at a global tech company.
2. Jobs sometimes evolve over time as the industry, trends, and expectations shift.

Your journey may not be as linear as you plan

Depending on where you’d like to get to, progression through different stages can take a whole career. Be patient. Some people may jump from having a couple of years of development experience into a very senior role, but that’s certainly not the norm (and can be due to over-inflated job titles rather than the work itself).

Another factor to consider - rather than these being distinct roles that you deliberately move between as and when you’d like to progress, if you’re working at a hyper growth company you may find that you start out with quite a shallow structure which then needs to rapidly change as your team grows. As such, you may find yourself at a different level of expectation in accordance with what the company needs, not necessarily at the point when you’re feeling confident to make a leap!

You should also be mindful that your own likes and dislikes may change - you may set out determined to be a CTO at the start of your career, but end up as a VP of Product instead. That’s ok, you’re allowed to evolve.

And finally, the most important caveat. You don’t have to want to change your role or become more “senior”. Some people will get to the point of being an extremely competent individual contributor developer, and not want to increase their scope or take on leadership responsibilities. That’s ok. Only you can truly know what path you’d like to take… although please do humour your manager trying to play devil’s advocate and challenging you on occasion 😉

My story so far

Caveats declared and scene set, here’s a run through of where I started out, right up to what I’m responsible for at the moment.

Background

👩🏻‍💻 I studied an “internet computing” course at university, before joining a web agency on my ‘sandwich course’ year in industry, then dropped out to continue working whilst finishing off a degree with the Open University.

👩🏻‍💻 I started off focusing on the back-end, but became a generalist, doing back-end, a little bit of ActionScript, and then more front-end once the agency started doing less Flash work. I really fell in love with the web once HTML5, and practices like responsive design started gathering pace.

Starting out in management

I’d been Head Developer and in solutions architect roles. I was comfortable leading projects, choosing technology solutions and approaches, and knew how to ask the right questions at the start of projects. Then, like many people, I started managing when the person managing the engineers left and the company didn’t want to hire externally.

Management wasn’t my sole focus, and I was still working on projects in different capacities. My advice to myself with hindsight would have been to find a mentor, learn the craft, and build up my ‘toolkit’ and experiences rather than management being a bolted on responsibility. At the time, despite building my experience I didn’t identify as a manager very much, and I certainly didn’t have a good view of my future or possible opportunities in that realm.

Mentoring and coaching

After leaving the world of employment and setting out on my own I ran a consultancy business for quite a while, and wasn’t managing engineers. I was however building up my mentoring and coaching experience.

My top tip here is to spend some time really understanding the differences between these different kind of modes; when they’re best suited, and when they’re not. At the point when I decided to come back to employment I was very insecure about my ability to manage people, but again with hindsight I feel like the experiences I had during this period really stood me in good stead. One of my core strengths is the ability to bring people together and build positive culture and safety within teams, and I think this originated in having to drop into quite a lot of unknown (and sometimes quite hostile!) teams myself to help others.

Rejoining the management world

Heading back into more typical management, this time the focus was entirely on people rather than having any hands-on responsibilities. My focus was initially on the performance, wellbeing, progression, and growth of everyone I managed.

At this point I had the experience of learning to manage at scale - at its peak I managed 17 people directly! This is not something to aspire to, it’s extremely hard to do well, but it helped me learn strategies that I wouldn’t have experienced otherwise. Building up your core skills around prioritisation, time management, as well as learning to identify the difference between putting out fires or investing in fixing root causes are all skills that will serve you well later on.

At this point it’s also good to try to experience a range of different situations, working with a variety of good and bad performance, and working with engineers of assorted seniority (including higher than you ever went, ideally). You’ll likely learn to adapt practices like 1:1s to find your own approach (and one that suits your people), as well as starting to define what your own management philosophy is.

At this point I was also running initiatives for the engineering management discipline, things like bringing in lightning talks, running workshops to look at improvements to on boarding, etc.

My people were initially mostly web folk, and they were spread across the business. The company’s approach to management was originally that the manager be paired with the person wherever they worked around the company…. but that didn’t scale. At all. After we introduced new vertical segments of the company I very rapidly found myself across three incredibly different areas of the business. This in itself was a good learning curve; learning to be able to say what I needed to do to be successful in my role (although it’s important to note that it’s often much, much harder for non-men and people who are under-represented to do this, and it very much depends on your company culture).

Since I went through this level of management we’ve evolved the expectation that we have of engineering managers, and now align people with teams rather than being “purely” focused on people. Our experiences resonated strongly with this article by Jeremiah Lee about “Spotify’s failed squad goals”.

Widening responsibilities

As I became more senior in the management team, some of my responsibilities were formalised. This included things like becoming ‘discipline lead for web’ (rather than just happening to manage a lot of web engineers). As part of this I’d do work including running the discipline’s hiring processes and finalise offer levels, do headcount planning for the discipline across the business, make proposals to create new teams (Web Platform and Web Consultancy). I was also involved in some more engineering-wide projects, such as starting to make some improvements around the fringes of our engineering progression framework (before we eventually rebooted and I eventually led this through to completion earlier this year).

As our number of engineers (and therefore managers) grew, I then started to manage other managers in my area of the business. This is a very different skill to managing individual contributors, and when you first start to do it you may find yourself revisiting some of the basics, down to “what does a 1:1 look like with a manager vs an engineer?”.

Director-level

And so to present day! Since last year I’ve been responsible for engineering within one of our ‘Collectives’ (vertical segment of the company). My Collective is Operations, which covers all of our customer support systems, and other absolutely fascinating domains like fighting financial crime. In total there are around 40 engineers that I’m responsible for, and we currently have 6 different multi-disciplinary squads.

The Collective is the group of people that I spend most time with, and I’ve had to invest in building up a strong relationship in particular with the Senior Staff Engineer and Director of Product. At this point you can’t just move squads if you’re not gelling - there’s so few of these roles across the company that you can’t pick and choose! Learning to work with whoever you’re paired with (whatever their default style) is extremely important to being effective as an org.

In terms of line management, I now…

👥 Manage either directly or indirectly 4 engineering managers (I’m a manager of managers who manage managers who manage engineers…)

👥 I also still manage some individuals including at staff engineer level. This is for strategic reasons, and these folk are key individuals who have a connection to the web discipline.

My day to day is hugely different from the days I had earlier on in this point. In any given week I may be working on things like:

📆 Lots of meetings! Leadership councils, risk councils, sync meetings with engineering and product managers, as well as product/architecture reviews and more.

📄 Feeding into board papers, content for the regulator, and other people ‘above’.

🔮 Setting engineering strategy and vision.

🖥 Making decisions on technology that impact our strategy

📊 Responsibility for setting KRIs (key risk indicators) and working with the engineers to get tracking capabilities implemented, plus accountability to make sure we’re headed in the right direction!

📈Looking at ‘Collective level’ or business level improvements.

🔢 Future quarter/year headcount planning for engineering, working with overall business budget plans, plus the other Collectives to make better decisions and tradeoffs.

👯‍♂️ Coordination of the staffing of teams, working with the Product Director to put together the right squads and people for the problem spaces and priorities (and changing these when necessary)

🦸🏻‍♀️ I rely on my team to handle many day-to-day pieces of work. I’m a point of escalation and decision making, but am a huge bottleneck if I was needed to solve every problem directly!

📣 I spend a lot of time doing information gathering and sharing, working out comms plans for wider company communications (for example furlough applications and decisions across our teams)

💪 Trying to strengthen the culture of a whole area of engineering (doesn’t happen overnight!), gain trust and respect, and make sure the engineers know I’m ultimately working to make their lives better.

This level can be lonely, and I’ve had to be mindful of where I get support, as I wrote about in a previous post. Some of the things you’ll be working on are hard problems, but it won’t be the right time yet to share them with your wider team.

One of the other biggest challenges at this level is that the wider business can make changes that affect your area (things like salary changes, promotions processes, or working policies), and the people in your management tree may not be happy. They’ll let you know! These factors can be outside of your control, but can throw your area off-track and out of the harmonious balance you’ve worked so hard to get. What’s worse is that you as an individual may have your own views; you won’t necessarily always agree with every big decision. It’s at these points where you need to be very mindful that you’re a leader, and how you lead at these points can make a big difference.

Everyone’s journey is slightly different

I really enjoy hearing about the different paths that people have taken, and hearing the stories of others has helped me work out what possibilities I have. I hope that this post in turn can help some more people find the right path for them!