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!
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.
Thanks to many folks, and @skamille and @b0rk in particular, for suggestions on the earlier version of these ideas that struggled to get them out clearly: lethain.com/engineering-st…
Also a bunch of existing articles and posts that were v helpful, starting with “Sending gifts to future-you” by @whereistanya
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
Getting to write in different, non-blog mediums was the most fun I had writing this year, and something I hope I can continue next year. If you have writing projects that require non-book levels of effort, lmk!
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.
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
Most companies hang on to the "small group of long-tenured experts" approach too long, even though almost no one likes it (except the occasional hero). This is because structured approaches initially work worse than heroics, but they are still only thing that scale in long-run
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.
2. @stevesi memo on computing at cornell. All students had computer accounts since '75! TCP/IP as common language across VAX/PDP/Prime/Sun/Macintoshes/etc managing cost of heterogeneity. Software to run it all was free. The internet: not a fad.
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.
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!)
Is infrastructure really so different as to need specialized approach to investment? Yeah, I think the average infrastructure team does have different constraints in two ways: (1) a lot more "forced" work driven by reliability, security, efficiency, etc and
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…
Lately tho, I'm even more interested in the difficulty of managing a portfolio of infrastructure projects. Which users should we focus on this planning period? How do we make this *particular set* of tradeoff between maintenance and innovation?