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/

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.

@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.

Pulled together slides and talking notes for upcoming talk at QCon in SF, which internally I'm thinking of as "Solving the Engineering Strategy Crisis" although that is indeed not it's official name.

The "complex' solution here is basically:

1. Write down your implicit existing strategy
2. Use one of two methods (top-down, bottom-up) to improve it where it has issues

Yup.

https://lethain.com/solving-the-engineering-strategy-crisis/

Solving the Engineering Strategy crisis.

These are speaking notes for my October 4th, QCon talk in San Francisco. See a video of this talk. Slides for this talk. Over the course of my career, I’ve frequently heard from colleagues, team members and random internet strangers with the same frustration: the company doesn’t have an Engineering strategy. I don’t think this problem is unique to Engineering: it’s also common to hear folks complain that they’re missing a strategy for Product, Design or Business.

Eng execs, and aspiring eng execs, talk a lot about personal brand. Generally, I think that's not a super interesting topic, much more interesting is building prestige.

"Brand" is active awareness, e.g. stuff you know about something. "Prestige" is ambient awareness, e.g. stuff you can find if you go look it up.

https://lethain.com/building-prestige/

Building personal and organizational prestige

Most months I get at least one email from an engineering leader who believes they’d be a candidate for significantly more desirable roles if their personal brand were just better known. Similarly, when funding is readily available during periods of tech industry expansion, many companies believe they are principally constrained by their hiring velocity–if their engineering organization’s brand was just a bit better, they believe they’d be hiring much faster.

Miss the Increment magazine, pulling together resources appendix for upcoming book, and articles like this one surveying how diff tech companies plan are unique resources. Takes access and time to assemble these sorts of things, and rare for both to intersect.

https://increment.com/planning/what-planning-is-like-at-netflix-mailchimp-and-more/

What planning is like at… – Increment: Planning

From sprint cadence to success metrics, here’s a snapshot of the planning process at Netflix, Mailchimp, Asana, LaunchDarkly, and more.

Gelling your Engineering leadership team. https://lethain.com/gelling-engineering-leadership-team/

This is another great post from @lethain I particularly like how he describes how you might evaluate your team when you start as an executive.

The main piece of advice I would add is that the best way I have seen to get a leadership team to gel is to get them to work together on shared objectives. You must set that up immediately, and the team formation will naturally emerge from that. At least that had been my experience.

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.