Experimentation. Chaos. Resilience.
These topics are on the tip of the tongue for every engineering team struggling to deal with the complexities of developing and operating real-world, large-scale software systems. It’s easy to understand why. When teams start spending more time dealing with incidents and production outages than developing features and delivering customer value, it’s worth asking: Is the chaotic cycle of “develop and deploy, production is on fire now, FIX IT FAST, postmortem it weeks later, file a list of bug fixes we can’t get to because we’re too busy, develop and deploy, production is on...” really working for our teams? Or is there a better way?
This is what resilience engineering is about… and what we’ll explore together at REdeploy. But resilience isn’t just about the technology. It’s about teams and how they work. It’s about their ability to create the additional capacity needed to cope with unexpected challenges. It’s about how they make sense of the razor-sharp edge of the systems they work in and how they communicate that context to others who have to make their own critical, day-to-day tradeoffs and decisions.
And ultimately, it’s about the people in those systems. No team can be resilient and create technology that adapts to the world if the people developing that technology are burnt out. Creating resilient teams requires understanding how we can cultivate resilience in ourselves, in our colleagues, and in our friends, and be able to help them when the system is pushing them toward ineffective and unhealthy boundaries.
REdeploy is a rich exploration of all of these topics. But more than that, it’s an exploration of the intersection of and interactions between them.