In 2017, I became an engineering manager at Gusto. One year and many learnings later, I left the role.

To many, career growth in software engineering = becoming a manager. This idea is in part what drove me to take on a management role. I wanted to share my story, in case it’s helpful to others.

This post is about:

• My journey into engineering management (and back).
• Lessons I learned along the way.
• Takeaways for the reader contemplating their own career path.

Illustration by Camellia Neri

I grew up in Israel and, after completing my Master’s in Computer Science, moved to San Francisco to work for Gusto. I joined the Benefits Engineering team to build software that helps small businesses offer health benefits to their employees.

The team was great, and I was constantly learning new things. I was engaged and growing in my role.

But then, something happened that I hadn’t anticipated.

Lesson #1: If you’re interested in a career transition, tell people about it!

About a year into my role, my manager transitioned to another engineering team. This was a side-effect of a fast growing company, with engineers moving around to fill necessary roles.

His transition caught me off guard, but then I realized that I could be the one to replace him. I was familiar with the team dynamics, the benefits domain, and our product and design partners, and felt that I could guide them toward our goals. However, I was not even considered for the role.

I felt pretty frustrated and annoyed. But after talking to my team, I realized why it happened. No one at Gusto (including myself!), knew that I was interested in leading a team. So naturally, when that role opened and needed to be filled quickly, my name didn’t come up.

If you’re interested in a career transition, tell people about it!

Who should you tell? Well—first and foremost your manager, but also their manager, your peers, and other leaders at the company. You can start the conversation by saying, “I’m interested in a transition to role X, because of Y. Do you have any advice for me?”

I’m not saying you should email the whole company about it, but spreading the word has two big upsides:

1. Your manager and peers start evaluating you for that role and can give you concrete feedback that will help you reach your goal.
2. Transitioning takes time, and when those opportunities come around, decisions need to be made quickly. The names considered are usually those who spoke up and expressed interest in the past.

Make sure the right people know that you’re interested.

Coming out of this experience, I started telling people that I was interested in leading a team at Gusto. I didn’t express this as an immediate hard requirement (“I want to manage a team ASAP or I’m leaving”), but instead I brought it up in 1:1 conversations, and asked for advice about the skills I should develop to help me get ready for that kind of role. This made it easier to talk about what I wanted without feeling like I was demanding something I couldn’t achieve right away.

