The Many Roads to Staff Engineer

Building on Will Larson's Staff Eng Personas

When it comes to engineering leadership, few authors have been as consistently useful to me as Will Larson. Larson presents perfectly distilled lessons and observations from his experience as current CTO at Calm and former engineering leader at Stripe, Uber, and Digg, both on his blog and in his fantastic book An Elegant Puzzle: Systems of Engineering Management.

Larson has recently turned his attention to the complicated topic of engineering “IC” development. The common pattern for engineering career development follows two tracks: the engineering manager track, which is essentially the path of an engineer-turned-people-manager, and the “individual contributor” track, a name which horribly misrepresents the multiple personas contained within. Generally speaking, there’s a straightforward path from a new grad IC, to a “senior” engineer (I’ve heard the two ends of this spectrum bucketed into “juniors” and “seniors”). Beyond senior, there’s a grab bag of titles: staff, senior staff, principal. They mean different things at different companies, although most paths end with something resembling “distinguished engineer” or “technical fellow”.

While an Eng Manager’s growth follows the growth of the organizational tree they manage, an IC does not have the same easy proxy for measuring development. As both an EM and an IC mentor, I’ve fielded countless questions from aspirational senior ICs who want to reach the next level in their career. Unfortunately, institutional models of IC growth (captured in the form of some kind of trait matrix) become increasingly hand-wavey as the levels progress.

When it comes to “staff engineering”, the old management saying of “what got you here won’t get you there” applies. The path from junior to senior engineer is one of gradual evolution: a steady growth of technical capability, product knowledge, organizational acumen, influence and mentorship, etc. Yet this evolutionary approach has diminishing returns. At a certain point, the path forward isn’t one of evolution, but transformation. A staff engineer is not a “senior senior engineer”. It’s a different role.

I’ve struggled with how to express the different requirements of a staff role in a way that’s actionable for senior ICs. Most recently, I’ve settled on using “strategic definition and impact” as a differentiator. A staff+ engineer’s work is not measured by product impact, but by strategic definition; staff engineers can take a totally undefined area of a technical or product roadmap, provide the necessary strategic definition, and then lead execution against that strategy (whether in the form of people leadership, or complex technical delivery).

Larson’s recent explorations of staff engineering archetypes, complemented by his interviews with staff+ engineers on a dedicated StaffEng site, adds needed specificity to the general heuristic I outlined above. Larson’s encapsulation of the different shapes of staff engineer into four archetypes is incredibly helpful, and provides a framework for career growth conversations. What role does a senior IC find most relevant or attractive for their current stage of growth and interests? Selecting an archetype provides constraints for identifying a possible strategic direction in which the IC can make an impact.

While Larson’s four archetypes encapsulate nearly every flavor of IC growth, there’s one archetype that I believe is missing: the staff engineer as “Community Organizer”.

Larson places his archetypes within the context of “strong and weak team concepts”:

A strong team concept is one where ownership, work and accountability is generally assigned to teams. Signs of a strong concept are sprints, story points, tracking tickets, SLAs and goals. A weak team concept is one where most work is assigned to individuals and work is driven primarily through interpersonal connections rather than process.

The organizational context in which a senior IC finds themself constrains the potential archetypal paths. The Team Lead archetype is more prevalent in strong team organizations, while the parallel Solver archetype is aligned with weak teams organizations. (Note that “weak” has a pejorative connotation, but I don’t think that’s necessary; think of strong and weak in terms of strong and weak atomic charges, rather than some kind of virtue model.)

In addition to Team Lead, Solver, and Architect archetypes, Larson defines a final “Right Hand” archetype to describe a “senior organizational leader without direct managerial responsibilities”. The unspoken context here is a strong team concept: because the Right Hand role only applies to large engineering organizations, the assumption is that a strong team concept must apply (Larson notes “almost all companies move towards a strong team concept after they reach a couple dozen engineers, but some companies manage to evade the specter of process for considerably longer”).

So what’s a Right Hand to do in a weak team concept organization? Put another way: Larson’s “Right Hand” title is feudalistic in origin (a reference to “the Hand of the King”). What would a more democratic alternative look like?

Enter my extension to Larson’s model: the Community Organizer.

As with a Right Hand, the Community Organizer addresses problems that “are never purely technical, and instead involve the intersection of the business, technology, people, culture, and process.” The difference from a Right Hand is that a Community Organizer cannot “delegate execution to the most appropriate team” in a weak team org, nor can they rely on the “borrowed authority of a senior leader”, given that the political capital of leaders is diminished in a weak team context.

A Community Organizer “get[s] people to work together to solve their own problems”:

Some liken the role of a community organizer to that of the coach of an athletic team, in that it is the organizer’s job to get other people to take the lead. Others say that an organizer builds community with a purpose. Still others define an organizer as someone who “builds a group of people or institutions to address a common problem through collective action.” (from a definition here)

The Community Organizer Staff Eng, then, is a facilitator and connector. They work to define the details of a senior leader’s strategy, then connect the dots across that leader’s org to implement the strategy. Success in the role relies on a broad understanding of the technical systems at play across the org, in addition to a careful political understanding of the various motivations of (and alliances across) the key organizational players. Most importantly, the role relies on a deep well-spring of patience; this role presents hefty strategic problems to solve, while minimizing the available levers to deliver solutions.

The complexity of growth for the IC path perhaps explains why so many ICs veer into engineering management, whether or not they feel an aptitude for or interest in people management. EM growth continues the linear pattern of growth from junior to senior IC. Yet while senior IC growth is complex, it’s also an opportunity for engineers to “choose their own adventure”; the many flavors of growth enable a diverse catalog of success patterns. My hope is that increasing the clarity of staff+ archetypes will encourage ICs to stick the path and pursue Larson’s ideal of the forty year career.