Learning to Speak DevOps With Stakeholders

When I left my position at Thomson Reuters in late 2012, a colleague gave me a gift.  It was a page cut from a Robert Frost book of works with a raven drawn over it.  Frost is one of my favorite American writers/poets and I have a strong tie to the raven (I even have a sick raven tattooed on myself).  This colleague was clearly a deep listener and really took the time to learn things beyond the superficial about me and made me feel special.  I learned that the art came from a merchant on the Etsy marketplace, which was only 7 years old at that time.

Ironically, the move from Thomson Reuters to Elsevier that the gift celebrated, was one I made to deepen my love for lean and agile.

At the time, I knew nothing about Etsy other than they made available some amazing art.  Since digging into my career more, I have learned about the amazing inter-workings and deployment pipelines that Etsy have curated over the years.  Leveraging private cloud and sound DevOps practices, they have created deployment streams that make most enterprise level shops weep with envy.  In 2014 it was reported Etsy deployed to production as many as 50 times a day.

But it wasn’t always that way.  You don’t always build a deployment chain like that from day one, and they too felt the pains of manual releases, and the associated integration/regression issues with other tightly coupled systems.

“Deploys were often very painful. We had a traditional mindset of, developers write the code and ops deploys it. And that doesn’t really scale.”

The beauty of Etsy was the intentional step to assess the operational culture, process and tooling that enabled poor deployment practices.  Etsy realized that they were only winning some of the business they targeted, and the technology that enabled the business was also the major system constraint and risk to scaling.

To win in business, you require the ability to sense market problems and respond with valuable technical solutions.  Both disruptive innovation and sustainable growth are underpinned with the ability to deploy software nimbly, and with high confidence.  It is important for the business team to understand the critical importance of DevOps, the mindset and to prepare for the speed that is acquired when teams adopt this culture.  Assertive organizations like Etsy realized this and have capitalized on it to continue to grow.

As technologists humans, we are almost hard-wired to talk about solutions.  I can share the publicly known details of the Etsy leveraged tools, but that only feeds the solution-based thinking.  What companies like Etsy do prior to retooling the deployment pipeline is the leading indicator of transformational success and sustainable flow.

All technological change starts with people.

Getting people to understand what better outcomes exist and how these outcomes benefit them, the organization, and the user base is a critical first step in meaningful transformation.  But is typically overlooked by most organizations. Whiskey tango foxtrot.

DevOps is not a set of tools.  It is the intersection of people, process and tools that align with leadership, culture and strategy (LCS).  People need to have the purpose in their environment to align with the LCS from which process and tooling should emerge.  The only way to ensure this alignment is to speak to people in a shared language; said differently, we do lead discussions with our business partners and stakeholders centered on tooling.

It is lazy.  It is short sighted.  It is a shell game.

Learn the intrinsic motivators of the stakeholders, the fears, and the real root problems they face.  Align these items with the strategy (wait, you do have a strategy, right?) to mitigate concerns.  Then cast the message of how DevOps is an enabler of “better” and partner with them on this journey.

DevOps extends well beyond the traditional IT/Engineering silos.  A simple example of this point is the speed of data driven feedback we acquire when we implement analytics, instrumented code, A/B testing harnesses, etc.  To assume our partners in product and marketing are equipped to handle all this new input and respond with better prioritization and strategy is foolish.  This extends to product operations if we increase user registration/billing, sales as we experiment with new features, procurement as we adopt infrastructure as code, and HR as we shift the core values of our product delivery staff.  And these are just top of mind examples.

The days of locally optimizing software practices are either nearly or totally over.  Transparent and honest organizations are emerging as the ones enabling faster growth in market.  This is only achieved with a first mover to shepherd the conversation, and I call on all my change agent friends to be the beacon of delivery calibration.

I recently sketched this model as a tool for myself when speaking to the business about DevOps, perhaps it is useful for others:

R – Research the business to understand the problems they have with current models
E – Empathize with the constraints and lack of technical insights they may have
A – Ask them to partner with you on charting better outcomes
C – Calibrate goals and achievements (leverage OKRs)
H – Harmonize practices and tooling to enable the goals and achievements

Thanks to Hibri Marzook for pointing out the intended loop of the model

As I left my time with Thomson Reuters, I kept that art with me in my various offices and work stations till it got lost in a move.  I loved it as a sign of appreciation from a coworker, but also as a symbol of the shared respect I formed with a Product Manager while working in a technical role.  I find the serendipitous humor in that it lead to this post asking for better efforts from my technical peers to continue with that same torch.