Hey! Welcome back to another week of musings.

We spent the weekend packing boxes with my wife, and on Sunday I took some time to meet with other Guatemalan's living in the Bay.

I hope you had a great weekend and managed to rest!

Was this forwarded to you? You can subscribe here!

Things I enjoyed in the past week

• Why Netflix is betting on systems thinkers, not specialists, in the AI era with Elizabeth Stone, CPTO of Netflix
• Wild AI-related reliability incidents are coming by Lorin Hochstein

I've been thinking about how a lot of the work we do is about "keeping the lights on" (KTLO) or "running the business" (RTB). Depending on your company's acronyms.

I keep coming back to this topic because every week we're asked to do more with the same or fewer people around. And while that's its own fight, I also see some teams struggle more than others because their time isn't going into executing these KTLO tasks, but into more reactive work: incidents, operational emergencies.

One area management over-focuses on is vulnerability scanning. Sure, we have a bunch of out-of-date dependencies, but how many are actually exploitable by bad actors? And how many of those dependencies are still providing value without being in the latest version?

From a systems-thinking angle, I've been chewing on all these topics: how they relate, and where to find a leverage point to change the current system. Like, if I imagine leadership agreeing to double our headcount, how would that really solve the problem?

I keep thinking that increasing headcount alone might make it worse without a functioning system. We might be prioritizing the wrong things at best, or stuck in analysis paralysis at worst.

I think people who have lived through high-growth startups might have experienced the idea of doubling the headcount every week, or every month. But in companies that have had stable products for so long, they get into a cadence of how things work, how long it takes to set a product in the roadmap, get a feature approved across multiple business units, etc.

At this point, I don't have a playbook to share. I've been trying to tackle this problem through a systems-thinking lens. I keep thinking that's the true unlock. In some cases, the visible problems are a bit fuzzy, so I'm also taking a first-principles approach. How should this team work if we started it today?

So I leave you today with more questions than anything: how often do you think about your team's efficiency?

Your turn

How do you tell the difference between a team that's understaffed and a team that's just not spending its time well? And if you've worked in a stable growth org before, how did you approach maintenance work without it swallowing everything else?

Let me know your thoughts by replying to this email!

Happy coding!