Howdy! My name’s Jon, and I work as an engineering manager in the Operations Collective.
I joined Monzo 3 years ago as an Android engineer, but last year I made the switch into engineering management full time. It’s been an interesting journey with lots of lessons learned. In almost every chat with an engineer since, I’ve been asked: “What’s it like? What exactly does an engineering manager do?” so I want to answer those questions for anyone thinking about engineering management in their future.
Journey at Monzo
Before joining Monzo I’d been an Android engineer for 7 years at a mix of different companies, varying from product-focussed companies like Skyscanner to contracting at legacy banks.
I’d been an early user of Monzo and distinctly remember the first time someone introduced me to the hot coral card at a cosy pub in Edinburgh. Fast forward a few years and I joined Monzo in 2019 as an Android engineer and got started in the Growth & Core Collective building golden ticket referrals.
Not long after, I moved to the Operations Collective where I became a tech lead of a squad and got promoted to Senior Android Engineer.
As a tech lead I had one-to-one meetings with engineers in the squad where we discussed engineering challenges and areas they were keen to grow technically. During the pandemic Monzo had to make the difficult choice to make some staff redundant. My role morphed to offering direct support, helping people to talk through how they were feeling and being another voice of support.
This was my first real experience of offering the kind of support that an engineering manager gives, and while difficult, it was important work that felt meaningful to me.
After some reflection (prompted by my own manager), I decided to dig a bit deeper into engineering management and try to answer the question what exactly does an engineering manager do?
I’d been doing Android development for almost 10 years. It’s something that continued to interest me, and was always changing (since I moved away from engineering, Android adopted an entirely new way of building UIs - compose). However, as a tech lead I’d had a chance to experience some of what an engineering manager is responsible for, and I loved it. In particular I enjoyed focussing on technical delivery through improving squad processes and helping engineers in the squad grow.
At this point in my career I wanted to focus on my progression, particularly ramping up my speed of learning.
From my perspective, I had 3 options in front of me:
Keep growing as a mobile engineer and progress down the individual contributor track (staff engineer)
Switch to backend engineering (a completely new technical challenge)
Become an engineering manager (switch to a new career track)
I chose engineering management as I optimised for what would give me the most learning, and what I enjoyed the most.
This was also a fantastic opportunity. I’d get to learn how to be a good engineering manager without the added pressure of building domain context on an area I was unfamiliar with. Monzo also has an amazing engineering leadership team, and getting the chance to up-skill from them was an opportunity I couldn’t pass up.
What do Engineering Managers at Monzo do?
Engineering management at Monzo has changed over time. It started out as a role defined by supporting our world class engineers, and shifted to providing both excellent support and technical leadership for teams.
Monzo has an engineering manager progression framework that outlines the expectations of the role, which are broken down into 3 themes:
Team and execution
This might be things like course-correcting a project that’s going off track, unblocking a project by communicating with stakeholders, building out a roadmap with a product manager, contributing to hiring, coaching engineers, preparing for performance conversations, ensuring a squad is appropriately staffed, and more.
Some of the work that an engineering manager does is invisible. This means the work isn’t shared as widely and publicly in the same way you’d share the impact of shipping a new feature.
To find out more, I spoke to a number of engineering managers, engineering directors, and some staff engineers that had previously managed. This helped to fill in the blanks of what the role entailed day to day.
The transition: Too many hats 🎩
Before making the switch I worked out a trial period with my manager.
I would take on 2 reports for at least 3 months (to give some individuals some stability), with an ‘escape hatch’ at the 3 month mark. The escape hatch was a check in point where I could return back to my previous role as an individual contributor.
An important step in this journey was to build a support network that could help answer some of my early questions on being a manager. As part of this I moved manager to someone that had direct experience of supporting new engineering managers, and was best able to set me up for success. I also setup recurring 1:1s with another engineering manager to get some direct support from a peer.
I also read, a lot. This isn’t required though, and some of it won’t make sense until you experience it first hand. Some resources I found useful:
Even with the support network in place, and the escape hatch, the transition was daunting and I made a bunch of mistakes.
To give stability to the squad I worked in, I remained as an Android engineer and the tech-lead, whilst also taking on management responsibility for two of the engineers. This was too many hats and I found myself actively switching between hats during discussions.
I’d dialled up the learning, which was exactly what I wanted, but I’d also taken on some stress too. To help alleviate this, I delegated some of my tech-lead responsibilities and agreed with the squad to contribute less code than normal.
I also found that my relationships with my peers changed. Engineers that I managed that I worked with previously no longer felt comfortable challenging my suggestions, and this meant I had to change how I communicated.
Communicating as a leader was a new challenge. There is lots written about finding your leadership style, but an important lesson I learned was to be more thoughtful in how I communicated. There was an implicit weight to what I communicated as an engineering manager, and I had to learn to factor that in. An example - as an engineer it can feel very different to be asked to contribute to an incident by your manager vs another engineer.
At the end of the escape hatch, I’d decided that I wanted to go all-in and commit to becoming an engineering manager full time.
The transition to full time engineering manager wasn’t immediate, I also ramped up slowly, taking on engineers over a few months.
Life after coding - one year on
I’ve now been an engineering manager for a year and still really enjoy it. Like everything it’s a rollercoaster, but my rate of learning has exploded which is exactly what I wanted 🚀
coaching an engineer through a problem for the first time
running a new squad kick off with good outcomes
receiving feedback from an engineer that they felt safe to share in our 1:1s (psychological safety)
helping out with mobile hiring - improving the interview process and seeing new hires go through the pipeline was incredibly rewarding
I also crowd sourced some questions from engineers interested in hearing about the transition from individual contributor to engineering management.
Do you miss coding?
Yes. The immediate feedback loop of writing code is addictive. As an engineering manager, making improvements to a team or a way of working has a much longer feedback loop, and isn’t always directly attributable to your contributions. This can be a really hard adjustment and you have to find other ways to get the feedback on how you’re performing.
However, a core part of being of an engineering manager is problem solving. It just doesn’t involve writing code.
What's it like changing from technical problems to people problems? Particularly interested in hearing how you have to account for emotions in problem solving
There is overlap between technical and people problems, the higher level skill of problem solving applies to both.
In my opinion the main difference between the two is that a technical problem generally has a ‘right answer’ - a way to solve a problem that will execute within set bounds.
People problems have lots of nuance. What works for one individual might not work for another. Add in the fact that you’re dealing with humans, not machines, what works for an individual one day may not work on another.
Something I struggled with was turning off work brain at the end of the day. As an engineer there are certain technical problems that sit with you, the kind you’ll find yourself thinking about in the shower on the weekend. As a manager, I’ve found it difficult to disconnect from people problems outside of work.
Helping people through problems in their life outside of work can take an emotional toll that leaks beyond the ‘9-5’. In situations like this I found it’s helpful to lean on your own support network and remember that you can’t solve every problem, sometimes listening is the best thing you can do.
It’s important to call out that while people problems are something you have to solve as an engineering manager, the role is not exclusively solving people problems.
Did you find it hard to keep yourself out of the technical details? Was it hard to let go?
Yes, especially starting out. Switching from the default of providing solutions to problems, to leaning on individuals to solve problems was tricky. I found it’s important to have trust in individuals, and ensure they have a support network that can help with technical problems. This might mean facilitating things like reviews on technical proposals, or bringing in a domain expert on a particular problem for context.
How is it having meetings all day?
Moving to manager time can be hard (interrupt driven). I was given great advice early on to ‘manage your energy levels’, but I didn’t understand the value of this until I experienced some of the pain.
Whilst it’s natural that on manager time you’ll have lots of meetings, certain meetings can give you energy, and others can drain energy. Understanding what meetings give or take from your energy levels can help you build a more balanced day.
You also have a lot more control over your time than you’d think. It's a common trap to find your calendar starts managing you, rather than the other way around. In reality, you have the flexibility to re-arrange meetings, or decline meetings that you don’t think you add value to.
Periodically running a calendar defrag can really help maintain a balanced week and ensure you’re spending your time in the most impactful ways.
What advice would you give to others who are considering the Engineering Manager path?
Be kind to yourself. This is not a promotion, it’s a sideways move into a new career. There will be lots of new. You can lean on your experience as an engineer, but you also need to build new skills.
Manage your time. Making the adjustment to being interrupt driven is hard. You’ll need to get more comfortable with not reaching the end of your todo list in a week. Sometimes doing nothing is the right answer.
Set realistic expectations. I’d expected that I’d be able to manage engineering management while still contributing as an engineer ‘on the side’. This was not a realistic expectation, I could make time to do this week to week but it wouldn’t be the best use of my time. If you aren’t comfortable letting go of writing code (during working hours) then you may struggle.
Switching from the individual contributor track to the management track might seem like a small hop, and in some ways it is. But in reality it’s changing your career, and changing career is hard.
Starting from the beginning of a new career track is equal parts daunting and exciting. I’d encourage anyone curious about making the transition from engineer to engineering manager to put in a 1:1 with an engineering manager and ask them about their day - what are they working on right now, what’s the biggest challenge they’re facing?
That’s all folks, if you have any questions please either comment in the forum post or drop me a message on Twitter.
P.S we’re hiring!