Skip to content

Case Studies

Theory is useful until it meets reality. Then you need patterns.

This section collects situations I've navigated—or helped others navigate—as an engineering leader. Not as polished success stories, but as honest accounts of what worked, what didn't, and what I'd do differently with hindsight.

These are not prescriptions. Every team, every company, every crisis has its own shape. But patterns rhyme. The dynamics of a team under pressure, the friction points when scaling from 10 to 50 engineers, the communication breakdowns that turn a minor incident into a trust crisis—these repeat across contexts. Recognizing them earlier makes you better at responding.

What you'll find here

Each case study follows a consistent structure:

  • The situation: What happened, what was at stake, and why the normal playbook wasn't enough.
  • The approach: How we navigated it—decisions made, trade-offs accepted, rituals adjusted.
  • What worked: The things that actually made a difference.
  • What didn't: The missteps, the delayed calls, the things I'd change.
  • Artifacts: Copy-pastable templates, agendas, or communication scripts drawn from the experience.
  • Signals and failure modes: How to recognize similar situations early, and common ways they go wrong.

The goal is practical transfer. Not inspiration—patterns you can adapt.

Case studies

Leadership in Crisis

When systems fail and stakes are high, leadership becomes visible in ways it normally isn't. This case study covers how to lead an engineering team through a major incident—not just the technical response, but the human side: communication under pressure, decision-making with incomplete information, protecting team health while managing stakeholder expectations, and recovering trust after things stabilize.

Useful when: You're facing (or preparing for) a major outage, a security incident, a critical data issue, or any situation where the normal cadence breaks and urgency takes over.

Scaling Remote Teams

Scaling a remote-first engineering team from a handful of people to dozens—or from dozens to over a hundred—introduces friction that doesn't exist in co-located settings. This case study covers the inflection points where communication breaks, coordination costs explode, and team cohesion frays. It's about the structural and cultural changes that make scaling possible without losing what made the team work in the first place.

Useful when: You're growing headcount, splitting teams, adding new functions, or noticing that what worked at one size is starting to fail at another.

How to use this section

These case studies are meant to be read with your own context in mind. As you read, ask:

  • What's similar to my situation? What's different?
  • Which patterns are showing up for me now?
  • What decisions am I delaying that might get harder later?
  • What artifacts can I adapt and use this week?

The best time to read about crisis leadership is before the crisis. The best time to think about scaling is before the team doubles. But if you're already in it—these patterns still help. Start where you are.