In the rush to be original, innovative, provocative, or first-to-market, we often forget to acknowledge “prior art” or provide the context for the new ideas that we’re espousing. The resulting lack of credibility is one of the most serious threats to emergent fields and their practitioner communities (such as devops or systems safety).
Would devops exist without ITIL or the work of Deming? Would Agile exist without Waterfall? Would the all-electric Tesla Model S exist without the hybrid Prius and the gas-guzzling Hummer?
That is not to say that there’s nothing new under the sun. However, even the most groundbreaking ideas do not exist in a vacuum, but only in relation to previous ideas. They build on—or refute—what came before. Humans suffer from a built-in resistance to change, and when new ideas are presented without proper context or attribution, they risk becoming just someone’s brilliant ideas, too easy to dismiss or accept, depending on the person’s popularity, without full and critical evaluation.
In science, it’s simply not enough to receive new ideas in dreams or visions; ideas that stick must have solid foundations, and often come with bibliographies many pages long.
Want to build your or your idea’s credibility? Want to strengthen your nascent field or emerging community? Emphasize their lineage, and give full attribution.
Recently, a recruiter (who I’m lovingly calling “#1 Recruiter”) sent this gem on LinkedIn with the subject “I would like to talk to you”:
I work at [Company] (#1 Hedge Fund in the world), reviewed your profile and I would like to talk to you. Please let me know your availability to connect next week.
I tweeted and ignored the SPAM, but a few days later, #1 Recruiter followed up:
I am following up with you because I work at [Company] (#1 Hedge Fund in the world), reviewed your profile and I would like to talk to you. Please let me know your availability to connect next week.
Notice the expert use of copy-paste. To be fair, he did include a few extra links with information about the company, including their “Culture and Principles” web page. Nice touch!
This interaction neatly summarizes just about everything that’s wrong with recruiting (and LinkedIn). So instead of ignoring, this time I wrote a brief reply, cc:ing the CEO of #1 hedge fund in the world:
If you actually reviewed my profile, you would see that I know at least half a dozen people who currently work at [Company]. I am *quite* familiar with the company, and appreciate its culture.
One of the core tenets of your company’s culture is radical openness and honesty. With that in mind, I’d like to be open and honest with you. What you’ve sent is SPAM. It reeks of mediocrity, the opposite of your company’s “overriding objective [of] excellence”. Stating only that you work for a company with money (“#1 hedge fund in the world”) as the reason to connect will not net you people who “value independent thinking and innovation”. I’d be weary of anyone who actually responds to your message (and I’d guess only about 1 or 2 out of a 100 do); they, like you, hate their jobs and are just looking for money.
If you truly are looking for people who seek and can create “meaningful work and meaningful relationships”, why do you approach those you’re trying to recruit in such an utterly meaningless, repulsive way?
Why not take the time to actually tell candidates what working at [Company] would look like? Why not take 5 minutes to highlight the specific parts of the person’s background that stood out to you, and that would be especially relevant at [Company]? It would save you time in the log run, and help you find amazing candidates.
It’s not difficult, but it does require you to make a decision about which business you’d like to be in: selling counterfeit Viagra, or representing (favorably) the #1 hedge fund in the world.
I loved N.N. Taleb’s Antifragile, and kept finding echoes of devops (and, naturally, Agile and Lean) throughout the book. I wanted to explore the connections between devops and antifragility in depth, and the result is the following presentation at the first Velocity Conf in NYC.
What do you think?
Free t-shirts are a long-standing tradition at tech conferences. Until this year, Devopsdays NYC, a tech conference that I co-organize, was no exception. At best, attendees wind up with a closet full of free t-shirts they wear with pride; at worst – and more often – these t-shirts end up in a landfill.
While planning this year’s conference, I found that each t-shirt would cost approximately $12 to produce. Given that Devopsdays NYC would have about 200 attendees, the total cost for t-shirts would add up to about $2,500. This particular number reminded me of a donation page on the Lotus Outreach website for their wells project. I quickly found the page, and the symmetry was astounding: “each well costs $2,500 and provides life-saving clean, safe drinking water to approximately 200 rural villagers – at the extraordinary cost of about $12 per person”.
Suddenly, it made sense: by forgoing ephemeral mementos, members of the devops community attending this year’s conference could build a deep-bore water well that would provide life-saving, clean, safe drinking water to approximately 200 rural villagers in Cambodia for years to come! I ran this idea by Patrick Debois (who coined the term “devops”) and others in the group that organizes Devopsdays events around the world, and they were enthusiastic to try this in New York!
At the end of the conference, we donated $12 of each Devopsdays NYC registration to Lotus Outreach, for a total of $2500. My co-organizer Michael Rembetsy and I received an ovation when we described the impact that the attendees will have on life in one Cambodian village with this donation. We are all looking forward to following the progress of the well construction – the devops community will certainly enjoy seeing “Devopsdays NYC” on a plaque near the completed well, and knowing that they’ve made a huge difference in the lives of some of the poorest people on earth.
It is my hope that other tech conferences adopt the same approach, and donate the money they would normally spend on t-shirts to worthwhile causes like Lotus Outreach.
Here’s a video about the Lotus Outreach Wells Program:
[Download The Human Side of Postmortems to your Kindle].
Imagine you had to write a postmortem containing statements like these:
We were unable to resolve the outage as quickly as we would have hoped because our decision making was impacted by extreme stress.
We spent two hours repeatedly applying the fix that worked during the previous outage, only to find out that it made no difference in this one.
We did not communicate openly about an escalating outage that was caused by our botched deployment because we thought we were about to lose our jobs.
While the above scenarios are entirely realistic, it’s hard to find many postmortem write-ups that even hint at these “human factors.” Their absence is, in part, due to the social stigma associated with publicly acknowledging their contribution to outages. And yet, people dealing with outages are clearly subject to physical exhaustion, psychological stress, not to mention impaired reasoning due to a host of cognitive biases.
This report focuses on the effects and mitigation of stress and cognitive biases during outages and postmortems. This “human postmortem” is as important as the technical one, as it enables building more resilient systems and teams, and ultimately reduces the duration and severity of outages.
Here’s a video of me discussing this topic at Surge 2013:
I gave an introductory talk at NYC’s CTO School, titled Practitioner’s Guide to Devops. This post lists some devops-related resources for attendees of that talk, and others who may be interested.
Devops reading list
Devops practitioners on twitter
Devops Cafe (Podcast)
Food Fight Show (Podcast)
Your organization has embraced the Devops philosophy, and is growing. So you set out to hunt for Devops practitioners, and quickly find that usual hiring approaches (e.g., recruiters looking on LinkedIn) simply don’t work.
What do these these mythical Devops creatures look like? (Hint: a lot like unicorns and combs).
What is their natural habitat? (Shockingly, they don’t hang out on LinkedIn).
How can you capture them?
Watch my Devopdays NYC 2013 talk on this subject.
P.S. My thinking on devops hiring was influenced by Elaine Wherry (her posts on the recruiter honeypot and the best recruiters are must-read!) and Chad Dickerson’s blog post on recruiting (especially what he calls “slow recruiting”).