Staff Engineer, by Larson

Sunday September 19, 2021

It's all online for free too, but I enjoyed reading a paper copy of Larson's Staff Engineer. (Well: I skimmed some of the interviews that pad out the page count.) I really liked the use of QR codes with the endnote links. That could work well in Tufte-style margins too.

cover


"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. The best way to grow those around you is by creating an active practice of mentorship and sponsorship." (page 22)


"It might be addressing the sudden realization that your primary database only has three months of remaining disk space, and you can't upgrade to a larger size (in my experience, a surprisingly frequent problem at fast-growing startups)." (page 24)


"For mentorship and sponsorship, spend some time with Lara Hogan's What Does Sponsorship Look Like?, and for being glue, spend time with Tanya Reilly's piece that bore the phrase, Being Glue." (page 34)


"The first place to look for work that matters is exploring whether your company is experiencing an existential risk." (page 39)


"Foster growth" (page 40)


"Specific statements create alignment; generic statements create the illusion of alignment." (page 47)


"There's no such thing as winning, only learning and earning the chance to keep playing." (page 52)

Reminds me of Finite and Infinite Games.


"Premature processes add more friction than value and are quick to expose themselves as ineffective." (page 43)


"There's the old joke about Sarbannes-Oxley [sic]: it doesn't reduce risk; it just makes it clear to blame when things go wrong." (page 54)


"... adopting the "define errors out of existence" approach described in A Philosophy of Software Design." (page 54)

At a quick look, it seems like this is something like "give your functions defaults rather than exceptions" so if you ask for something out of range, for example, you get the last thing rather than throwing.


"Genuine best practice has to be supported by research, and the best source of research on this topic is Accelerate." (page 56)


"When it comes to complex systems and interdependencies, moving quickly is just optics. It's methodical movement that gets the job done." (page 69)


"I think this is the most important lesson I've learned over the past few years: the most effective leaders spend more time following than they do leading. This idea also comes up in the idea of the "the first follower creates a leader," but effective leaders don't split the world into a leader and follower dichotomy, rather they move in and out of the leadership and follower roles with the folks around them." (page 76)


"There's a well-worn model of genius encapsulated in the Feynman algorithm: "1) Write down a problem. 2) Think very hard. 3) Write down the solution." This mystical view of genius is both unapproachable and discouraging. It's also unrealistic, but it's hard for folks to know it's unrealistic if we don't write down our thinking process for others to follow. By writing down the process of finding an answer, as well as the rationale for the answer, folks around us can being to learn from our decisions rather than simply being directed by them" (page 85)


"Barbara Minto, whose The Pyramid Principle is the most influential work on effective business communication, is also a big fan of structure: "Controlling the sequence in which you present your ideas is the single most important act necessary to clear writing. The clearest sequence is always to give the summarizing idea before you give the individual ideas being summarized. I cannot emphasize this point too much."" (page 96)


"brag document" (page 106)


"Whether your company does ad-hoc promotions or uses a calibration process, promotions are a team activity and as Julia Grace, then of Slack, advised me once during a job search, "Don't play team games along, you'll lose."" (page 110)


"Share weekly notes of your work to your team and stakeholders in a way that other folks can get access to your notes if they're interested" (page 128)


"The flying wedge pattern of one senior leader joining a company and then bringing on their previous coworkers is a well-known and justifiably-despised pattern that relies on this built-in referrer-as-sponsor, but it doesn't have to be toxic if done sparingly." (page 139)


"There are some wonderful engineering leaders creating pockets of equitable access to Staff-plus roles, but those pockets can quickly turn into a Values Oasis that can't sustain itself once the sponsoring leader departs the company or changes roles." (page 139)


"Back in 2012, Patrick McKenzie wrote Salary Negotiation, which has since become the defacto [sic] guide to negotiating salaries for software engineers." (page 145)


"Staff-plus is all about enabling other people to do better work - to be a force multiplier." (page 184, from Bert Fan)


"This is not a meritocracy and your professional network is important." (page 186, from Bert Fan)


"To reach Staff Engineer, you have to know and do more than what you currently know." (page 209, from Ritu Vincent)


"A quote I love from Seneca is "Luck is what happens when preparation meets opportunity."" (page 267, from Damian Schenkelman)


"In the quest for efficiency over effectiveness, many companies trap their managers in a staggering amount of coordination and bureaucracy." (page 309)


"When we talk about designing a Staff-plus engineer interview loop, the first thing to talk about is that absolutely no one is confident their Staff-plus interview loop works well." (page 312)