My Path to Becoming an Engineering Manager at Gem

Two years ago, I decided to transition from a software engineer to an engineering manager — at the time, I’d been a senior individual contributor (IC) for over three years at both Gem and Uber. I know firsthand that being part of a team where you feel supported, belonging, and safe makes a world of a difference to your growth. I’ve been fortunate to have had a few managers in my career that have had a huge impact on me and my experience. These managers inspired me to learn first hand to build inclusive engineering teams where engineers felt like they could do their best work and grow in their careers.

Luckily at Gem, there isn’t one single track for engineering leadership. We understand that not all great engineers make good managers or even have an interest in being people managers. Gem provides engineers two paths for leadership: one that is more technical and another that focuses on people management. We value and respect our technical leaders that decide to remain technical and provide growth opportunities for them within that track. If I found that I didn’t like people management, I knew I could always go back to being an IC and still have a strategic impact on our engineering processes and product roadmap.

In this blog post I will go over the transition process of going from an IC to a manager at Gem and some resources that helped me along the way.

Decision Process

I had been thinking about leadership roles at Gem for six months before actually making the decision to pursue management. I knew I wanted to lead a team, but I hadn’t decided if I wanted to continue in a tech-lead role or to go down the people management route. The timeline included discussions with my manager revolving around my reasons for pursuing management. The ultimate reason to pursue a leadership role was to scale my impact and learn how to effectively lead a team. What drew me specifically to management was that I enjoy teaching. The role of a manager really aligned with that of a teacher when it comes to mentoring and coaching and the satisfaction you get by helping others achieve their goals.

I started with smaller mentorship experiences where I onboarded an engineer and was in charge of delegating that engineer’s projects, unblocking that engineer when they were stuck, and providing feedback. This experience was further evidence that this was the right path for me at this point in my career. It was a small step, but one that proved to me that I was ready for the road ahead.

Transition Process

We started to think through how we would split out the 12 person engineering organization into separate teams. I was first involved in establishing the scope, charter, mission and then the roadmap for my team. All this to say that my transition to management involved building out the team and its responsibilities which is a different experience than inheriting an existing team.

Once the team boundary was established, I expanded my mentorship and technical leadership scope. Throughout this phase, we did not announce that this was a management trial period. Not announcing this broadly made the transition feel more smooth and natural for both the engineers and myself. If we were to announce it, there would have been a lot more pressure. Instead, we communicated to the team that my role was that of a tech lead and a mentor rather than a manager. We communicated my responsibilities which included: establishing a roadmap, delegating tasks, ensuring task follow-through, and helping engineers de-risk their projects for four engineers. These people would soon officially join the newly formed team that I would be managing.

Throughout this process, I learned that it gives me meaning to help the engineers on my team grow by working on interesting projects that allow them to achieve their goals.

Success Metrics

In addition to a detailed process, the success criteria was clear as my manager had pointed out exactly what it would take to be a successful leader of the team. The criteria included:

• Do individual contributors (ICs) on the team feel like they have a clear understanding of what they should be working on each week?
• Do ICs feel like they’re working together towards a common goal?
• Do ICs feel like they’re working on projects aligned with their interests and growth?
• Do ICs feel like they’ve received feedback from Einas that has helped them grow?
• Do ICs feel recognized for good work?
• Is Einas finding opportunities to unblock or accelerate projects?
• Is Einas ensuring that key stakeholders are being kept informed of project progress and decisions?
• Is Einas working sustainably to maintain all of the above?

Over the next couple months, my manager would check-in with engineers to see how I was tracking against these metrics and would share course corrections. Once my manager and I felt comfortable with my progress, we communicated this transition to the engineers and gathered their input. No red flags? Good. My role was communicated out to the rest of the engineering team.

I should note that even though the success metrics were clearly laid out, my own feeling of productivity decreased as it was very hard to tell how I was doing. As an IC, it’s very easy to measure your success and productivity — you can point to what you implemented, code you wrote, products you’ve launched. As a manager, you ultimately spend most of your time working with people, listening, mentoring, coaching, and then executing. Your execution and measured progress comes through your team which takes more time than your own individual work. It took me a while to feel like I was being productive and doing a good job at being a manager. My own definition of what success was needed to change.

My own success criteria has evolved over the past couple years of being a manager. In addition to all the points listed above, I have added two more metrics to my measure my success:

• Am I effectively delegating and scaling myself?
• Is my team executing at the level that is expected of us?

Throughout the first year of my transition, I focussed more on the team, building trust, and establishing a healthy team culture. Today my main focus is on execution and scale.

Continuous Learning

After years of being an engineer, I was struck by how much there was to learn about management. As an engineer, I had started feeling very comfortable and suddenly I was in a position where I was way outside my comfort zone. Ultimately, that’s because engineering management is a completely different role with a whole new skill set to learn. In this section, I’ll go over some resources that helped me accelerate my growth and learning.

• The Manager’s Path was my first go to to help me understand what the role of a manager is. It’s useful for anyone that is also considering becoming a tech lead and debating whether or not management is right for them. Specifically, Camille’s lesson on keeping an eye out for opportunities for your team members to stretch themselves is one that I still lean on.
• My good friend gifted me a manager care package by Wherewithall that included a copy of Resilient Management. Lara Hogan provides practical advice and worksheets that were invaluable when it came to learning the ins and outs of management. One worksheet that I still use with every new hire is the questions for your first 1:1.
• I signed up for a few of Lara Hogan’s workshops through Wherewithall. I highly recommend the Mentoring, Coaching, and Sponsoring which helped me understand that you should be coaching 95% of the time where active listening and open questions come handy. The Influence without Authority workshops introduced me to the concept of understanding your team’s core needs with the handy BICEPS acronym to help!
• Through Gem’s annual Learning & Development budget, I signed up for a career coach through BestPracticer. BestPracticer matches you with a career coach from your field based on your career goals. Having a coach that’s been an engineering manager really helped me with the day to day challenges I was facing in my new role. We went over how to conduct effective 1:1s, how to give and receive feedback, hiring, and sourcing engineers. They have even given me feedback on a proposal for an engineering conference and how to introduce a promotion to fellow leads before we had established promotion cycles.
• I learned about the importance of playbacks and split tracks to help scope the conversation from LifeLabs Learning’s Coaching workshop. These could be questions like “It sounds like you said X, is that right?” and “I think I heard two things, X and Y. Which should we focus on first?” Their workshops provided excellent management training. Gem managers across functions are currently going through 6 management training courses that have been incredibly helpful.
• LeadDev has free blog posts and talks — all were incredibly helpful.

The learning never ends and Gem still continues to support my growth with management training and continued investment in management coaching.

Summary

It’s important that the transition is documented and detailed with expectations and success metrics. This not only helped me grow as a manager but helped my team be successful and healthy. It’s equally as important to provide your new managers with the training they need and the ramp up period required to set them and their new team up for success. Finally, it’s important to establish two career paths for engineers because not every engineer should and wants to be a manager.

Huge thank you and h/t to Mike Pinkowish for creating this transition plan for me and for showing me what good management looks like!

Please feel free to reach out to me if you have any questions about management, what books I’m reading today, or about engineering at Gem.

___________________________________________________________________

Are you interested in being a part of #LifeAtGem? Head to our careers site to learn more about our culture and what it’s like to work at Gem.