It’s time for tech to retire the myth of the “dead end” individual contributor track

This article was written by Eddie Kim, CTO and co-founder, Gusto.

Conventional industry wisdom often says the management track is the only long-term growth path available to engineers. Unlike management roles, which generally grow proportionally with the headcount of the company, individual contributor (IC) roles tend to have a much flatter structure. As a result, the IC career paths are oftentimes deemed a “dead end” unless you somehow manage to become the one or two technical leaders of the entire codebase.

Traditionally, the epitome of an IC’s career ends in a title like “Engineering Fellow” or “Chief Architect.” These are typically people with uncommon coding abilities who make an impact by creating new programming languages, inventing a faster sort algorithm, and keynoting at technical conferences. In reality, very few ICs have any interest in this, and even fewer people achieve this.

The two tracks are often presented as a binary choice, leaving management-inclined ICs stuck in the middle. While it’s true that IC and people management require very different skills that can be challenging to do well at the same time, a strong IC could be a solid programmer who also contributes to the organization in ways that aren’t just people management.

To help support those engineers interested in contributing in other ways, companies should redefine what it means to be an individual contributor, and create more flexible career paths for engineers as they scale. Here’s how:

Recognize the hidden power of the IC to turn something from zero-sum to infinite-sum

In depictions of business in pop culture, managers are often viewed as the ultimate power brokers within an organization. They are seen as the ones making decisions about the direction of the business and calling the shots.

But oftentimes, managers can only make decisions within the bounds of their part of the organization and the strategy dictated from above. They have fixed resources and are constrained to play a largely zero-sum game until something new comes along. Compare that to ICs, who can create new opportunities by shipping an idea from a hackathon, find efficiencies by tweaking code, and even create new markets through game-changing technical innovations.

Both roles have opportunities to demonstrate leadership, though ICs have more of an ability to create leadership opportunities out of thin air through the power of technology. Most companies, unfortunately, get this wrong and overly recognize people managers instead of ICs. The best teams support and recognize both managers and ICs without limiting the roles of either.

Focus on impact and allow for flexibility

Growth (whether you’re a people manager or an IC) hinges on impact. Both managers and senior ICs have to do things that contribute in big ways to the company.

There are many ways outside of coding that a senior IC can have impact. Senior ICs can design a better interview process that saves valuable engineering time without sacrificing interview signal. They can lead internal technical guilds that increase developer productivity. They can lead diversity programs that improve representation in the team. They can invest in developer tooling that cuts new engineering onboarding time in half. Each of these tasks has a significant impact on the long-term health and success of the engineering organization, and often requires the same level of effort as a coding sprint would. A company’s performance and promotion system needs to both recognize and reward this sort of work – these folks should be considered “Engineering Fellows” as well.

At Gusto, we recently redesigned our promotion process to address the impact gap in our performance reviews. Initially, our performance review process relied heavily on the ability of an individual’s direct manager to deliver a successful “sales” pitch on why their direct report should be promoted. ICs would write a long, multi-page essay about themselves and a committee would debate it, much like a dissertation or thesis defense. The process was too subjective and too focused on behavior – the “what” of what someone did (action), not the “so what” (impact).

To better measure and reward impact, we developed a new framework for breaking down engineer performance into several axes that can be discussed separately before drawing an overall conclusion. Our four axes are:

• Project Impact: The primary IC work done by the engineer. This is oftentimes the coding that an engineer does to ship a new feature or improve an existing one.


• Better Engineering: Improving the broader codebase or tooling in a way that increases the productivity of the entire engineering team. For example, improving build/test cycle time, or cleaning up legacy code that is hard to work with.


• People Impact: Helping others become more effective and the team become more healthy. This includes interviewing, mentorship of colleagues, onboarding new team members, or managing interns.


• Org Contributions: Making the broader organization healthier, including evolving people practices, driving DEI programs, or representing the company at external events.

The overall career growth of the IC is defined by the sum of impact across all three axes. I sometimes jokingly call this the Pokémon approach to career development.

By developing these axes, we were able to create a progression expectation for engineers at each level, outlining clear but flexible growth paths that allow them to shine in multiple ways. This flexibility has also made it possible for engineers to add new management skills and responsibilities to their roles, empowering them to shift between people-focused and technical-focused impact, all without actually having to be a people manager.

Better for engineers, better for organizations

To develop the strongest engineering organization possible, companies must empower ICs to co-create their own senior roles and growth tracks, by allowing them to lean into their natural strengths and interests. If you force your best engineers to become a manager of people when they don’t want to, that’s not good for the engineer and definitely not good for the organization. If on the other hand, you allow engineers to focus on what they’re good at, what they enjoy doing, and what’s impactful to the organization, you’ll create more opportunities for everyone and the organization will grow. Things turn from zero-sum to infinite-sum.

Retiring the false binary of management and IC engineering tracks can build stronger teams and stronger recruitment pipelines. Engineers want to work for companies with clear and flexible growth paths that reward a range of skills. This means recognizing contributions that fall outside of traditional and limited views of IC and manager roles.

Edward Kim is the co-founder and chief technology officer of Gusto. He is responsible for the software development and technical framework of Gusto’s people platform, which enables 200,000+ businesses to onboard, pay, insure, and support their teams.