The Five Love Languages of DevOps
A presentation at Chicago Code Camp 2015 in in Chicago, IL, USA by Matt Stratton
THE FIVE LOVE LANGUAGES OF DEVOPS
WHOAMI
WHAT IS THIS DEVOPS THING ANYWAY?
"A cultural and professional movement, focused on how we build and operate high velocity organizations, born from the experiences of its practitioners." -- Chef Style DevOps 1 1 https://youtu.be/_DEToXsgrPc
Words of Affirmation Acts of Service Receiving Gifts Quality Time Physical Touch THE FIVE LOVE LANGUAGES
We talk a lot about empathy in DevOps. The Five Love Languages is basically about being empathetic. But we need to talk about HOW you do these things, rather than just say "MAKE WITH THE EMPATHY" WHAT DOES THIS HAVE TO DO WITH SHIPPING SOFTWARE?
After the first US based Devopsdays in Mountainview 2010 Damon Edwards and John Willis coined the acronym CAMS, which stands for Culture, Automation, Measurement and Sharing. Jez Humble later added an L, standing for Lean, to form CALMS. There are several different models/definitions of DevOps, but for purposes of this discussion, Iʼm going to use CALMS to specify different focus areas on what DevOps can be. CALMS
A lot of people say that culture doesnʼt matter. J. Paul Reed has talked about that itʼs not important to change your culture, but mostly to ensure that your culture is consistent. Culture also has to do with the personality of your organization. You may be an organization that is based on consensus, etc, like we all need to make sure everyone agrees and lets have meetings about meetings and meetings. CULTURE
Add mention of incenting employees; use Etsy example. You incent for the behavior that you want and then that behavior drives culture which drives further behavior. You can’t directly change culture. But you can change behavior, and behavior becomes culture — Lloyd Taylor, VP Infrastructure, Ngmoco
Stuff like chef, puppet, automated release, automated testing. Manual steps when not needed are a problem. AUTOMATION
In general, a software process should be automated up to the point where it needs specific human direction or decision making. “Asking experts to do boring and repetitive, and yet technica ! y demanding tasks is the most certain way of ensuring human error, short of sl " p deprivation, or inebriation.” — Continuous Delivery , Jez Humble and David Farley
Lean Thinking is a business methodology which aims to provide a new way to think about how to organize human activities to deliver more benefits to society and value to individuals while eliminating waste. The term Lean Thinking was coined by James P. Womack and Daniel T. Jones to capture the essence of their in-depth study of Toyotaʼs fabled Toyota Production System. Lean thinking is a new way of thinking any activity and seeing the waste inadvertently generated by the way the process is organized Sometimes people say the "L" stands for Learning (for example, Jason Hand). That's okay. We can still be friends. But for purposes of my talk, it's "Lean" LEAN THINKING
How do we know if we have been successful if we donʼt collect metrics? Measuring is important to start during a transition as well – you canʼt go back in time and collect information you didnʼt know you wanted at the time. Setting success criteria is very key at the beginning of any transition. MEASUREMENT
Transparency is key. No “Brents”. First, donʼt keep info to yourself to protect yourself. Also, share as much of the “why” – no mandates. Finally, goes to a culture of trust. Blameless postmortems cannot happen in a culture without sharing. SHARING
What does this have to do with anything? WUT?
EACH OF THESE IS A “DEVOPS LOVE LANGUAGE”
Itʼs more important for me to learn to talk to them than for them to learn how to listen to me. If you find yourself thinking "this is crystal clear to me, why aren’t they s ! ing it?," that’s more about you than it is about them. — –Bill Joy, Arrested DevOps Episode 33
Patrick Debois has said (jokingly) that we should rename DevOps to “common sense”. The problem is, common sense is a relative term. IT'S NOT ENOUGH TO GET SOMEONE TO DO IT, THEY NEED TO SEE THE VALUE IN THEIR OWN LANGUAGE
DiSC is kind of like Meyers Briggs. I like to use DiSC because itʼs easier to make a quick assessment (you could be wrong). DISC ▸ Dominant/Direct ▸ Influencing ▸ Steadiness ▸ Conscientious
Someone focused on direct is most likely going to respond to Lean and Measurement. They are results-driven. They want to see how the change helps move the ball forward and are also more likely to be influenced by experimentation. Preaching culture or automation wonʼt necessarily resonate with them – they care less about the “how” DIRECT LEAN/MEASUREMENT
Influencing types will respond to culture and sharing. They like consensus and they like to collaborate. The results-oriented portions (especially the automation) wonʼt make as much of a difference to them. INFLUENCING CULTURE/SHARING
Steadniness like stability. They want to be sure about change and to be comfortable with it. Automation helps them feel safe, and measurement assists in understanding that things really didnʼt get messed up. Lean can make an S feel uncomfortable. STEADINESS AUTOMATION/MEASUREMENT
Conscientious folks will respond to sharing and measurement. They love data. They want to measure 30 times and cut once. Lean might scare them. Culture is less of an impact. Automation CONSCIENTIOUS SHARING/MEASUREMENT
Often times we have conflicting incentives. Dev incented to ship features quickly. Ops incented for uptime (nancy example). These may actually not be at odds. Ultimately our driver should be to move the biz forward, at a macro level, but we have our individual incentives. Changing these isnʼt always right. Understanding what appears to be a conflict may actually help. Ship changes at a higher velocity can actually increase the stability of a system b/c small batch changes are more stable. Ship more frequently actually helps both dev and ops. Similarly, caring out uptime and stability can enable the dev to ship more features as they are not caught up in troubleshooting and have more resources available from ops, etc. Drive: The Surprising Truth About What Motivates Use - Daniel H. Pink ASSESS THE DRIVERS
Talk about the Challenger Sale. “(Challengers have) a deep understanding of the customerʼs business and use that understanding to push the customerʼs thinking and teach them something new about how their company can compete more effectively.” If youʼre not comfortable with being a salesperson, find a buddy who is. BE A SALESPERSON
The key is to look at your key influencer as your client instead of your boss for the purpose of this project. If your client (who happens to be your boss) shoots down your ideas and offers a counter plan, you have to be ready to channel some boldness and stand firm in your beliefs. Instead of arguing back and forth or worse, completely backing down because of his/her position above you in the company, you could say something like “I see what youʼre saying, but if we do it your way, this is what is going to happen”, and then lay out how their plan is flawed. TALK THEIR LANGUAGE
The Compliant One: The compliant person will sign the documents, put their time in, “do their TPS Reports, punch the clock. Theyʼll do it because they need a job, or are too lazy to leave. Whatever the reason, theyʼll make the changes, but wonʼt really care much about it. The Committed One: The commitment person will simply, “Believe in the TPS Reports”. Theyʼre dedicated to the idea of change and are committed to the success of the company. As you have more commitment, the success of your company will be exponential. COMPLIANCE VS. COMMITMENT
theyʼre authentically interested in them, and enjoy the pursuit of the how of change more than the change itself. THE BEST CHANGE INFLUENCERS ARE THOSE WHO DON’T SEE PEOPLE AS SOMETHING THEY ‘HAVE TO DEAL WITH’.
Don't dictate; let the influencers and stakeholder take an active part in the change Donʼt let it just be a venting session – we can all talk about how we got where we are, but this is about moving the needle forward. BRING PEOPLE ALONG FOR THE RIDE
QUESTIONS?
MORE STUFF ▸ http://arresteddevops.com/devops-culture-change/ ▸ https://github.com/chef/devops-kungfu ▸ @mattstratton on the twitters ▸ https://github.com/mattstratton on the githubs ▸ http://www.ted.com/talks/dan pink on_motivation
The title of this session is inspired by the self-help book The Five Love Languages by Gary Chapman, but the similarities end there. When we are working to bring about cultural change in our organization, it’s essential for us to understand that not everyone speaks the same “language” of DevOps as we do. The CFO has different drivers and communication style than your friend in the QA department, who is still different than the DBA in that remote office. In this talk, I will work to help provide techniques and strategies for identifying the drivers of your peers and decision-makers. We will talk about beliefs, perceptions, and communication styles, all with the express intent of helping YOU drive home the value of the DevOps philosophies and work-practices to make your organization succeed!
Content will include a discussion of the DiSC model, as well as discerning drivers for different individuals to adjust the conversation.
The DiSC model provides a common language that people can use to better understand themselves and to adapt their behaviors with others. The four areas of DiSC are Dominance, Influence, Steadiness, and Conscientiousness.
Approximately 25% of the talk will be background on DiSC and methods for identifying the communication styles of others. 25% will be based upon identifying drivers of example roles in an organization (finance, product, tech ops, etc), and the remaining will be focused on use cases and strategies for applying this skill towards organizational change.
Buzz and feedback
Here’s what was said about this presentation on social media.
