DevOps: How to empower your team

Set a challenging mission, let the team define the stages of the journey and control the outcome. But only trust and empowerment make it happen.

The way a young colleague started in my company reminded me of how teams start in a DevOps transformation. Here I will share Peter’s story and explain the approach we take in the DevOps journey.

Define the Mission, Challenges, and Framework for Support 

We hired a new consultant in my DevOps team. Peter came from a business school in the Netherlands and he was really smart. Our customers and team members responded well to him. With our new hires, we have a process to set them up for success.

RoboyUp.jpg

First we sat together and spoke about his aspirations. We put together a mission for his journey in our company: challenging but attainable. My ultimate goal was to slowly empower Peter. In our team, consultants need to act independently to make their own decisions which let us move faster. 

We give them confidence as we acknowledge their skills. We show them our trust by making them responsible for their own journey. And we support them by being their mentor on their journey in which they are the hero.  

Peter’s first project came in the form of a DevOps transformation in Baltimore. The team was known as critical and difficult to deal with. The team lead was a guy who blocks changes. The human aspect was challenging, yet the actual transformation risk was low: we had enough time and the team was small.

Peter began by defining the team’s mission and developing a framework for its transformation. The mission was concretely stated in one sentences with measurable facts:

Mission Statement: Be the fastest way to deliver IT changes (at least once per week) to make the experience of our shopping application so joyful that we increase our average feedback from users to 4.5 stars until December 2020.

Now that the team in Baltimore was set up for success, it was time to look at how to gradually build up their responsibility through measurable stages. 

Small Achievable Steps with a Clearly Defined Measurement of Success

How could Peter progress towards his own goals? The same way as his team: going step by step with support. In our meetings I zeroed in on his desire for personal development and we spoke about areas where he thinks he can improve. He told me that a big issue for him was that he gets intimidated and insecure when teams push back strongly in discussions. So I asked him, “Peter, what do you need from me or our team to better deal with this?”

“To better handle the push backs,” Peter told me “I would need one hour of your time each week to discuss the status and get your guidance.” This was exactly what I wanted to hear. I went ahead and scheduled those meetings which gave him the responsibility, but allowed me to stay close. 

Just as Peter was moving through the stages of his own professional story, Peter and the team defined the interim stages for the DevOps journey like chapters of a book. Then they filled these chapters in with capabilities and sorted them into a list. Each item brought them one step closer to their mission statement. The team also clearly defined what support they would need to accomplish the steps. The journey for the team was looking like the following:

teamtransformation.PNG

To motivate the teams, and for our own reporting, we track the adoption and the maturity of DevOps for all the teams in our company. We make this ranking transparent together with the KPIs. This leads to competition between the teams which accelerates the transformation. 

Empowerment Means Stepping Back so that the Team Can Step Up

Peter had identified his own goals, he had taken supported steps and he started to have success. Now it was time for him to be fully empowered. 

Before the kick-off meeting in Baltimore, I called Peter and told him that I knew that he would be able to handle the transformation on his own. “I know, you will do a great job. And remember, you are not alone on your journey.” I could hear Peter questioning, doubting himself and holding back. I listened to his concerns and expressed my trust in his abilities. And I really had this trust in Peter, it wasn’t a glib statement. He knew all facts about a transformation and had a framework of support: our team at his back, and the guide rails of the structure for each step.  

The team in Baltimore followed a similar path. The team had determined their mission statement. Then they had defined the order of the steps in their journey, what kind of time and support they needed. And this is crucial: the team took each step at their own pace. You quickly feel overwhelmed when the pace is too high, when you rush from one new topic into the next without enough practice. It's a learning process for the team. The right tool is sometimes available in minutes - we could just install it. But the challenge was to learn to use this tool and to increase the performance. This might take weeks or months, but the result will be honest and sustainable and not built up on false assumptions. 

Peter had empowered the team in Baltimore based on three principles:

  1. Show them confidence: We appreciated the knowledge of the team, we asked them for guidance: The team tailored the standard approach to their needs.

  2. Peter gave them his trust, they are responsible for reaching the defined goals in the time they need.

  3. Peter supported them as a mentor or as their sidekick, they are the hero and have to write their own heroic epic.

The epic is challenging, each single step appears easy when you have a team lifting you up

Baltimore was the first chapter of the heroic epic Peter was writing in our company.

After the successful transformation, Peter shared his learnings with other consultants from our transformation team. He had not only learned how to lead a DevOps transformation, he had also learned how to be more confident. 

After the retrospective Peter told me that what had helped him the most was my trust in him. And I think this is also the essence of a DevOps transformation. The team has to step up and the transformation team has to empower and trust them. By stepping back and allowing the team to unfold themselves, amazing things can happen. 

Previous
Previous

Structure, Structure, Structure or three options to order your DevOps story

Next
Next

Storytelling is in our DNA