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. There are a lot of examples to additional dimensions transforming tradeoffs: fast *and* deployment when you decouple release and deploy; high returns and low risk with portfolio, diversification, doing both things instead of X or Y with clearly defined budgets, etc

Over past few weeks, I pulled together my notes on executive job/role searches, which I hope will help folks pursuing their first executive role avoid some of the common issues ("how do I find these roles?!", "what are single triggers?!").

lethain.com/getting-engine… The most important idea for these searches imo is that they are all very bespoke, and there are few if any actual rules! (Don't worry, I don't actually know anything about luxury items, I drive a Camry Hybrid.)

"What should I measure when the CEO asks for engineering metrics?" is probably the most frequently recurring eng leadership question, and connects into a larger, somewhat nebulous topic: how should you measure engineering organizations?

Some notes! lethain.com/measuring-engi… The biggest challenge with answering this question directly imo is that there are a number of different stakeholders who all want very different things, and literal attempts to answer usually get artificially anchored on one of those stakeholders rather than solving for whole set

A friend and I are playing around with the idea of doing a small site where we answer anonymous engineering leadership questions ("eng leadership" meaning org, people, structural, process questions, but not technology questions).

Do you have a question? If so... Send me an email at (lethain @ gmail.com) with your question, provide a bunch of context, and we will provide our answers :-)

Give us a sense of the teams/folks involved, why it's a challenging. Details are great! Recommend using "SCQA" to frame your situation!

Few eng orgs have clear engineering strategies, they can feel almost mythical & intimidating to write. While struggling myself, I’ve landed on a reproducible way to write useful strategies: five 5 design docs, synthesize them into 1 strategy, repeat!

lethain.com/good-engineeri… The same thing works for writing genuinely useful visions as well. Write 5 strategies, extrapolate how those strategies will shape the next 2-3 years, and that’s the first draft of your vision doc.

What are best resources on becoming/being/operating as staff-plus engineer? Looking for more stuff like (thread): @keavy's perspective on being a senior technical leader w/o managing keavy.com/work/thriving-…

Wrote up my year in review post, comprised of mostly writing metrics :-)

lethain.com/2019-in-review/ 65 blog posts (-10 YoY), 3 writing contributions outside of blog (+3 YoY: Increment, 97 Things EM Should Know, An Elegant Puzzle), An Elegant Puzzle sold 16.7k copies (7k Q2, 6k Q3, 3K Q4), 383k pageviews (+173k YoY) with 21% social, 40% direct&rss, 22% search, 1% email

I've been working with a large-ish startup that's revamping their incident response and incident program, and ended up writing up notes on some of the phases and challenges of creating and operating these programs.

Some tips!

lethain.com/incident-respo… Incident programs start out focused on fast incident response. Later on they focus on consistent response across much larger team. Larger still, they end up justifying company's overall investment in reliability. These transitions are easy to miss and end up playing wrong game

Went down rabbit hole of @sriramk's memos page, and it is a highly recommended rabbit-hole to fall down!

sriramk.com/memos 1. @BillGates' memo on moviemaker is hilarious, although I can only imagine how I would have felt *receiving* that memo. Take away: entropy is real, even (especially?) for Windows XP.

sriramk.com/memos/billgate…

Over the last couple of years I've worked to build frameworks for infrastructure engineering teams to prioritize, invest and be durably healthy. This has culminated in four different approaches, one long blog post, and fifteen tweets.

lethain.com/how-to-invest-… Aside: If this is a topic you're interested in, I'll be talking about this next month at @velocityconf on June 12th! (Glad to sign books if you've got em!)

conferences.oreilly.com/velocity/vl-ca…

One challenge of infrastructure engineering is that we rarely talk about how to apply product management approaches to our work: problem selection, understanding our users, how tradeoffs impact different user cohorts, etc. Earlier this year, I spent some time chasing that thread, and ended up writing "product management in infrastructure", thinking about how we could do more of all those things: lethain.com/product-manage…

Software migrations are a way of life at rapidly growing companies, and increasingly I think your ability to migrate effectively is the defining constraint for your growth.

lethain.com/migrations/ Teams hate tech debt. If they can locally reduce it, they'll do it. So at some point all remaining avenues to reduce tech debt require ~everyone simultaneously adopting a new platform: migrations! Moving everyone? A *lot* of coordination!

This has been a terrible, staggering year in so many ways. It's also been a disproportionately interesting and meaningful year for me professionally, and I wanted to share some of what I learned in 2017 about engineering and infrastructure management. There is a surprisingly broad category of work where a single dedicated person saves person-years of rushed efforts later: ensuring systems are scaling (and not regressing), cost accounting, build tooling, code hosting, etc. Prefer two people, one is still the loneliest number.