Will Larson

@lethain
2.2K Followers
113 Following
251 Posts
Confused by the social internet. Author of Staff Engineer and An Elegant Puzzle.
Writinghttps://lethain.com/
Staff Engineerhttps://staffeng.com/
@kstewart thank you sir!

@markallanson generally yes, this page has the links from resources section: https://staffeng.com/guides/learning-materials/

StaffEng.com has most content from book in one format or another, but requires some browsing depending on which you’re looking for

Additional resources on Staff-plus engineering

Stories of folks reaching Staff Engineer roles.

It took me a long time to capture the idea concisely, but finally found way to talk about tradeoffs in a useful way, especially why some folks see tradeoffs everywhere, and others believe tradeoffs are rare: good tradeoffs are multi-dimensional.

Post: https://lethain.com/multi-dimensional-tradeoffs/

Useful tradeoffs are multi-dimensional.

In some pockets of the industry, an axiom of software development is that deploying software quickly is at odds with thoroughly testing that software. One reason that teams believe this is because a fully automated deployment process implies that there’s no opportunity for manual quality assurance. In other pockets of the industry, the axiom is quite different: you can get both fast deployment and manual quality assurance by using feature flags to decouple deployment (shipping the code) and release (enabling new functionality).

Seeing across different layers of context is one of the hard skills to learn as a Staff-plus engineer. It's also the only way to consistently get access to company-scoped problems rather than team-scoped ones.

Some notes: https://lethain.com/layers-of-context/

Layers of context.

Recently I was chatting with a Staff-plus engineer who was struggling to influence his peers. Each time he suggested an approach, his team agreed with him, but his peers in the organization disagreed and pushed back. He wanted advice on why his peers kept undermining his approach. After our chat, I followed up by talking with his peers about some recent disagreements, and they kept highlighting missing context from the engineer’s proposals. As I spoke with more peers, the engineer’s problem became clearer: the engineer struggled to reason about a problem across its multiple layers of context.

What are your preferred books, blog posts or case studies about engineering strategy?

Pulling together my thoughts on this topic and looking to understand the prior art. Collection thus far in https://lethain.com/strategy-notes/

Engineering strategy notes.

Recently, I am thinking quite a bit about engineering strategy, and as part of that have started re-reading previous resources on the topic, and looking for new things to read while I refine my point of view on what makes for good engineering strategy. The best introduction to my current theory of engineering strategy is Solving the Engineering Strategy Crisis, which has both written and video versions. You can also reading my other strategy writing via the strategy tag.

@MALPI that’s wonderful to hear! It’s a topic I’ve been iterating on for a few years now trying to get it all to come together
@reconbot hah yeah a pandemic era online purchase for us 😂
@lethain An approach I've taken to build trust and learn the environment is going after things that matter but aren't owned. It's usually cleaning the floor kind of things, eg; finish that test migration and decide to use one framework, remove the last 10 uses of that deprecated library, get data about customers to help an annoying decision get made so you can remove technical debt, etc

Although I'm quite convinced that I'll always be a writer first and a conference speaker second (or third or tenth), decided to record a quick cut of the same slides I gave at QCon a few weeks ago.

https://www.youtube.com/watch?v=vkfzpQ10eI4&ab_channel=WillLarson

Solving the Engineering Strategy Crisis

YouTube

Another draft chapter, this one on gelling the leadership team that reports to you (rather than one composed of your peers). Majority of "leadership teams" are "groups of individuals" rather than actual teams, and it's a lot more fun & effective as team.

https://lethain.com/gelling-engineering-leadership-team/

Gelling your Engineering leadership team.

One of the first leadership books I read was Patrick Lencioni’s The Five Dysfunctions of a Team, which introduces the concept of your peers being your “first team” rather than your direct reports. This was a powerful idea for me, because it’s much harder to be a good teammate to your peers than to your direct reports. While your incentives are usually aligned with the team you manage, it’s very common for your incentives to be at odds with your peers’ incentives.