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?
In March, I put together a framework for prioritizing technical infrastructure work, which I thought was fairly good but didn't inspire much feedback or excitement. Maybe it wasn't very good, and yeah the title was terrible: lethain.com/infrastructure…
Turns out, I'm _still_ very much thinking about planning infrastructure work, and for latest planning cycle at Stripe, we took another pass at evolving our approach, culminating in a new planning framework: lethain.com/infrastructure…
Your infrastructure priorities are defined by your users, baselines and timeframes.
Users are the folks you support, both outside and within your company.
Baselines are your service-level-objectives for security, reliability, productivity, efficiency and latency.
Timeframes are the eras across which you want to maintain your baselines: today, tomorrow, three years from now, etc.
It's still fairly simple, but I've found it surprisingly helpful! How do you prioritize infrastructure work?