Soon after, another opportunity came along. A few existing leaders of another team were transitioning, and we needed to bring in other folks to take their place. Coincidentally, I had connected with the head of the team some weeks before this. We were both visiting the Denver office at the same time and had an informal 1:1. I brought up my goal (remember lesson #1?), so he knew that I was interested in leading a team. When the shuffle happened, he reached out to me and asked if I wanted the opportunity. I said yes.

Remember when I said management decisions need to be made quickly? This was one of those moments. When a manager leaves a team, people can feel jarred and uncertain. Leadership then has to move forward quickly to mitigate these effects. Opportunities like this come up often, especially in fast-growing companies.

Lesson #2: Get to know yourself

Soon I had jumped into a new team, a new domain, and a new set of challenges. I had a lot to learn, so I looked for inspiration from role models I had admired in the past, like my former manager.

I wanted to be just like them. To me this meant:

• Being able to unblock my team on any project, which also meant knowing the code better than anyone else.
• Taking on the grunt work so my team could do the interesting things.
• Helping the team figure out how to become better engineers and better teammates.
• Being the external communicator on behalf of my team: coordinating with product, design, compliance, support, sales, technical writers, and other engineering teams.

To make things more complicated, I had to switch domains—I’d moved from Benefits Engineering to Payroll Engineering—which meant I was starting from scratch. I didn’t know the code and the domain, I didn’t know the stakeholders, and I didn’t know the team, my team.

My first few months felt daunting. I tried to learn as much as I could while “faking it till I make it.” I was extremely fortunate to have a manager that coached and encouraged me when I was suffering from imposter syndrome.

Being a manager gave me a glimpse into “the other side.” I discovered that it involves a lot of behind-the-scenes work: preparing for one-on-ones, being involved day-to-day in what your team members are working on, finding opportunities to give them feedback, and being very thoughtful about how you deliver that feedback. Phew.

How on earth did my role models manage to do it all?! A colleague of mine, Kelly Sutton, analyzed data from ~20 engineering managers at Gusto. He found that while managers with four or less direct reports were still writing code pretty frequently, managers with five or more reports were writing zero lines of code. This result astounded me but also put into perspective how much I struggled to write code when I had exactly four direct reports.

Number of direct reports Average PRs/week

4 or less reports
1-3 PRs

5 or more reports
0 PRs

About a year into management, I felt burnt out. I was wearing three different hats, and each deserved more attention than they were getting.

The Individual Contributor Hat
It was very important for me to continue coding. In my mind, an ideal manager could unblock team members on any problem, apply a critical eye to every technical decision, and suggest a more effective way to implement any requirement. Stepping away from the code felt like it could block my personal technical development—an area which already felt stagnant because I was spending a lot of my time wearing the two other hats.

The Tech Lead Hat
This role, which at Gusto we call ‘Technical Anchor,’ revolves around setting the team’s technical direction, building up the team’s technical muscle, and contributing on project and capacity planning. This type of work was the most appealing aspect of leadership for me—the ability to have influence at a more strategic level and see the bigger picture of software development.

The Manager Hat
This role, which we call ‘People Empowerer,’ is the more classical manager role. It encompasses people leadership: 1:1s and coaching, providing feedback, performance evaluations, promotions, headcounts, hiring, and all that jazz 👐.

In hindsight, it’s fair to say that this aspect of my role is the one I knew the least about going in, and it caused me to feel a lot of imposter syndrome. It took up way more of my time than I had anticipated. I really wanted to do a good job at this, and it wasn’t apparent from the outside what this would require.

As a non-manager, most of your exposure to management work is through 1:1s and performance evaluations with your own manager. In that former role, these tasks took a much smaller part of my time. However now on the other side, even with a small team of four, they ended up taking quite a bit of time.

The A-Ha moment

Looking back, I remember one particular day. I had many manager-related tasks scheduled, and on the way to work I suddenly realized that these tasks did not scare me anymore. In fact, I felt confident that the day would go well.

This should have been a turning point—managing was no longer a daunting role. I knew how to approach it and I wasn’t terrible at it. And yet, I dreaded the day that was ahead of me.

Later on, I tried to figure out why I felt this way. I realized that although I had gained confidence in my ability to perform this type of work, I still didn’t look forward to it. It felt like work that needed doing, and I wanted it to be done well and by well-intentioned people, but I didn’t feel a particular desire to do it myself.

This was my ah-ha moment. The management tasks were not bringing me any satisfaction.

I realized that I didn’t want to be a manager anymore.

So now what?

Lesson #3: Remember lesson #1?!

If you’re interested in a career transition, tell people about it!

Part of me felt like I was back at square one. I dreaded telling my manager about my revelation. He’d been the one who had given me a chance and so patiently coached me into this role.

What would he say?

Would he lose confidence in me?

Would he try to negotiate with me to stay in this role?

Remembering Lesson #1, I wasted no time, and brought it up at our next 1:1. It was difficult, but I just bit the bullet and told him why I was unhappy in this role. He heard me, and to my surprise, wanted to take immediate action to help me make the change.

As a result of our conversation, we opened up a job posting for a new manager on my team, which would allow me to stay on as both a tech lead and an individual contributor. My replacement joined about a month later.

This change was such a relief for me. It allowed me to focus and spend more time in roles that I really enjoyed. Additionally, this felt like career progress and not a demotion, because Gusto didn’t treat it as such. Our engineering organization doesn’t treat the different hats as promotions or demotions.

If you’re considering different companies to join, think about whether you will be supported in a non-traditional career path, should you want one—and keep in mind that you may only discover you want it later.

If you want a career change

Here are some questions you can ask yourself:

• What do I like about my current role? How will those aspects change if I move to a different one?
• What are aspects of the new role that I’m looking forward to? Can I do more of that type of work without switching roles? And if so, how can I get recognition for it?
• What are aspects of my role that I don’t enjoy? Why not?
• What are aspects of the new role that I know little about? How can I get more exposure to them?
• Am I communicating about these topics clearly enough with my manager and other relevant people? Do they know what I want? Can they help me answer some of these questions more in depth?

As you discover more about your needs and interests, talk to people around you about how you can make your current role work better for you. You’ll lay the groundwork for what you want next in your career.