What is DevOps Coaching? The Art, Science, and Culture Of Engineering Enablement

Software engineering may be difficult, but fostering a working environment that enables skilled engineers to perform their best can sometimes seem downright impossible. Every day, many engineering teams are battling a messy whirlwind of forces like unmovable deadlines, impostor syndrome, psychological safety issues, personnel/leadership conflicts, fierce technological preferences, and more. With teams more distributed all over the world than ever before, cultural differences can exacerbate many of these difficulties.

As a software engineering coach, my job is to not only introduce new technology to software teams currently looking to transition to DevOps, but to strengthen their working relationships within their organization. Coaches aren’t simply technical instructors. Rather, they are change agents that guide a team towards better outcomes for their project as well as their interactions with one another.

In this presentation, I will discuss tips, tricks, and techniques that technical leaders and managers alike can utilize to better coach engineering teams, including concepts like the definition of empathy (and, more importantly, what doesn't count), the trust-influence relationship model, introducing new technologies in a meaningful and consumable way, and a 5-step process to provide teams confidence to own their new DevOps solutions moving forward.

Transcript

1. What is DevOps Coaching? The Art, Science, and Culture Of Engineering Enablement
2. Hello! Michael Migliacio マイケル　ミグラシオ Software Engineering Coach 　
3. 井の中の蛙大海を知らず A frog in a well does not know the great sea... 1
4. THE ENGINEER MINDSET It’s more complex than you think... 2
5. Engineers Engineers generally want to do their best work. That work consists of solving business and engineering problems that are extremely complex. DevOps fuses engineering, testing, and operations acumen.
6. Challenges • Deadlines without business context • Scope creep • Conflict within team, lack of psychological safety • Imposter Syndrome and the Dunning-Kruger effect (“the more knowledge you possess, the more you realize you are actually lacking”)
7. What is a Coach? 1. A technology advocate. 2. A leadership whisperer. 3. A stakeholder in the team’s success. 4. A change agent. 5. A counselor. 6. All of the above.
8. Most importantly... An agent for change!
9. CHANGE AND EMPATHY Understanding is one of the greatest tools in a coach’s toolbox. 3
10. Change • Is DevOps in a nutshell. • Is not rational, but emotional. • Is scary (inertia is preferable). • Happens when the fear of change is less than the fear of remaining the same. • Is cross-cultural.
11. What Sparks Change? • No one wants to take the first step. • “It’s not me that needs to change, it’s <someone else, something else, leadership, technology, etc...>” • Coaches must change how they interact with teams to promote change organically.
12. What is Empathy? 1. Not pity. 2. Not sympathy. 3. Not understanding (at least not on its own). 4. “I feel what you feel.”
13. Empathy • Vital to the role of a coach. • People will respond to suggestions and advice if they like and trust the advisor. • To do this, coaches have to put themselves in their team’s shoes and understand their pain points.
14. THE TRUST - INFLUENCE LOOP Building trust and influence one step at a time. 4
15. The Trust-Influence Loop • Made famous by Mike Cottmeyer • https://www.leadingagile.com/podcast/trust-influence-l oop-mike-cottmeyer/
16. Influence • Begins with access to the team. • Influence grows through feeling understanding the team’s pain .points. “I see your point of view. I hear you.” • Ultimately results in a feeling of kinship, camaraderie, and safety.
17. Trust • Only once safety is established in a team can a change agent take action. • Reality check. ‘Are we doing what we set out to do?’ • Competence. ‘Let’s do the task.’ • Results. ‘How did it go?’
18. PROBLEM OWNERSHIP IN 5 STEPS How to coach a team through a technical problem 5
19. Technical Ownership • DevOps Coaching is often squishy. • Sometimes technologies and solutions are decided by an enterprise, other times teams can choose themselves. • Part of coaching is empowering teams to own their decisions.
20. Step 1 • Demonstrate Empathy • “Learning how to set up a .drone.yml file as part of a CI/CD pipeline is a drag. I feel your pain because I’ve been there myself.”
21. Step 2 • Hand the Problem Back • “What do you think you’re going to do?” • “How are you going to handle that error case?” • “What have you tried so far?”
22. Step 3 • Ask For Permission and Give Suggestions • “Would you like some choices as to how to solve this problem?” • Meaning is not the same as “How can I solve this problem for you?”
23. Step 4 • Let Them Make Their Choice • Do the team the honor of assuming they can figure it out. • The team owns their choice through the knowledge gathering they’ve done and the fix they’ve created.
24. Step 5 • Wish Them Luck • Maintain a positive attitude. • Follow up with the team on their solution afterwards.
25. ◇ Every question is a good question. ◇ Follow @AngstyGaijin on Twitter if you want to know more. 6 QUESTIONS