I really only had myself to blame. My team had raised this concern a number of times at retrospectives and I hadn’t taken it seriously enough: We had been taking on new tools and abilities too fast to spread knowledge of them around. This was creating pockets of expertise and dependency on key people. But as their manager, I’d failed to listen and act.
These were the thoughts running through my head as I accepted the resignation of a key member of my team. I knew the hole he left was going to be a big one. He’d been driving implementation of a really important new logging service that our organization was depending on more every day. Now the rest of the team was going to have to scramble to learn this system, on top of all their other duties, in order to prevent a serious outage that could affect customers.
As our team somberly took stock of this situation, we assessed all the tools and expertise we needed in order to be successful as a team. As the team had suspected, we had key-person dependencies in many of our skill areas. If another person left, we’d be in serious trouble.
I started talking to development managers and colleagues outside the company. It was pretty obvious that this is a problem that teams of all kinds face, from software development to infrastructure and even HR or the help desk. I started to do some broader research and found that 90 percent of the people I asked had been on teams with this problem! The issues they called out as consequences were incredible. I didn’t want my team to fall prey to this anymore. We had to find a way to make sure we got rid of these risks.
Over the next six months I worked with my team to develop a process and a tool to help us make sure that critical expertise and ability wouldn’t be able to be held by one person like that again. Over the course of a year and a half the approach evolved and helped to eliminate all our key-person dependencies.
Our grading algorithm looks at the skills you define for a team, taking into account importance of the skill based on its stack ranking, and examines the skill rank distributions of team members. The most important skills should have more skill coverage to make sure critical, high-throughput functions of the team are adequately covered, but it also helps identify areas that are underrepresented.
The system we created is fun to engage with and doesn’t add to our workload. It helps us focus training and hiring in the best way possible. Morale on our team is up, and they are learning new skills. And we’ve not had any more attrition.
The goal is to help your teams identify and manage these key-person dependency risks. With just a little effort, you can make a huge difference.
Lee Eason is presenting the sessions Methods for Handling Key-Person Dependencies in Agile Teams and Peer to Peer Session: Solving Your Continuous Delivery Problems at Agile Dev, Better Software & DevOps West 2018, June 3–8 in Las Vegas, Nevada.
As the director of DevOps at Ipreo and the co-founder of Tekata.io, Lee Eason is serious about high-performing teams. A self-taught programmer and now a technology leader, Lee believes passionately that continuous learning has been the key to his success over the past 18 years. He has served in various technology industries, including marketing, education, health care, and finance. Most recently at Ipreo he has led a full DevOps transformation for all of the organization's 30+ products and 65+ scrum teams leading to a dramatic reduction in manual work and an increase in quality and customer satisfaction across the board. You can read Lee’s articles on LinkedIn and follow him on Twitter @leejeason.