Reflections (2022) - Becoming Head of Engineering

My year started off by getting promoted to the Head of Engineering of a small subsidiary company. To be honest, when I was first offered the opportunity, I had a lot of hesitation. At 25, I had never imagined that I would get such a position so early on in my career. Although I had led a few teams leading up to this, I still had a lot of doubt if I was ready. I always kept coming back to thinking of how many more years of experience many of my team members had over me that surely, I wasn't qualified to lead them let alone be responsible for an entire department. Surely, I just wasn't ready. A whole year has passed since then and I finally feel like I have settled into the role. Things are still hectic and I'm constantly playing catch-up but we're moving forward. My department consists of 4–5 small teams that have responsibilities ranging from developing web applications to data pipeline to machine learning. We're even developing on Nvidia Jetson devices! I think my initial concern in taking up this position was the daunting prospect of having to be an expert in all these fields but that wasn't the case. Whilst I did indeed need to have some level of knowledge of everything, I've come to understand my roles as 3 main sub-roles:

• Director
• Manager
• Developer

Director

The director role is probably what most people expect. I had the responsibility to align our vision with the business teams and make sure that all our components are built to work together to fulfill this vision. I would have regular meetings with the CEO and PdMs to discuss what direction we want to head in and draw out a roadmap of all the features that we would have to develop. When it comes down to development, I would have a general idea of how all the different components should interact with each other, but the majority can be handed off to the many great teammates that I could rely on. My job was to be able to steer everything in the right direction, be on the lookout for potential issues (including security & protecting user privacy) and make sure the team had what they needed to complete the task. My role isn't about control, it's enabling my team to take ownership and to take action if anything comes up.

Manager

The manager role is something that I had a lot of trepidation about. I think all my managers in the past would agree that I can be difficult to work with at times for better or worse. If I found something unsatisfactory, I would be very straight about it. I would question everything from my team to what my manager's role is and even how the CEO is handling a particular situation. If I felt like my manager was giving me non-answers, I would keep prying. To be clear, I don't do this just for the sake of being difficult, but it frustrated me to feel like the core problems weren't being addressed. Of course, simply complaining wasn't going to do anything so I always tried to have some other proposal. It was very amusing when my last manager called me his canary in the coal mine which I took as a compliment.

One of my biggest gripes with my previous managers was that I never really felt like any of them really understood the work I was doing or the full impact I had on the team. A lot of this was likely due to my managers simply not having the expertise in the work I was doing but another large factor was that they just weren't spending enough time with the team. Even if they were doing regular 1on1s with every member, I don't believe that that's enough to understand how each member communicates within the team, who has been stepping up to facilitate meetings, and even how the team is gelling together. If I made a very versatile UI component that took advantage of the natural DOM flow, I want my manager to appreciate the underlying knowledge that was required to make such a component; not just as that one component on that one page.

Now finding myself on the other side of the table, I wanted to be the manager that I always wanted. I want to make sure I don't fall into the same hole and really understand the work my team is doing. More importantly, I want them to feel like I know what they are working on. I am actively participating in as many team meetings that I can. I am reviewing their code. I am checking in on the side to make sure everyone can do their work with confidence. This all becomes incredibly important when it comes to performance evaluations. Regardless of if the result was good or bad, if I can make each member feel like their work was evaluated fairly, it becomes so much easier to then plan their next goals and create an environment where everyone is welcome to feedback.

One last thing I make sure I do is to leave a paper trail of everything, especially around evaluations. This is just generally a good thing for anything you do, and it can avoid horror scenarios where evaluations suddenly change after being disclosed (which has unfortunately happened to me in the past).

Developer

The final major role I have is that of a developer just like anyone on my team. I use the term developer as an all-encompassing term that includes everything from breaking down the requirements, designing the system, implementing the feature, testing and finally release. A large portion of my time is spent code reviewing for all the various components across multiple teams and it really does feel like a never-ending road to catch up to everything. While my focus was on one component, all the others are still moving forwards so when I switch to another component, I would need to go through all the changes that have been merged. Although the times I get to write is usually to fill any holes that our team isn't able to cover or to help complete a feature for a deadline, I would say my greatest contribution would mentoring the more junior members.

I've seen many approaches to mentoring, some many magnitudes more effective than others. Having done some tutoring and receiving mentorship in the past, I've developed my style of mentoring. Although I will alter things slightly depending on what works well for the person you're mentoring, this is the general flow I go with:

1. Give the engineer full ownership of a task
2. Get them to break down the issue and research multiple potential solutions
3. Have them present their findings to the rest of the team and begin a discussion
4. Break the solution into smaller pieces and execute the plan with the team

Between each step, I would take some time to sit down with them to go through their thinking. If there are areas that they may have overlooked, prod them in the direction by asking questions and give them time to think. After a few times of this and they still have a few issues, I would propose my solution and explain how it works and any drawbacks it may have. Encourage them to ask any questions and even disagree with you. I never want them to take my word without understanding the reasoning behind it. Once they get into the implementation phase, it's more or less the same. In code reviews, rather than giving them the solution straight away, I would ask them questions on why they decided to code things a particular way, did they think about this other approach, etc.

Final thoughts

Over the past year, I have gained a lot of confidence and I think I have proved that I am capable of my new position. Whilst there is always room for improvement, I am very happy with what my team and I managed to achieve. There is so much more I could dive into for each of the topics I've mentioned above as well as others such as my thoughts on team dynamics, role assignments, etc. Maybe I'll start to write more of these posts throughout the year but for now, I'll leave it here. 2022 has been a very significant year for me not only for my career but all aspects of my life and I hope to keep riding this wave into next year.