Finding your way from maker to manager

The transition from engineer to engineering manager can be a tough one. But become a manager of engineering managers and you’re even further from what attracted you to the job in the first place, and maybe even what you identify yourself as being best at.

My own time at Intercom can be described as a play in three acts – I joined as an engineer, moved over to engineering management and now I’m a manager of engineering managers. The third act is only really starting, and now’s a good time to reflect on the changes and nuances I’ve observed after transitioning between each role.

Act 1: Engineering

When you are a manager, it’s easy to look back at your time as an engineer with rose-tinted glasses. When I look back at my first year at Intercom it almost feels like I was free to do whatever I wanted – I spent my time building new things, fixing things that were broken, and contributing to a variety of activities across the engineering organization.

“Will the person I’m in the room with take me seriously as I pretend to sound like a manager?”

Other than a daily standup meeting, weekly 1:1 with my manager and a weekly planning session, my calendar was mostly clear. Of course, the nature of the work I was doing as an engineer was quite different to what I do as a manager, and the tasks definitely filled up my free time – hustling to drag weekly commitments over the line, painstaking and time-consuming analysis of outages, and doing technical research. They’re all activities that I don’t do very often these days and take a lot of time and effort to do properly.

A lot of the work that I was doing was easy to quantify. I’d close a few issues, complete (or occasionally miss) a weekly team goal, submit and review pull requests, modify a cloud scaling policy or two and do some hiring activities like interviewing or reviewing candidates. Satisfyingly the work being done here was largely tracked automatically, and it was easy to see what I’d been doing each week – not that the work itself was easy though!

Management doesn’t give you the same sense of immediate progress as shipping code does. Important things you do as a manager, such as 1:1s, writing roadmaps and making sure the team are working well, don’t tend to have as easily quantifiable outputs – at least not in the short-term.

Act 2: Managing engineers

My motivation to manage comes out of wanting to do more. Through managing a team of engineers, I can get more done in the way I want to get it done. I can help out more with growing people, and get more involved in wider activities such as recruiting and public speaking. So when an opportunity arose to move to manage a team in Intercom, I jumped at it.

“It didn’t take too long for me to hit calendar bankruptcy”

Once my job title changed to manager and the company directory got updated, I thought for a few minutes that I was actually now a manager. I dutifully updated my LinkedIn profile and admired my new position in the company directory. Being a manager is great!

It was only when I started doing basic management tasks – sending out invites to weekly 1:1s, planning what I was going to say at each 1:1 – that I found being on the other side of the conversation quite intimidating. I had experience mentoring and chatting to folks in 1:1s, so the experience wasn’t totally new to me. But nervous negative thoughts quickly started to creep in… what if I said the wrong thing? Will the person I’m in the room with take me seriously as I pretend to sound like a manager?

It doesn’t help that you’re often managing folks who were until recently your peers on a team. The nature of your relationship with your team, the people with whom you spend a huge amount of time with every week has rapidly changed, an obvious source of stress. Getting good at 1:1s takes not just practice and preparation, but also requires delivering a few terrible 1:1s. As you get more practice, 1:1s get easier and far less stressful and become an enjoyable part of the week (though there are occasionally tough conversations to be had too).

Over time, my calendar started to get very busy with invites to “Very Important Meetings.” I had to represent my team in some meetings and shielded engineers from being distracted by them. I needed to know the status of projects and things that were going on that could impact my team. I was now the natural location for escalations and pings about things my team were involved with.

It didn’t take too long for me to hit calendar bankruptcy. I wasn’t getting around to doing things that are important, and even just replying to simple emails seemed to get lost in the frenzy. It’s unfortunate that learning how to say no and when to delegate usually requires a complete meltdown of your schedule first.

Another important lesson I learned the hard way after transitioning to a management position is when to “managineer” – that is, figuring out what technical work to get involved in. The easy answer is to not do any technical work at all – managers should manage. This sets a clear demarcation between engineering and management, but it’s often not very practical, and it’s tough to move on entirely from technical work.

Engineers moving to management roles typically have significant technical depth in their field and a track record of getting work done. My experience as a manager is that taking ownership of weekly deliverables for the team almost never worked. Something urgent would come up and it was too easy to immediately consider the engineering work expendable. The tasks themselves also suffered from inevitable underestimation of the time it’d take to complete them. As a manager, these icebergs are all around you. It certainly didn’t help that my engineering skills were getting rusty, and my development environments needed to be cajoled back into life, lying relatively idle most of the time.

That said, there is some engineering work that can be worthwhile to take on as a manager. It’s usually non-critical but still important to the team – stuff like clearing out some technical debt or turning things off to make the team more productive. Taking on-call shifts only worked well out of office hours. In the office my team tended to have a reasonable amount of low priority tasks to attend to, and the on-call engineer would typically take these. These low priority tasks tended to get dropped in the same way that project work did. This didn’t set a great example to my team in how I expect them to act when on call, and resulted in on-call debt being built up.

Act 3: Managing managers

As Intercom has grown, we’ve built new teams dedicated to functions that didn’t have dedicated staff, but are critical to Intercom’s future success. Running Intercom’s infrastructure team, early last year I was well placed to build out two such teams – Security and IT. At the same time we backfilled the engineering manager role in the infrastructure team, and suddenly I was in a job that could be described as middle-management.

Lots of great advice has been written on how to transition from engineer to manager. But less has been written on how to manage managers. Some have come close, but none have hit the mark for me. Here’s a few things I’ve learned so far though.

Respect other managers’ boundaries

Part of the problem for me is still feeling attached to my original team. Figuring out how to engage with the team in a way that is valuable to them while not undermining or stepping on the toes of the team’s new manager has been tough. When I handed over management of the infrastructure team I told the new manager: “This is your team now. Organize it they way you want, and don’t follow what I did just because it was what I did.” He did this, which was great, however in day-to-day practice I was still getting involved in project planning, task breakdown, low-level implementation discussions and day to day operational events. I needed to be more deliberate about making room for growth and allowing him to truly make his mark on the team.

Distance can be a positive thing

One thing that has helped a lot is not showing up regularly at daily standup and planning meetings, which forces me to work with the team to understand when I should have input and when they want me to get involved. We’ve since established a solid working relationship when planning the team’s work – distance and formality have helped a lot here, though they both feel a bit unnatural when you are putting them in place.

So far my experience managing at Intercom has been really positive. The teams I’ve worked with have done some great work, and I’m very proud of what they’ve delivered and how they’ve gone about their work. Moving from engineering to managing and beyond involves a lot of pain and change, but it’s been really worthwhile. For me, talking through what’s happening with your reports, managers and a good peer network is the most important tool you can use to survive the transitions.