A couple of months ago I moved from a senior engineer position to being an engineering manager on a medium sized team. I’ve found this role change come with a steep learning curve: many things that mattered when I was an individual contributor – like writing good code and teaching others engineering best practices – suddenly became less important. Other things that I paid less attention to the past – like time management strategies and learning about my new role – became things I need to focus on much more. In this post I’m summarizing what worked well for me during the early phase of this transition.

Mentors matter – especially within the company

When I started my first job I was convinced I had software engineering figured out. This was due having finished my masters in the upper half of the class and having built a few small and moderately successful projects on the side. Turns out, despite these I was as junior as any fresh grad when it came to engineering in the real world. It would take me years of hard work to get from this junior level to something more senior. Looking back, it is also clear how mentors helped me grow much faster professionally – most of whom I’ve met by chance on the way.

Now that I was starting on a new position, I wasn’t kidding myself that just because I have some tech lead experience, read some books on management and know how to code, I have any of engineering management figured out. What I did know from experience though is that mentors do make a big difference. I wanted to make sure mentoring won’t happen by accident.

This was the first time I was looking in a targeted way for a mentor. As engineering management expectations can be different from company to company and I work at a larger one, I was keen to find a mentor within the company to start with. However, I didn’t have a clear idea on how exactly this works. I asked for help from my management chain, who in return connected me with people I both look up to and can learn tons from – as well as had the bandwidth to take on another mentee.

So far having a mentor – and one who is inside the company, but outside my management chain – has felt very helpful. Because my mentor is further away from what I do, it feels I get independent advice, from a birds eye view. However, given my mentor is within the company, they also give me a lot of insight and ideas that are specific to the environment I’m working in. It’s hard to see the effect of mentorship the short term, but it already gives me additional confidence to have someone I trust provide me with regular and candid feedback.

Understand the most important priorities of your new role

I had a solid understanding of my previous individual contributor role. But what really is an engineering manager? Are they a tech lead who also do 1:1s and performance reviews? Are they expected to coach and / or mentor team members? Should they still code? Are they responsible for only the team executing well, or also in setting the direction or strategy? These were just a few questions I had.

I thought plenty of these as well as talked with my manager, mentor and other managers about how they see their role. I don’t think there are universal answers and the expectations will also vary from company to company. However, the one company agonistic priority I’ve learned – that will is different to that of when I was in an individual competitor – is this:

As an engineering manager, you’ll need to put company first, team second and your team members third.

And I would also add: yourself as fourth. As an individual contributor I was used to this being the other way around: I would do my job first, then help my teammates whenever I could. Only after getting these out of the way would I look for doing things that would further help the team. I didn’t have to think too much of what’s good for the company – I usually assumed that whatever I’m doing is what the business needs.

As an engineering manager if I mix up the order I could easily find myself with an amazing team building something that doesn’t move the needle any way. Or worse, with a group of empowered individuals each going off their own way, and not producing much valuable as a whole.

Decide on a time and task management strategy

Early on in my transition, I asked another manager what practical advice they would have to start doing day one. They told me something practical indeed:

Figure out your time management strategy.

Up to that point, I hadn’t thought much of this. As an individual contributor, I wouldn’t worry too much about time management: I would say no to some meetings I didn’t have to go to and try to be on the maker schedule most of the time. I also did not have too many meetings.

However, as a manager, I do have far more meetings than before. Also, I am the one actually scheduling many of these meetings – the most important ones being the 1:1s, team meetings and catching up with key stakeholders. I do want to make conscious decisions on structuring these and when to leave time for uninterrupted chunks. And of course, I also want to take into account how much these meetings disrupt my team’s time and make sure to minimize that.

Same goes for task management. As an engineer, I was able to do almost all of my tasks any given week. As a manager, I have far more things to pay attention to: both things I need to do, and more frequently things that others need to do or need input from me. Keeping all of this in my head doesn’t work well for me – so I’ve started to write things down.

I’m still experimenting on what setup works best for time and task management. I do, however, consider my and other’s scheduling preferences more consciously for meetings. For tasks, I’ve started to experiment with simple GTD strategies that already work better than my original ad hoc approach did.

Set short term goals

One of my roles as engineering manager is to help engineers set goals that grow them professionally. So I took a good deal of time understanding priorities and goals of people on my team.

I did this first by asking people to do a self-assessment of where they are compared to the next level in the corporate career leader. Internally we have well defined job levels and expectations that made this easier to do. I also talked with people about where they would like to grow, things they like and dislike doing at work and in where see themselves on the longer term, beyond their current role or company.

Over a few 1:1s I got a sense of their short and long term ambitions and then asked them to put some goals in place. We then talked through these. An important thing I told people is how they themselves own their career progression – they should be coming up with the goals as well as executing on it. As a manager, my role is to help and support with this process – but they will own driving it.

I went through this process with everyone on my team. The only person I forgot to do it – ironic enough – was myself. It took my manager to remind me that I also should come up with short and longer term goals.

So I put a my of goals together and worked with my manager and mentor to refine these, prioritize them and cut them down to something that’s more achievable. Having these goals written down and going through them regularly help me focused on doing the important things and deprioritizing things that are not on the top of my list.

Finally – take time to read, experiment, learn and reflect

One piece of advice that stuck with me was from the 90 day plan article on FirstRound. It’s this:

If you’ve decided to transition from engineer to technical manager, your first month is about committing to own your education.

I’d argue replacing “first month” with “first year and beyond”. Going back to the analogy with how I started software engineering: I just kept learning wherever I could – from others code, from books, via conferences and so on – and I kept getting better over time. Similarly now I’ve asked for book recommendations and started to read some of them, signed up for The Lead Developer Conference and decided to reflect on my experiences on various places like this blog.

I will close with this: learning is only one part of the advice. The other part is experimenting with things that make sense in the given situation and later reflecting on what worked and what did not. So far, transitioning to the engineering manager track has been a really humbling, interesting and exciting journey. Looking forward to learning more and sharing these learnings along the way.

(Sidenote: I was inspired to write this post after how my manager, Charles shared his learnings from six months as a first-time engineering manager a few years back. If you enjoyed this article, I suggest you read that one as well.)