Last year, Mary Thengvall and I embarked on a journey to produce the software development and operations industry’s first conference on how to sustainably build and promote resilience in code & technology, teams, and individual people.
And thus was born REdeploy.
Today, I’m happy to announce: REdeploy is REturning for 2019!
We’ll be continuing the conversations on Resilience and Chaos Engineering we started last year, further exploring the bleeding edge of technical, operational, and operator practice, and bringing together a community of practitioners from around the world who are using the concepts of Resilience Engineering today to wrestle with the…
As many of you know, Mary Thengvall and I produced and co-chaired REdeploy last year, a conference on the intersection of resilient technology, organizations, and people. Mary recently posted a three-part retrospective series on the conference.
Despite ignoring my own advice about running retrospectives within 72 hours after incidents, here are some of my musings about the 2018 event (based largely on notes I, at least, did take in the days after):
This post is part of a larger retrospective on REdeploy 2018; the discussion about our CFP process, specifically, was split out into its own post; read the full retrospective here.
Mary talked a little bit about our CFP, but I think it’s worth talking a bit more about because it’s one of the aspects of REdeploy I’m most proud of.
One of the lesser known REdeploy facts is that Mary and I originally didn’t plan to have a CFP: we were going to invite speakers. But there was such interest in a CFP that we ended up putting one together…
The 737Max and Why Software Engineers Might Want to Pay Attention
As someone with a bit of a reputation for talking about aviation and software development and operations, I’ve been asked about the 737Max repeatedly over the past week. I’ve been watching this story develop since November of last year, when the Lion Air 737Max crashed. Given recent developments, if you want a pure-aviation take on what’s going, there are better people to ask.
But that’s not what we’re here to ponder. This is more about the facts we know right now and what it means for our industry.
I’ve noticed an interesting pattern when discussing incidents with engineers over the years.
One of the topics that invariably comes up is the concept of “root cause,” a notion faithful followers of my Twitter stream know that I have at least a few thoughts about. Many organizations base their entire process of understanding incidents on the concept, and many of the techniques they use to facilitate that understanding, such as “The Five Whys,” are firmly rooted in this concept of a “linearity of events.”
Challenging this idea, and suggesting that in complex systems, this linearity is soothingly deceptive — but…
Astute followers may be wondering “Hey, wait a second, I thought you graduated last summer? Twitter has the receipts!”
Well, I did march with my classmates last summer. But, that didn’t mean everything was all signed, sealed, and delivered. It took another six months to finalize all the analyses, cross the I’s, dot the T’s, add Easter egg footnotes, and hand it off to the assessor for final review and approval.
In America, it is generally considered taboo to discuss salaries.
Some of this is surely rooted in socially normative behavior, where discussions of personal finances are considered conversation’s most intimate tier. Some of it probably comes from that stigma being cemented into the “professional identity” expected of employees. (Some companies have even gone so far as to make open salary discussions a dismissible offense!)
This is unfortunate, because sharing compensation information is the best way to get an unfiltered pulse on the local job market, to correct for socio-economic, racial, gender, and other prejudices, and put labor on a more…
Three years ago when I would talk to engineers and technology leaders about the ideas around Chaos Engineering, only about a fifth of the audience had heard of the concept. Now when I mention the term, most hands in the room go up.
This is due in large part to Netflix’s Chaos Monkey (and the rest of their “Simian Army”) as well as their Chaos Engineering team’s stories on the work they’ve done in the space and the benefits it’s produced.
I was recently shopping at my neighborhood grocery store and encountered yet another real example of the omnipresence of work-as-imagined versus work-as-performed.
With only 12 checkout lanes, this is a smaller store. It’s also a heavily trafficked store, sometimes causing long lines. So, any out-of-service lanes have a big customer and operational impact. (Navigating people waiting as the lines spill down the aisles can be… an adventure.)
Anyway, on this particular day, I’d put my credit card in the venerable customer-facing PIN pad; it beeped and asked me to sign. At this point, I noticed that the wire connecting the…
As an infrastructure nerd, I found it fascinating.
But as a student of human factors, this bit also stood out to me:
Four years later, signal failure caused one train to rear-end another on the Williamsburg Bridge, the fourth such collision in two years. The driver died, and several dozen passengers were injured. The train was going at 36 mph through a signal designed for trains whose maximum speed was 28 mph…
Build & release engineering / DevOps / human factors; Managing Partner at Release Engineering Approaches: Simply ship. Every time. @ShipShowPodcast alumn.