Leadership, Mentoring and Team Chemistry, the Soft Skills needed for DevOps

When I wrote that as a profession we’ve only scratched the surface of applying the ideas from DevOps and that we’ve been focused on the tools side of things I had thoughts in mind on how to address the points I raised.

One is the importance of mentoring and leadership as part of creating successful teams. During my career as a fire fighter I was lucky enough to learn these points by example from some amazing people. These ideas were not just part of our culture, they were expected and they’re what I want to share with you.

Any team requires both members and leaders. Nothing earth shattering there. But when you have a culture of mentoring and solid leadership that mix of people can grow into a successful team existing as long as you can keep them.

Our field is ever changing and a chaotic environment and that’s what draws some of us to to. It requires attention to what is going on and it gives each of us opportunities to learn something new or revisit old ideas again.

OK quick side note… while writing this autocorrect changed revisit to resist. Not sure if my text editor was trying to tell me something.

What we cannot have is that same pace of change and chaos reflected in the teams themselves. The leaders in each team who step-up to take on different roles need to provide stability. They include the official (tech leads, managers, and directors) and the unofficial ( experienced engineers who’ve earned the respect of their peers).

As a leader you become responsible for your team. Their needs, problems, and failures become yours, but just remember that their successes are their own. It means that you will need to be a good listener while also providing honest and direct feedback. You will need to provide a calm and positive outlook on the work at hand no matter what difficult challenges you are facing. Your job becomes not keeping the system, site or service up, it becomes keeping your team up.

The other important role a leader performs is clearly communicating to everyone the current situation, the challenges ahead and the goals for not only the team, but for the entire organization. If you have a team of capable people and have this type of clear and transparent communication going in both directions they should be able to prevail against almost any problem they face.

One of the best descriptions I’ve seen of what this looks like was from Gene Kranz.

“There, we learn the difference between the ‘I’ and the ‘we’ component of the team, because when the time comes, we need our people to step forward, take the lead, make their contribution, and then when they’re through, return to the role as a member of the team.” Kranz then went on to explain the “chemistry” aspect of a team: “it amplifies the individual’s talents as well as the team’s talent. Chemistry leads to communication that is virtually intuitive, because we must know when the person next to us needs help, a few more seconds to come up with an answer.”

— Apollo 13 Flight Director Gene Kranz speaking at the National Air and Space Museum on April 8 2005

The fact that this type of chemistry has to be cultivated over time is really an completely separate subject. But the short of it is you can’t have a team that performs at that level without having them do the work, responding to outages, and training together. That last bit is something that’s sorely missed in many operations teams.

One way to help encourage this type of dynamic and to continue to pass down the institutional memory from one generation to the next is by making mentoring a key part of your teams.

This includes both mentoring new members who join, but also existing people who have stepped up into more senior or different roles. Once you’re no longer the new person doesn’t mean that you shouldn’t be the mentoree anymore.

There is already a bit of inertia that you will be fighting against that actually discourages all of this. As a profession we tend to stay in our perspective technology silos without stepping outside to see how other tools and languages have approached similar problems. We end up disregarding the results of other smart people who already addressed what we’re working on.

Then we have ageism continuing to bleed out knowledge from some of our peers who just happen to have years of experience. Think of the idea that everything comes back again or ideas are cyclical.

You could reason that old ideas come back around, because the technology we have has either been improved or created to the point that they are now practical. I’ve learned to think of this not as a circle, but that we’re looking at it down along it’s axis. It’s more of a spiral moving linearly into the future. We just tend to not always see the progress and we ignore the past when we only see it as a circle.

Each of these ideas are not only applicable to our individual organizations, but to our field as a whole. Events like DevOpsDays are amazing opportunities for us to share our experiences and help mentor someone along for the little bit of time we have with them. Just remember to not pass up the change to get some mentoring of our own while you’re there.

If you find yourself starting out taking a DevOps approach to how your development team works you will need people to lead and champion those changes and mentors to share the ideas with everyone. If you don’t then it will become just another attempt to use a different methodology (think Agile or Lean) to improve the output of the team. And I think many reading this have unsuccessful experiences when those types of changes come down from management as a we’re doing this now. Here is a class or book. Now make it work.

Doesn’t matter what the change is if the team has the leadership, mentors, and chemistry they can make things happen or they have the weight to challenge ideas that will not work.

One final comment that I want to point out is these ideas don’t exclude self-managed organizations. The fire service is very structured. Pretty much you can think of it as paramilitary, but it’s made up of several self-managed teams who each have a fair amount of flexibility. You could say they are the pinnacle of the Results Only Work Environment and self-managed teams. And they succeed by taking care of their people with these ideas, after that everything else usually just falls into place.