Five things I've learned transitioning from engineer to engineering manager

Five things I've learned transitioning from engineer to engineering manager

Over half a year 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. Below are the five important things I found worked well for me during the early phase of this transition.

1. Mentors matter - especially within the company

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.

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 to provide me with regular and candid feedback.

2. 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 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 a servant leader. As an engineering manager if I mix up the order I could easily find myself with an amazing and high performing team building something that doesn't move the needle for the business. Or worse, with a group of empowered individuals each going off their own way, and not producing much valuable as a whole.

3. Decide on a time and task management strategy

As a manager, I 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.

4. 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.

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 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 helps me focused on doing the important things and deprioritizing things that are not on the top of my list.

5. 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 relevant conferences and decided to reflect on my experiences as I go.

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. Also, you can read a slightly longer version of the above article on my blog.


Robert Avery

Programme Manager

7 年

Like this one!

回复
Helbert Maich

Sr. Software Development Manager at Amazon Web Services | Bedrock

7 年

Very nice article Gergely Orosz. And btw, can you get me one of those t-shirts? LOL All the best luck on your new journey !

回复

要查看或添加评论,请登录

Gergely Orosz的更多文章

社区洞察

其他会员也浏览了