Technical leadership
Staff Engineer
Will Larson and Tanya Reilly
At senior levels, durable impact is multiplied through people, context, and direction rather than individual output alone.
19 Readwise highlights · In book order
Highlights
Camille Fournier’s The Manager’s Path, Julie Zhuo’s The Making of a Manager, Lara Hogan’s Resilient Management, and even my own An Elegant Puzzle.
Being a Staff-engineer is not just a role. It’s the intersection of the role, your behaviors, your impact, and the organization’s recognition of all those things.
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.
setting and editing technical direction, providing sponsorship and mentorship, injecting engineering context into organizational decisions, exploration, and what Tanya Reilly calls being glue.
It can be helpful to think of this as being a part-time product manager for technology.
One constant across all roles is that the reality of setting technical direction is far more about understanding and solving the real needs of the organization around you and far less about prioritizing technology and approaches that you personally are excited to learn about. In earlier roles, you may have tried to influence decisions towards technology choices you were motivated by; in senior positions, you’re accountable to the business and organization first and yourself second.
You’re far more likely to change your company’s long-term trajectory by growing the engineers around you than through personal heroics.
over time the right people will be in the right places at the right time.
Most write some, some write none, but none write as much as they used to earlier in their career.
When you have a title, you don’t have to spend so much energy putting your credentials on the table. It helps set the context for others. You’re more respected from the outset, and that’s been really noticeable.
If you do find your time diverted towards proving and reproving yourself, the title will return a considerable measure of time to you for reinvestment.
If you start dedicating even a couple of hours a week to developing the team around you, it’s quite likely that will become your legacy long after your tech specs and pull requests are forgotten.
We only get value from finishing projects, and getting a project over the finish line is the magical moment it goes from risk to leverage. Time spent getting work finished is always time well spent.
focus on work that matters, do projects that develop you, and steer towards companies that value genuine experience.
To write an engineering strategy, write five design documents, and pull the similarities out. That’s your engineering strategy. To write an engineering vision, write five engineering strategies, and forecast their implications two years into the future. That’s your engineering vision.
You should write design documents for any project whose capabilities will be used by numerous future projects. You should also write design documents for projects that meaningfully impact your users. You should write a design document for any work taking more than a month of engineering time.
fix the hot spots that are causing immediate problems adopt best practices that are known to improve quality prioritize leverage points that preserve quality as your software changes align technical vectors in how your organization changes software measure technical quality to guide deeper investment spin up a technical quality team to create systems and tools for quality run a quality program to measure, track and create accountability
Study how other companies adopt similar practices, document your intended approach, experiment with the practice with a few engaged teams, sand down the rough edges, improve the documentation based on the challenges, and only then roll it out further. A rushed process is a failed process.
If you’re deliberate in your approach, you’ll be able to influence your organization’s leaders immensely over time, but you’ll only get that time if you learn to remain in tight alignment at each step along the way.