DevOps For Managers (with speaker's notes)

As a manager (or manager at heart) you want the best for your company and people, so you’re looking to instill a DevOps culture. Except it isn’t clear what this means, much less how you go about achieving this. This talk explores what it means to have a DevOps culture from a manager’s perspective. It draws on Mark’s experiences with Chef to consider how you might begin or refine the DevOps journey of your company and people. After this talk you’ll have new ideas to ponder and to think about how they can be applied in your situation to create the DevOps culture you want.

Transcript

1. DevOps For Managers* *And Managers at ❤ Get a feel for the room: How many managers? How many ICs (individual contributors)? How many leads (straddle IC and management)? This is take 1 of this talk - there are many possible variations.
2. Who Am I? • Mark Mzyk • Engineering Manager at Chef • Organizer: Triangle DevOps DevOpsDays Raleigh Why listen to me? Engineering Manager for a year at Chef Dev for 4 previous years at Chef, 9 years in the industry total 5 years organizing Triangle DevOps Helped organized and emceed 1st DevOpsDays Raleigh
3. –Vinny, My Cousin Vinny “What is a DevOp?” Lead off talking about DevOps Then present examples of what we do at Chef from a manager’s perspective that fit into DevOps - which is a higher level view of engineering than an IC (individual contributor) might view things
4. Development + Operations = DevOps It’s simple - combine development and operations and you have DevOps, right? Leads to the idea of the DevOps team - this isn’t bad, but it’s not the view I prefer
5. “DevOps is a cultural movement that changes how individuals think about their work, values the diversity of work done, supports intentional processes that accelerate the rate by which businesses realize value, and measures the effect of social and technical change. It is a way of thinking and a way of working that enables individuals and organizations to develop and maintain sustainable work practices. It is a cultural framework for sharing stories and developing empathy, enabling people and teams to practice their crafts in effective and lasting ways.” - Chapter 2, What is Devops?, Effective DevOps It’s not so simple. Definition from Effective DevOps. Also won’t find a spelled out definition in The DevOps Handbook (that I could find on skimming) It’s complicated, it’s culture - and this is why we therefore often focus on the tools Tools are visible and interplay with culture, but they are not culture (Also, vendors can sell tools - I work for one)
6. DevOps is Magic
7. We watch someone else do it We say what we hope is the right incantation If all goes right …
8. We get dragons! (Hopefully not as scary though). Do we even know why we got a dragon? And most of the time, we don’t get a dragon - sometimes it blows up in our face, but often it is just a dud.
9. Blueprint for DevOps Effective Devops and The DevOps Handbook are two books that I think lay out the best blueprint for achieving a learning focused, DevOps culture. Just because they give you a blueprint doesn’t mean you’ll be able to follow it exactly or that it’ll be easy.
10. Learning Culture DevOps is about a learning culture. Achieve that and you will achieve DevOps
11. Context Matters Your company culture is different from Chef’s. What I describe might be helpful, but you’ll have to figure out how it applies to you. What we think of as successful DevOps companies - Netflix, Etsy, etc. They don’t know what works either - but they have a learning culture, keep learning. The world changes, so we all have to keep learning
12. Kaizen - Continuous Improvement Kaikaku - Radical Change Types of Change From Toyota, Lean Thinking Most people have heard of kaizen, less so kaikaku We often hear and think of doing kaizen, but sometimes you need kaikaku Let’s talk about an example of kaikaku at Chef.
13. Conway’s Law Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. http://melconway.com/Home/Conways_Law.html
14. http://www.bonkersworld.net/organizational-charts/ What we typically think of as Conway’s Law
15. Fixed Teams Chef Server Analytics Delivery Example of how teams at Chef used to be - fixed to a product. Chef then tended to create features for each product - whether it was needed or not. Chef shipped a lot of software - but it wasn’t moving the needle on the business.
16. Flexible Teams Chef Server Automate Habitat Kaikaku - Switched to flexible teams (feature teams) Enables us to focus on the products and features that need focus Might have products that aren’t being actively worked for a time Aligned Business and Product - shipped software that clearly was having an impact (Also, product names have shifted/changes as business model evolves)
17. Issues • In a model with rotating teams, how does an engineer build expertise? • Emphasizing product alignment led to deferment to product, loss of some of engineering’s voice Teams rotated often - but that meant engineers sometimes lacked stability, felt they couldn’t go deep in an area before shifting away With the emphasis on feature teams, shipping became focus and emphasis shifted away some from quality, wasn’t clear when or how technical debt should be addressed Also - attrition did happen. Sometimes you have to be okay that people will leave over change.
18. Kaizen • Shift focus from implementing a feature to achieving an outcome • Let teams live longer These are kaizen steps currently in progress Teams focus on an outcome (Automate Adoption) instead of a feature (GitHub integration) Team can integrate in the problem space until a sufficient solution is found Let the teams live longer, but still be willing to switch up things when a team isn’t working or someone needs a change Do not intent to go back to fixed teams
19. Embrace Variability a.k.a Learn to Live with Ambiguity Your world won’t stay the same - so you have to learn how to live with variability and ambiguity This will vary based on your circumstances - startups will tend toward more variability, enterprises less so (most of the time)
20. – Rands (Michael Lopp) “Process is documentation of culture and values.” From: http://randsinrepose.com/archives/the-process-myth/ At some point you’ll realize you’ll need process Process helps control variability Aside: We dislike process when we’ve lost sight of the value it was put in place for If you can’t remember the why for a process, remove it or change it
21. No Process Clearly Defined Process This is the path it will probably take to find the right process. Don’t be afraid to change. Everyone lives in a different comfort zone - Some people operate easily with no process and find a way forward. Others need a clearly defined process to feel comfortable. Learn where your peers and reports live. If you are at one extreme, know the other might be your blind spot. How can you leverage your peers who are in a different place so you end up in a good place as an organization?
22. Define your processes like dirt paths - see what works, try out different things, change while they are easy - let them wind a bit. Only when they have been successful for a while should you path them and make then more solid Picture Credits: “Path” by Tim Green https://flic.kr/p/6TM1w4 https://creativecommons.org/licenses/by/2.0/ No changes made “Path” by Allen Watkin https://flic.kr/p/4bmtAD https://creativecommons.org/licenses/by-sa/2.0/ No changes made
23. Where to ask for help? This is a story of winding process at Chef When a customer facing person needs help from engineering where do they ask? Observed that they often asked for help in engineering channels, but might go unanswered or sit for a while. What if they needed immediate help? Set up #eng-escalations channel for immediate help during business hours. Engineering managers and principal engineers watch room for any activity, mount immediate response For after hours, have a define pager duty escalation to page an engineering manager - this was easier to put in place than the #eng-escalations channel, because we had experience here
24. HBR Article - https://hbr.org/1991/05/teaching-smart-people-how-to-learn To achieve a learning and DevOps culture you will have to combat this In both yourself and those you manage and work with We’re all smart - single-loop learning (problem solving) comes easy to us Double-loop learning (reflection on ourselves) is hard Read this article - at least twice. Read it once, reflect on it, then come back and read it again days later.
25. Make Failure Safe If your people are afraid to fail, your org won’t learn, it won’t improve. The only way to avoid failure is keep the status quo - but this will result in the long term failure of the business as it doesn’t respond to the change around it. Without this, nothing else in this presentation will matter.
26. Google’s research into what makes a good team: #1 item - Psychological safety Without that, nothing else matters. It underpins all else. If you don’t have safety, you don’t speak up, you lose trust https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/
27. It takes many actions to build trust, but only one lie to destroy it. We know this to be true. This is why establishing safety is so hard - it’s a continual task. This is the challenge of being a manager and establishing a DevOps culture. Your words and actions are endlessly interpreted by everyone around you - and they don’t have the same context you do.
28. Your Actions Establish or Destroy Safety Bottom line. How you approach the world sets this up.
29. Blameless Post Mortem One way to establish safety is blameless post mortem Recognize we operate in a system and assume positive intent - everyone does the best they can with the information they have - so where did the system fail and how do we improve? This is a screenshot of the Chef post mortem template John Allspaw as spoken and written at length on blameless post mortem https://codeascraft.com/2012/05/22/blameless-postmortems/
30. Small Actions Matter • One on Ones • How you respond to requests • How you treat outcomes on your team These are where a true learning culture is built. Most of these will be seen by one person, or only a few people, but it shapes their perceptions of what you think is important - and if they have safety It is an ongoing conversation that evolves over time. Tell the Engineer and Elm story if there is time - unexpected request, but meet halfway, explored it
31. Context Matters This was my context - now how can these lessons apply to your context?
32. Thank You Keep the conversation going, through conversation we learn and grow. Twitter: @mzyk83 Email: mm@chef.io Slacks: @mm is hiring Some Slacks I hang out in: Triangle Devs, Rand’s Leadership, Chef’s Community, eng-managers, DevOpsDays organizer’s