Podcast Episode 109 – Why Developer and Ops Advocacy Fails and How to Use Empathy to Save It with Patrick Hubbard

Patrick Hubbard is the Principal Head Geek at SolarWinds, but more importantly, he’s someone who has great lessons in how to communicate in a world where tech teams seem to be on a different page.  This great conversation will be exciting for anyone who’s involved in developer advocacy, ops advocacy, or any cross-team work.  We cover how to communicate, how to create meaningful content, and meaningful relationships through the power of people and technology.

This chat explores DevOps challenges and also will be a super fun listen for anyone in tech as we talk about the history of how we got here and Patrick’s very broad background that led him to be where he is today.  I’ve long been a student and a fan of Patrick so this was a particular pleasure to share a microphone with him for this episode.

Listen to the episode here: https://discopossepodcast.com/episode-109-why-developer-and-ops-advocacy-fails-and-how-to-use-empathy-to-save-it-with-patrick-hubbard/ 

Listen and Subscribe on iTunes here:

Podcast Episode 109 – Why Developer and Ops Advocacy Fails and How to Use Empathy to Save It with Patrick Hubbard

PODCAST LINK: https://discopossepodcast.com/episode-109-why-developer-and-ops-advocacy-fails-and-how-to-use-empathy-to-save-it-with-patrick-hubbard/




Free Download – DevOps Automation with Terraform and VMware

Content planning for 2020 is underway and I realized that it’s a good time to share the recent O’Reilly report that I had done in 2019 here with folks.  DevOps may seem a long way off, but the methods of automating your infrastructure creation in order to enable better DevOps practices is not.  Even VMware environments are seeing the benefits of automation whether it’s DevOps as the ultimate goal or not.

My O’Reilly book DevOps Automation with Terraform and VMware is like the culmination of all my loves.  It’s about simplifying with automation, using Terraform to easily provision infrastructure, and it is a based in a VMware environment which I had a lot of requests about.  As a long-time VMware vExpert and lover of the VMware ecosystem, this was really fun to make.

You can download the book by clicking the link here to go to where it’s hosted at the Turbonomic website, or by clicking the image of the cover below.  I hope that you enjoy the book and find it helpful. It’s just a small step in your automation journey, but in just under 26 pages, you’ll hopefully find some gems that get you to love Terraform and automation as much as I do!




Podcast Episode 78 – DevOps-as-a-Service and Evolving Ourselves with David R Shaw (@Shawzer)

David R. Shaw is the co-founder of White Label Software (https://whitelabel.software) and someone who brings passion for business, community, and personal growth to any conversation. We discuss how David’s personal history led him to where he is today and the things that make successful teams and technologists based on his experiences in the industry. We explore what could be best called DevOps-as-a-Service which is the way to accelerate adoption of new practices with the help of outside expertise and much more.

Listen to the episode here: http://podcast.discoposse.com/e/ep-78-devops-as-a-service-and-evolving-ourselves-with-david-r-shaw-shawzer/

Listen and Subscribe on iTunes here:

Podcast Episode 78 – DevOps-as-a-Service and Evolving Ourselves with David R Shaw (@Shawzer)

PODCAST LINK: http://podcast.discoposse.com/e/ep-78-devops-as-a-service-and-evolving-ourselves-with-david-r-shaw-shawzer/




Blameless Culture: The Path to Agility in IT

You’ve inevitably heard the word blameless used in the context of technology and tech culture.  The foundation of DevOps and agile and many other methodologies is around blameless post-mortems.  Retrospective meetings and recaps that allow for trust and honesty when discussing what went wrong and what went well.

Here’s the issue:  being blameless is really difficult.  Like, really, really difficult.

Battling Human Nature

Blameless meetings in many organizations are more like “don’t blame me” meetings which erodes the very foundation of what blameless culture is all about.  A societal challenge is getting past the “Not it!!” mentality and embracing the issues without seeking a person to pin it on who isn’t ourselves.  People often mistake not taking responsibility with being blameless.  Just because you don’t assign blame, constantly un-assigning yourself from it is not a blameless approach.

It’s not easy to admit we made mistakes.  Trust me…

A Personal Story:  “Wait, that was production?!”

It was 9:30 AM on a Tuesday.  Two Active Directory administration windows open, one for production, and one for the test domain with the identical OU structure (to look just like production).  As I clicked the option to upgrade the Active Directory version to Windows 2000 native mode and proudly clicked the Change Mode button (clearly stating “this operation cannot be reversed”) and the following acknowledgement that it was irreversible, I sat back in the chair and smiled…for a moment.

Then I checked the other window to what I thought was production…and saw the domain version was mixed mode (legacy).  But then I also noticed the domain name was the test domain.  I had updated production in the middle of business hours during the potentially busiest login period of the day.

I stood up and took a lap around the cubicle. Once I stepped back in and confirmed it had happened, I called my systems architect who worked with me.  “James, I made a mistake.  I just updated production instead of test.”

James calmly said “Ok.  Let’s get some folks looking at it and figure out if anything happened and what our options are if something broke”.  James understood blameless culture.  We survived the change (without issue, luckily) and I learned that rallying the team around an issue was better than seeking blame.  We would work together on other issues that did have far reaching effect at other times, and the blameless culture and teamwork got us through those events.

Hire the Person that Made a Big Mistake – They Won’t Want to Make Another One

Making mistakes and learning to change process and recovery procedures meant building better IT.  As a systems architect and operations team member, our culture grew stronger under blameless acceptance of issues.  I also witnessed the very negative results of not using this tactic.  A manager at one time told me that even though we had a large, preventable situation occur from human error, we don’t remove the person.  We teach them to not have it occur again.  If you make the same mistakes again…and again, well, there isn’t a blameless team around who will not take notice and perhaps have to make some changes in your role.

Test-driven development and test-driven infrastructure are wrapped around the foundations of finding the error first and then working back from there.  Seek a problem and then find resolution.  The same goes for teamwork and production deployments.  To move faster, you have to be confident that you are testing and also able to work together as a team without fear of retribution when issues occur.  Some issues are avoidable, and some are not.  Be blameless before you find the solution and then when you find the cause, accept that it happens…but should happen less.  The real leaders then ask “how can we do it better next time?”

Leadership Defined:  We Succeed; I Fail

Acknowledging failure or just challenges is healthy,  Celebrating success as a team is also extremely positive.  My way of encapsulating what it means to be a leader of people in a team goal is “We succeed; I fail”.  In other words, celebrate successes as a team, because we all did this together.  When looking for where we may not have succeeded, look into yourself for what you feel could have been done better.  There may be others involved in the tactical things that went wrong.  The best outcome is a learning experience for everyone throughout the team.

Even when things go well, we should always ask how it could have gone better, or what would you do differently?  This is the beginning of embracing a culture of experimentation.  You have to know that things can fail and we can recover, without blame.