Leading a DevOps Team at a Fortune 100 Company
Accenture's DevOps challenges and how they overcame them can teach us about continuous learning and growth while maintaining quality, flexibility, and speed.
Join the DZone community and get the full member experience.Join For Free
A manager, an evangelist, and a godfather all walk into a bar.
Okay, this isn't a bad joke, this is an article about how managers can implement DevOps in large organizations, especially where culture and organizational change hamper efforts. But, I promise, we will talk about managers, evangelists, and godfathers.
Uldis Karlovs-Karlovskis (@UldisKK) works at Accenture Latvia. Accenture is a global consulting giant, employing 400,000 with teams and clients across the globe. Uldis helped bring DevOps into the organization and shared his journey - the good and the bad - at the Accenture Latvia in his talk entitled, "Lessons in Leading a Fortune 100 Team to a DevOps Philosophy AllDayDevOps conference."
Uldis joined Accenture in 2012 and faced three top challenges:
- How to maintain quality at such growth?
- How to enable continuous learning?
- How to stay fast and flexible at their size?
His team was small, they held daily stand-ups that were productive, and they were flexible. Life seemed good, and then his team grew into a "spider." They still held daily stand-ups, but they were useless because it was just people reporting and no one understood what is going on.
What did Uldis do? Well, he didn't freak out, if that is what you are wondering. Actually, he did. One morning he, "woke up, realized I had 25 people under me, freaked out, and skipped the job for the day." He walked around, thinking about it, and wondering what to do. He thought about his 3 to 4 types of DevOps projects and all of the non-project activities that were monopolizing his time. He realized he focused on the urgent over the important tasks, working 10-12 hours/day.
What is a manager to do? Have people help him, of course. Uldis decides to create an unofficial role that sounds interesting - a subject matter expert (SME). They would work on non-project activities, increase team engagement, improve satisfaction, and asses DevOps maturity in projects. Initially, people were motivated to be SMEs, but they were always busy with other things. So the effort failed.
Uldis had a new idea - instead of him leading the SME team, he will let them decide who wants to do what, they can join the SME team they want, each team can pick a lead SME, set their own goals, how they work, etc. This helped, but still didn't solve the problems. Uldis is still burdened with the tyranny of the urgent.
Back to the drawing board, and a new idea is born - evangelists. Uldis broke down 50 SMEs into 7 sub groups and added a little hierarchy because the flat structure wasn't working. Each evangelist lead a guild - one of seven. Team members were to talk to their evangelist before coming to Uldis with questions.
But, alas, Uldis was still just handling escalations and talks.
So, what do you turn to in order to bring order - bring in godfathers.
Now, team members can always go to the Godfather for help. Uldis decides that, generally, each person has four topics they may want to talk about. For each topic, they have a person to talk to:
- SME addresses how to contribute to the company in general
- Godfather addresses escalations, such as not happy with the team lead
- Evangelist addresses questions about the person's skills
- Team Lead addresses project tasks
Uldis now realizes the benefit of this approach - in a way, now, everyone is focused at some level on sales. As we all know, this is very hard, but important, in any organization, but especially when everyone is an engineer.
While his approach has helped him and his team, he also acknowledges that, "If I did the same thing today, I would fail, but maybe for different issues."
So, he is looking at improving his culture. As we talk about at AllDayDevOps time and time again, good culture is key to successful DevOps. Uldis, looking at Accenture, notes they don't fit into a typical organizational structure. Reading literature, industry buzz, etc., he realized something was missing from these models, but he wasn't sure what. He does know they needed to be better.
He discusses three dominant types or organizational cultures:
- Pathological - 8 hours of work and your job is done
- Bureaucratic - 2-12 hours of work if the process requires it
- Generative - 2 to 12 hours of work and I'll deliver it
Uldis is trying to be at the third approach, and one key to it is if you have a bad day, leave it for tomorrow when you will be more productive. Tomorrow it may take more than 8 hours, but you will put your best into your work.
His journey is ongoing, but he finished his talk covering a few things they do on his team:
- Onboard new joiners through a continuous delivery pipeline
- Meet weekly lunch
- Half-yearly performance assessments
He also provided four takeaways:
- Everyone by default is good
- Intrinsic over extrinsic
- Engagement is your work responsibility
- Let them lead
Uldis told an honest and open story about his journey with the hope it will help others. To hear it first-hand, watch it for free here. You can watch any of the 2017 AllDayDevOps sessions free-of-charge here.
All Day DevOps 2018
The free, online conference goes live on October 17th, offering 100 different practitioner-led sessions, each one 30-minutes long. With 5 separate tracks: CI/CD, Cloud-Native Infrastructure, DevSecOps, Cultural Transformations, & Site Reliability Engineering, and 100 speakers, there's sure to be something for everyone.
And speaking of everyone, if you're part of an organization with 20+ people that want to attend the conference (again, it's free!) then you should consider joining the Club 20 program so that you might get your company logo added to the ADDO site. Check out some of the Club 20 participants here and consider joining them.
Hope to see you online at the show!
Published at DZone with permission of Derek Weeks, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.