More on this book
Community
Kindle Notes & Highlights
At most technology companies, you’ll reach Senior software engineer, the career level for software engineers, in five to eight years. At the career level, your company’s career ladder won’t require that you work towards the next promotion; being promoted further is an exception rather than expected. This is also when many engineers are first given an opportunity to move into engineering management.
Engineering management is the first track, and the second is technical leadership. The technical leadership track is populated by titles like Staff engineer and Principal engineer.
This book standardizes on the most common sequence of titles: going from Senior to Staff, followed by Principal, and then Distinguished.
The Tech Lead guides the approach and execution of a particular team. They partner closely with a single manager, but sometimes they partner with two or three managers within a focused area. Some companies also have a Tech Lead Manager role, which is similar to the Tech Lead archetype but exists on the engineering manager ladder and includes people management responsibilities. The Architect is responsible for the direction, quality, and approach within a critical area. They combine in-depth knowledge of technical constraints, user needs, and organization level leadership. The Solver digs deep
...more
Tech Leads are the most common Staff archetype and lead one team or a cluster of teams in their approach and execution. They’re comfortable scoping complex tasks, coordinating their team towards solving them, and unblocking them along the way. Tech Leads often carry the team’s context and maintain many of the essential cross-team and cross-functional relationships necessary for the team’s success. They’re a close partner to the team’s product manager and the first person called when the roadmap needs to be shuffled. Earlier in their career, they will have implemented their team’s most complex
...more
Most importantly, an organization needs roughly one Tech Lead for every eight engineers, making it far more common than other archetypes.
Architects are responsible for the success of a specific technical domain within their company, for example, the company’s API design, frontend stack, storage strategy, or cloud infrastructure. For a domain to merit an Architect, it must be both complex and enduringly central to the company’s success.
The Architect role tends to evolve in relatively large companies, companies with exceptionally complex or coupled codebases, and companies that are struggling to repay the technical debt they created in their initial sprint to product-market fit. Some companies push for Architects to remain deep in the codebase, and others set a clear expectation that Architects must not write code: both models work for some companies.
The Solver is a trusted agent of the organization who goes deep into knotty problems, continuing to work on them until they’re resolved. Folks in this role are moved onto problems identified by organizational leadership as critical and either lacking a clear approach or with a high degree of execution risk. Where most Staff-level roles require a very heavy dose of organizational wrangling, the Solver generally operates on problems that are already identified as organizational priorities and thus are called on to do relatively little org-level chiropractics. On the other hand, they generally
...more
You’re less likely to encounter this role at traditionally managed sprint-centric companies until those companies become relatively large or long-lived enough to acquire their own varietal of technical debt.
The Right Hand is the least common of the archetypes, showing up as an organization reaches hundreds of engineers and is akin to operating as a senior organizational leader without direct managerial responsibilities.
Folks in this role attend their leader’s staff meetings and work to scale that leader’s impact by removing important problems from their plate. Problems addressed at this level are never purely technical and instead involve the intersection of the business, technology, people, culture, and process. Right Hands often dive into a fire, edit the approach, delegate execution to the most appropriate team, and then pop over to the next fire elsewhere in the organization. The joy of these roles is that you only work on essential problems. The tragedy is that you’re always on to the next issue by the
...more
All companies develop a need for engineers who can fill the Tech Lead role, which makes it the most accessible archetype to attain your first Staff engineering role. Companies that emphasize individual ownership rather than team ownership often develop the Solver early. On the other hand, companies that operate under strict sprints or agile methodologies tend to develop that role late, if ever. In the recent crops of fast-growing technology companies, the Architect and Right Hand roles have generally emerged as the organizations reached one hundred and one thousand engineers, respectively, and
...more
The Tech Lead and Architect tend to work with the same people on the same problems for years, developing a tight sense of team and shared purpose. Some months their focus will be a top company priority, and sometimes they’ll be humming along so well that executives forget their team exists.
The Solver and Right Hand bounce from fire to fire, often having more transactional interactions with the folks they’re working with on any given week. They’re tightly aligned with executive priorities and are likely to receive recognition for addressing leadership’s most pressing problems. On the other hand, while they’ll nominally be on a team with other folks, there will generally be little-to-no overlap within their team’s areas of focus, and they’ll often have a limited sense of community.
I feel most impactful when I can facilitate setting a technical vision for an area and get people moving toward that vision. I think we would all agree that we want our code to be better architected than it is or improved in some way. However, I’ve found that often people have some vague sense of wanting better without having a clear idea of what that thing they want is. I like to help the group decide on a shared understanding of where exactly they’re trying to get (it’s actually okay if we never get there) and come up with a general game plan of how to get there.
Much as the Lorax speaks for the trees in his popular children’s book, Staff engineers speak for their companies’ technology.
There’s a popular vision of heroic leadership that centers on extraordinarily productive individuals whose decisions change their company’s future. Most of those narratives are intentionally designed by public relations teams to create a good story. You’re far more likely to change your company’s long-term trajectory by growing the engineers around you than through personal heroics.
Staff-plus engineers are the folks who will often get unexpectedly pulled into the room where this sort of decision is happening. This gives them the opportunity to inject the engineering context and perspective into a decision while it’s still possible to change the outcome.
Hill-climbing can’t solve every problem, but it’s so effective that many companies struggle to take other approaches.
They find a couple of trusted individuals with broad skills, allocate some resources, and check back in a few months later to see what they’ve discovered. One of those engineers is often a Staff engineer.
It’s not glamorous, but high impact organizations often have one or more Staff engineer working behind the scenes expediting the most important work and ensuring it gets finished.
Most write some, some write none, but none write as much as they used to earlier in their career.
Even if you’re not writing much, you’ll be reading a ton of your coworkers’ code and doing a fair number of code reviews.
Early in your career, it’s easy to get attached to software development’s quick feedback cycle–write, test, ship, repeat–and most of the work you’ll be doing at this level replaces that feedback loop with one that takes weeks, months, and years.
The impact and the personal growth lives in those longer timeframes, and while everyone I spoke with wished they’d occasionally get more time to code, and admitted worrying some days that they weren’t accomplishing much, none of them regretted their transition into their current roles.
The three consistent advantages that generally come with a Staff-plus title are:
allowing you to bypass informal gauges of seniority, facilitating access to “the room,” increase in current and career compensation.
A potential fourth advantage is that some folks find that the title grants more agency to select the projects you work on, but others find that increase in agency is swallowed by a comme...
This highlight has been truncated due to consecutive passage length restrictions.
Most things relied on more informal gauges of seniority.
Many technology companies describe themselves as pursuing meritocracy, defined as creating the conditions for talented employees to rise to the top naturally. Given there isn’t any widely accepted measure of individual merit, such companies come to rely on what Nelson aptly termed “informal gauges of seniority.” While these gauges are believed to evaluate ideas objectively, their sheer informality becomes a broad vector of bias and often conflate confidence with competence.
Small companies tend to have fairly ad-hoc compensation, and increases come from direct negotiation with your manager.
However, most companies introduce compensation bands for each role by the time they reach one to two hundred folks.
The highest-paid roles at any company tend to be the executive and senior management roles. As companies grow, they typically create a compensation mapping between management and engineering roles, such that reaching Staff-plus roles (and sometimes this is Sr Staff or Distinguished roles rather than the initial Staff role) will significantly bump your compensation.
Even if your current company doesn’t compensate for Staff-plus engineer roles much differently than for Senior engineer roles, some companies do. Throughout your career, you can choose to steer towards such companies, and doing so with a Staff-plus title will meaningfully increase your lifetime earnings.
For example, Solvers often do get access to the most interesting work. Conversely, a Tech Lead would probably be undermining their team if they operated that way.
the most consistently effective way to get access to interesting work is being hired to do it,
The one consistent exception to this rule is that women and minorities often do find they spend significantly less time and energy, proving themselves once they attain a Staff-plus title.
The delayed feedback can initially feel quite demoralizing as you replace the visceral coding REPL with the uneven progress of mentorship, relationship building, and strategy.
An astute reader will notice two critical themes discussed in What do Staff engineers actually do? are missing from this topic list: the first is “mentorship and sponsorship,” and the second is “being glue.”
Many companies conflate high-visibility and high-impact so strongly that they can’t distinguish between preening and impact, which is why it’s not uncommon to see some companies’ senior-most engineers spend the majority of their time doing work that’s of dubious value, but that is frequently recognized in company meetings.
Such changes make the organization increasingly dependent on the new leader and also ensures anything that does go well gets attributed to the new leader directly rather than their team.
Companies operate in an eternal iterative elimination tournament, balancing future success against surviving until that future becomes the present.
Sometimes you’ll find work that’s worthy of attention but which an organization is incapable of paying attention to, usually because its leadership doesn’t value that work. In some companies, this is developer tooling work. In others, it’s inclusion work. In most companies, it’s glue work.
Teaching a company to value something it doesn’t care about is the hardest sort of work you can do, and it often fails, so you should do as little of it as you can, but no less. As a senior leader, you have an ethical obligation that goes beyond maximizing your company-perceived impact, but it’s important to recognize what you’re up against and time your efforts accordingly.
A surprising number of projects are one small change away from succeeding, one quick modification away from unlocking a new opportunity, or one conversation away from consensus.
With your organizational privilege, relationships you’ve built across the company, and ability to see around corners derived from your experience, you can often shift a project’s outcomes by investing the smallest ounce of effort, and this is some of the most valuable work you can do.
It’s surprisingly common that coaching a teammate on how to tweak a project into something finishable and then lending them your privilege to budge the right friction points will transform a six-month slog into a two-week sprint with almost an identical impact.
Sure there’s work that you’re faster at or better at than some other folks, but much more important is the sort of work that simply won’t happen if you don’t do it. This work is an intersection of what you’re exceptionally good at and what you genuinely care about.
