"Fail Fast, Fail Forward" is Great... Until it (Really) Isn't
As I’ve worked with the DevOps community over the last decade, I’ve noticed a few patterns. One pattern many of you have heard me rant about often is the general lack of understanding around the value that technical communities (and the community builders) can bring to the table. But another pattern I’ve picked up on is that the “fail fast, fail forward” mentality doesn’t just impact the technology -- it impacts the surrounding people and organizations as well.
The common definition of resilience is the ability to absorb or avoid damage without suffering complete failure. This idea of “complete failure” juxtaposed with the “ability to absorb or avoid damage” makes me think of the handful of companies that push boundaries (whether cultural, work/life balance, tool choices, etc.) just as far as they can without causing any “true damage.”
As an entrepreneur myself, I understand the concept of “how do I maximize my time / value / energy?” from a business perspective. But when you’re dealing with people, this type of practice isn’t healthy. As an industry, we’ve done so much to make sure our technology will stretch and grow to be more effective and efficient that sometimes we forget about the impact it can have on our organization and on our teams. From burnout, to how we expect individuals and teams to keep up with the ever-changing technology landscape, to the constant fear of “keeping up with the Jones’s” and FOMO, to how to protect your team from work creep and overwhelming tech debt, and more, these are all issues that can’t be addressed from a technology standpoint; they have to be addressed holistically.
Enter REdeploy, happening Aug 16-17 in San Francisco, hosted and produced by myself and my good friend J. Paul Reed.
We decided to call it REdeploy for two reasons: First, the RE in the name refers to “resilience engineering,” which is an academic area of study within the larger Safety Sciences that has been written and talked about for the last decade. Chaos Engineering -- a phrase you may be more familiar with -- is about how to make our technical systems more flexible and able to bounce back from outages and other disturbances. It’s a subset of resilience engineering, which takes the concept further, looking at how all parts of the system “bounce back,” and how to amplify these properties. As Paul says, resilience engineering puts the chaos in context.
Secondly, an update to a website or service is called a “deployment”, and when there’s a problem with a deployment, fixing it often requires a “redeploy” of the site. Our goal with this conference is to “deploy” Resilience Engineering within the technology community, which in turn will redeploy the way that we think about and perform working in the tech industry.
Paul and I have been having conversations over coffee, lunch, and drinks for the last year about the need to re-approach the “fail fast, fail forward” concept holistically and have realized that it’s time to get other people engaged in the conversation with us. Though we both have ideas and experience in the matter, we recognize we don’t have all the answers. We also know there are many other smart people out there who care deeply about issues like burnout, team dynamics, and navigating the increasing rate of change in our industry, in addition to chaos and resilience engineering in distributed systems.
It’s no longer enough to talk about things only from the perspective of code and technology -- we have to take into account the impact our technical decisions are having on our colleagues, coworkers, and friends because without resilient people and organizations, we can’t create truly resilient technology.
We’re committed to starting a conversation about resilience engineering that covers more than just the technology -- the intersections between resilient tech, resilient organizations, and resilient people, and how we, as individuals, teams, and an industry, go about fostering, constructing, and maintaining these qualities.
REdeploy is about figuring out how to bring these topics into the day-to-day conversations in the tech community so that people understand just how crucial they are. In true community builder style, my hope is that this conference will be a conversation starter; that attendees will be part of defining the conversation rather than being told what the answers are! In other words, this isn’t your average “sit back and be talked to” conference. I want you to show up, be present, and be deliberate with your conversations.
Still with me? Great -- I’d absolutely love for you to join us at the conference! We want this first year of attendees to help fill out the definition of what it means to be “resilient” in the technology industry, from every aspect and angle, and build that community of practice with us. Come get a crash course in resilience engineering. We want you to be able to take the ideas back to your organization, play with them, and share your results with the larger community.
If you’ve got questions, feel free to leave a comment below, or shoot me a note on Twitter (@mary_grace or @REdeployConf). I hope to see you in San Francisco in August!