We talked to two Commit Engineers, Sim Brar and Toly Kudrevatykh, who chose to follow a management track part way into their careers, only to switch back to being independent contributors. We asked with them about the thought processes behind their decisions, what it was like managing people, and why they chose to return to the IC path.
No matter what industry you’re in, career paths rarely follow straight lines. Usually they meander around corners and through foggy marshes without a clear view of what’s on the other side. The good news: that’s totally normal. Without perfect information, we can’t be expected to make perfect decisions every time we’re faced with a fork in the road. Plus, our priorities change. A decision that’s right for you today might be seen in a differently in five years.
Engineers generally face a choice between two career paths: whether to go deep in technical expertise as an independent contributor, or shift towards management and leading teams of other Engineers. Two Commit Engineers, Toly and Sim Brar, faced that decision a few years ago. Each chose the management route, but they’ve since veered back towards being independent contributors, focusing on developing their technical skills as Engineers. We talked with Sim and Toly about the thought processes behind their decisions, what it was like managing people, and why they chose to return to the independent contributor path.
People versus tech
For Sim, part of the appeal of getting into management was having the opportunity to work more collaboratively with people, and helping other people get better at what they do. “At the time I chose the leadership path because it felt natural and organic to work with people, rather than working more with computers,” he says. “I like people and I like helping people achieve their own goals.”
At the time of his shift to a management role, Sim was having a hard time visualizing the journey of becoming a technical expert. “The concept of having 10 or 12 years of experience—it seemed like such a steep climb to get to that level of technical expertise. It seemed a lot more unapproachable than working with people.”
It was a similar situation with Toly. He notes that the company he worked for at the time made it clear that there were two paths Engineers could follow, one with a technical focus, the other a management track. The management path immediately appealed to him. “I thought I had some strengths that I could play to,” he says. “I don’t mind talking to people, I’m a fairly communicative person. Eventually I was promoted to team lead.”
Toly had a good experience at first, as the manager role enabled him to use skills he possessed, but hadn’t fully flexed as an Engineer. “Some of my strengths did play into the team lead role quite well,” Toly says. “I had lots of connections across the company, and it was easy for me to introduce people and ask for resources or help.”
Sim’s first experiences with managing people were also positive. While he had experience as a mentor and working with juniors on co-op terms, the move to a more concrete manager role felt fresh and new. “At first it felt pretty good, maybe because I needed a break from direct engineering,” he says. “Also because I already had a close relationship with the people on my team.”
Evaluating your impact
But both Toly and Sim found a few frustrations in the differences between leading people and engineering—especially when it comes to getting feedback on your own performance. While it is possible to assess management skills, it’s not as straightforward as evaluating coding skills. Management tends to focus on qualitative measures, and the impact of good leadership tends to take longer to reveal itself, while coding can be judged nearly instantly and evaluated by more concrete measures—speed, lines of code, number of errors.
“As a manager, you don’t get to compile code and see something immediately and get a dopamine hit of happiness,” says Toly. “The feedback was much slower and I realized I didn’t have the patience for it yet.
“I want to come back to management eventually, but I realized I wanted to switch back to development.”
It’s common for Engineers—who are used to seeing rapid growth in their coding skills and instant input on their progress—to feel frustrated when the feedback loop lengthens. “I’m so growth oriented—I’ve set my life up in a way where I’m always trying to get better,” Sim says. “As soon as I went into leadership it was hard to measure my growth. And I still felt like I had a lot of growing to do.”
“I hadn’t set myself up in a way where I could get the stimulus and feedback I needed to grow as a leader.”
Guidance for other engineers
In terms of advice they would give to other Engineers who may be at a similar fork in the road, Sim and Toly have some thoughts. Be honest with yourself and think hard about why you may be considering a management path. While it’s a great option for some, you have to consider whether you truly have a passion for managing people, or if you just need a break from coding. Maybe you’re burnt out.
“Not everyone loves coding, but they still want to work on technical problems. For those people management is probably a great fit,” Sim says. “I didn’t love coding for a long time—I had to build my love for it, but now that I’m here I’m finding it more and more exciting every day, because I’m solving harder and harder problems.”