When I was hired at Inch my “official” position quickly became an issue. For various reasons neither the title they wanted to give me initially (Engineering Manager) nor the one I would be given externally (CTO) nor the obvious Senior Software Engineer worked. So I proposed to help them define the next position on the technical ladder.
What follows is a translation of a document I wrote in French, slightly edited to remove Inch-specific details. It is still written from a European - and more specifically French - point of view. That document was later used to promote a 2nd engineer to Staff. I publish it here so it can help people needing to do something similar elsewhere.
Typical early career levels for software engineers (or developers) are relatively well-known:
Progression is based on experience and it is expected that a good engineer will reach mid-level after 2 to 5 years of experience and senior between 5 to 10.
Senior developers have two ways to evolve: branch into management or stay on the technical track. This document describes the second option.
Let’s start with a few key things to understand regarding management. A development “team” (project or run) is typically 3 to 10 people. It has a “lead”, which is not a level or a management position. It is a technico-organizational role assumed by a Senior+ developer at a point in time.
The names of levels after Senior differ depending on companies but can be for instance:
At some large tech companies the “Distinguished” level is equivalent to VP and Fellow to SVP or CXO. At Inch, Staff corresponds to level F. The difference between Staff+ levels is often defined by impact:
Those levels constitute a pyramid where each stage must be much smaller than the one below (e.g. by a factor of 5 at least) otherwise they stop making sense.
Given the size of Inch, only the Staff level makes sense. A Principal level may not be created until the company is large enough to have several independent technical teams (at least 12 developers, ideally around 30). Consequently, some things relating to strategy and aura are expected from the Staff level at Inch.
A key point is that Senior is a “terminal level”, which means it is not expected that all Senior engineers will become Staff at some point. An engineer may very well remain at the Senior level for their whole career.
Progression from Junior to Mid to Senior is very related to experience and hard skills (soft as well, especially for Senior). But the value of marginal experience goes down with the years and is harder and harder to measure.
The Staff level is still partially related to experience - at least 8 years are expected in general - but more importantly to impact within the company. This means hiring at this level is rare, and it is not unusual for a Staff Engineer to go back to Senior for a few years after a job change.
Important note: Staff is not a management level but it does require more soft skills than previous levels (more on that later).
Staff is a technical specialization level, hence not all Staff engineers look the same. To understand the differences, here are a few axes.
A developer can specialize in one or several fields or technologies and become a true technical expert. For instance, they can be a master of their language and framework and contribute to their core or ecosystem. They can also become experts in a business domain. Those are depth-first approaches.
Others, on the other hand, expand their knowledge horizontally and know about numerous domains, technologies and parts of the stack. This is the generalist, breadth-first approach.
In general it is rather a mix of both approaches: developers with a very wide background and a few specialty topics they master. We talk about T-Shaped people.
Will Larson defines 4 Staff+ archetypes: tech leads, architects, solvers and right hands.
A Staff Engineer should be able to:
Grapple with a complex, poorly documented system quickly. For instance, identify the root cause of a bug in a code base they do not know well.
Understand what limits a system, anticipate problems and propose realistic and pragmatic architectural changes while taking existing assets and resources into account.
Know and understand high-level software and system architecture principles (Conway’s Law, Gall’s Law, permission models, different kinds of data flows…)
Communicate with their team as a Lead, organize a project, implement new processes.
Communicate with their management: report their results and those of their team, give visibility on load and work in progress.
Communicate outside the company, for instance: with customers, with prospects, with candidates, with investors, with Open Source communities…
Deal with a crisis, for instance organize production incident response.
Analyze a development opportunity while taking all company-level parameters into account (cash flow, strategy and positioning, long-term vision). Think ahead 2 / 6 / 18 months.
Understand the concepts of backlog, velocity / capacity / pressure. Know how to prioritize, understand when to say yes and when to say no. Know how and when they should defend their opinion depending on the topic (when to “be right”).
Think ahead developments and choices, considering impact on maintainability, stability, evolutivity, complexity and overall performance.
Anticipate hiring needs and departure risks. Understand hiring may take 6 months, plus 6 extra months to become really efficient. Understand that at Inch scale not everyone is replaceable, but still reduce risk for the company in the event of a departure, including their own.
Do technical watch, implement new tools and processes when it is necessary - and not when it is not. Retiring tools and processes whose benefits are dubious. Tech watch channels available include HN / Lobste.rs / Tilde, blogs, podcasts, meetups, the GitHub feed, social networks…
Be visible. Communicate internally on their progress and that of their team, in spoken and written form.
Develop their own network. At this stage of their career, an engineer must know people to get in touch with regarding specific topics, recruiting, etc. This kind of network is developed through previous experiences, participation in meetups and conferences, Open Source contribution and so on.
A Staff Engineer should tick several (not all) of those boxes:
Be the designated expert of one or several significant parts of the technical stack or technical topics (e.g frontend, backend, infra / deployment, security…)
Be the designated expert of one or several significant parts of the product’s code base.
Have realized or led a development or technical evolution which is undoubtedly an important achievement at company level, recognized outside the bonds of the technical team. This kind of very visible project can be handed to a Senior engineer ready to evolve to Staff as a Staff Project.
Mentor one or several junior developers. This is in “achievements” and not “competences”: any Staff - and even Senior - developer should be able to help a junior get better or understand something, but some can be true career accelerators for the juniors they work with.