I’m a bit of a podcast junkie; it’s essentially my equivalent to television watching in lieu to not having a cable subscription in over eight years (huge waste of time). A podcast that I’ve tuned into recently is the Puppet Labs Podcast. Usually, vendor driven podcasts are pretty lame from a content and editing perspective – I can’t stand podcasts that sound like someone slapped it together over a cellphone call. Puppet Labs has a very polished and well produced and edited podcast, and they also have a short format with quality guests.

The most recent podcasts dive into two topics that are pretty snazzy: Gene Kim’s DevOps Enterprise Summit and Automation with Wizards of the Coast. The episodes are available below:

Contents

Finding and Fostering Change Agents

Gene Kim’s knowledge of DevOps is well known (here’s my review of The Phoenix Project). What I enjoyed most from his discussion with Puppet Labs were takeaways from the previous DevOps Enterprise Summit. The stories that came from change agents presenting on behalf of their various companies is really powerful stuff. The common thread appears to be people who are willing to take a risk and stake their reputation, energy, and career potential on making meaningful change – the very definition of being a change agent. It helps highlight why this change is difficult and slow for most organizations with a reasonable size. Sam Eaton’s post on Change Agents of Ops highlights these challenges in greater detail, in which I’ll echo that “A clear idea of why change is needed, and what it would improve in the business and in the lives of ops team members” has typically been the most difficult at my past employers.

When I worked for a 15,000+ person organization, it was challenging enough just to figure out who the folks in other departments were, much less build relationships with them and earn the trust required to orchestrate change. Often times, these environments are only bridged at the highest levels of management, such as the VPs of IT Support, Applications, and Infrastructure Architecture being the only level where silos communicate to one another (and usually to play blame wars and fight over budget). These levels can be 5-10 layers above someone looking to pivot in a positive away and can seem impossible to do. It takes a heavy investment in figuring out how – and why – your organization does what it does in order to be an effective change agent. When I worked in automotive, for example, I spent months with the Service, Sales, Finance, Back Office, and Body Shop departments before I started designing a new printing system for repair orders, work orders, warranty tickets, and check cutting. Without a deep understanding of their business, I couldn’t have added any meaningful value.

Although I’ve given a number of variations of my Stop Being a Mine Sweeper – inspired by my DevOps journeys from before the term was coined – I’ve begun to borrow a bit from The Machine that Changed the World to use the Japanese term shusa (chief engineer) to represent the embodiment of a change agent. It seems like the perfect term to me. Which reminds me – check out my upcoming presentation in Amsterdam at Tech.Unplugged for this next iteration; I can’t wait to share!

Gene also mentions results from the 2014 State of DevOps Report – a very powerful collection of inputs to couple what we already sort of knew about DevOps practices with hard data. I’m looking forward to reading the 2015 report when it is released. If you haven’t snagged the 2014 copy, it’s worth a read and very well formatted.

The Wizards behind Wizards of the Coast

In the other podcast episode, Miller and McDermott, both at Wizards of the Coast, are pretty clear on their cloud infrastructure requirements and how Puppet Labs fulfilled them, which is the secret to any great design. But I specifically like how they took the time to examine their environment, realize that a change was required, and then get to work on creating a strategy for long term growth. All too often, the knee jerk reaction is to throw tools at a problem and bury it in complexity. Sure, Puppet may have been the right tool for them, but without really digging down into what their cloud infrastructure’s desired state would be, no one would have known for sure.

I’m also happy to hear how much of their environment is comprised of Windows Servers because all too often the configuration management solutions I work with are amazing for Linux or SSH, but largely ignore Windows, WinRM, PowerShell, or other great tools. Like it or not, very few businesses run on a single platform across the board, and it’s never fun to have to divide up configuration state across multiple tools (such as SCCM + Puppet). The Wizards of the Coast team also talk about how they’re pulling value from the integration between the vRealize Suite and Puppet, which is to me a huge piece of the puzzle. Building a private cloud environment is already extremely difficult; if and when I can leverage existing code and modules from vendors working together, I prefer to do so. It allows me to get out of the business of building cloud workflows and into production to start selling (literally or figuratively) my cloud services to tenants.

Thinking Like a Child, Doing What You Love

The final thought in this post comes from a long time favorite podcast of mine: Freakanomics. Stephen Dubner, along with his part time special guest and co-author Steve Levitt, do a wonderful job at breaking down complex ideas into smaller challenges, feelings, thoughts, and cold hard fact. In the Think Like a Child episode, they talk about many things, including how to hire individuals for a job. The story revolves around a magician who is asked to perform for an audience of children and then adults to see which group can figure out the trick quicker (or at all). I won’t spoil the episode, but it’s a good laugh while also being educational. Perhaps my love for SpongeBob and other shenanigans is the reason this topic resonated so well with me, but I do find that the inquisitiveness of children and their (annoying) habit of infinitely chaining the question of “why” after each response is also a helpful way to do root cause analysis in tough troubleshooting scenarios. In fact, Toyota uses it in lean manufacturing to eliminate as many defects from their production and assembly process as possible – it is called 5 Whys.

Later, the topic shifts towards hiring candidates that exude these child like traits. Levitt, the often more calculating and pragmatic of the two, states that he hires almost entirely on passion. The two talk about the fact that people who love something – such as being passionate about a their day job, and are thus not really “working” in a sense – are the people he tries to hire.

It makes sense. If you’re in a position where what you do for money doesn’t feel like work, you’re like going to do a lot more of it than someone who’s watching the clock hands approach five o’clock. I think many of us can relate to this – we read blogs (you’re doing that right now!), listen to podcasts, study documentation, watch training courses, and just generally enjoy technology on a much more vast canvas than what is done for a paycheck each 40 hours a week. And so, the duo argue, hiring on passion means you get greater productivity from an employee, while at the same time the worker is happier, too.

Coming full circle, many of the configuration management tools that make up the people, process, tools mantra actually bring technology work back into the realm of fun. It’s no fun building a bunch of servers by hand, only to revisit them later to fix something. It’s also no fun to install the same application stack over and over again. Declarative state languages, I’d argue, are fun. And based on the State of the DevOps report, being lean and operating under an edge-trust model also give you more “sand in the toes” time (not being at work or on call) coupled with greater job satisfaction, thus increasing your happiness and employment retention rates (not to mention influencing stock prices by way of quick, iterative successes).