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

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.

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.

Pretty neat to see my first book hit 1,000 amazon ratings. When I'd first published this thing, I'd go check the sales ranking and number of ratings multiple times a day, looking for some sort of evidence the book was alive. I haven't done that in quite some time (it's a lot less volatile 3 years later), but a pretty neat milestone.

A pure vanity metric for sure, but always grateful to see folks reading the stuff I write.

Most importantly, the key lesson I've learned about planning is that the stated planning process is rarely the real planning process! Don't get too caught up in the stated process, it's always directional rather than perfect.

Company planning is... so hard? Everyone I've worked with is pretty frustrated with their planning process, and there are layers of planning that I didn't really understand until stepping into my first executive role.

Notes on how to navigate company planning in an engineering executive role: https://lethain.com/planning/

How to plan as an engineering executive.

Some years back, I interviewed a senior leader for an engineering role, and asked them a question about planning. I enjoyed their response, “Ah yes, the ‘P’ word, planning.” That answer captured an oft heard perspective that planning is some sort of business curse word. Even when it goes well, planning is an objectively difficult task. When it goes poorly, the business loses months or years of potential progress. Despite those challenges, guiding your company’s plans towards the right work is uniquely impactful executive work, and is an area where effective executives can greatly distinguish themselves.

Scaled engineering organizations tend to generate a fair number of processes (tech spec reviews, incident reviews, bespoke perf processes, etc), and I spent some time writing about who ends up running those processes in common scenarios.

Full notes at https://lethain.com/who-runs-eng-process/

Who runs Engineering processes?

Uber ran a tech spec review process called the DUCK Review. “DUCK” didn’t stand for anything–it was created as a deliberate non-acronym–but was otherwise a fairly typical review process. When I first joined, we’d review one or two specs each week. The volume of requested reviews kept growing, and six months later there was a one to two week delay between requesting a review and receiving feedback. A year after that the process was disbanded due to lack of bandwidth to process all the incoming specifications.

Wrote up some notes on leaving executive jobs: thinking through the decision to leave, whether you need another job, whether you're "leaving too soon" wrt resume impact, exit packages, and so on.

https://lethain.com/leaving-the-executive-job/

Deciding to leave your (executive) job.

If two friendly executives meet for dinner, it’s likely they start by exchanging just how messed up things are at work. Initiatives are behind, layoffs are happening everywhere, the team is in disarray. Then they’ll laugh, and switch topics. Sometimes one of the executives can’t navigate the switch, and will keep ranting throughout their meal. Having problems is part of being an executive, but when you’re that second executive who can’t turn off the frustration, it’s time to start thinking about leaving.

Wrote some notes on structuring your engineering onboarding process: roles in running onboarding, when to prioritize, and so on: https://lethain.com/engineering-onboarding-programs/

Have been thinking a lot about the role of onboarding since I wrote this related piece in 2016 about onboarding and hiring at hypergrowth companies: https://lethain.com/productivity-in-the-age-of-hypergrowth/

Running your engineering onboarding program.

Most companies say that it takes three to six months for newly hired engineers to fully ramp up. Engineering leaders know it’s impolitic to admit that it takes their team longer than three to six months to onboard new engineers, so that’s what they say out loud, but they generally believe it takes longer for a new engineer to become fully productive. They also know that their most impactful engineers are still becoming more productive after years with the company.

Most engineering execs are happily going about their job when one day they're suddenly thrown into their first Mergers & Acquisition process to evaluate buying another company.

This can be a very confusing process, and I've written up how I recommend thinking about and running the M&A from engineering's perspective: https://lethain.com/engineering-in-mergers-and-acquisition/

Engineering’s role in Mergers & Acquisitions.

I managed the engineering team at Digg as we ran out of money, and were eventually acquired. It was an eye opening experience, and I learned a great deal about the reality and the optics of selling a company, particularly one with no money and a shrinking user base. Humbling was just the beginning. Since then, I’ve had the opportunity to evaluate a number of companies from the other side of the Mergers and Acquisitions (M&A) table.