On Cross-Functional Teams, DevOps and Spider Charts, pt. 2
##Part 2
As we saw in Part 1 of this essay, there are deliberate ways to organize our cross-functional teams for success in delivering our services in production. One of the most important ways is practicing infrastructure as code, which is critical to automation (the A in the CAMS, or Culture, Automation, Measurement and Sharing DevOps model), a core principle.
When working on that post, I was really excited to find 5 reasons everything you know about teamwork is wrong by Eric Barker that draws from Bronson and Merryman’s book Top Dog, while I was reading the Kates’ excellent Tech Leadership News.
There were two particular “rules” in that post that I felt were particularly relevant to our discussion of cross-functional teams.
Ninety percent of team success is determined before they start work
…60% of a team’s fate has been written before the team members even meet. Its destiny is decided by a combination of the team leader’s efficacy, whether the team’s goal is challenging yet attainable, and the ability level of the people recruited to the team. Thirty percent of a team’s fate is sealed with the initial launch of the team— how the teammates meet and, in those initial exchanges, how they split up the responsibilities and tasks before them. They need to agree on common codes of conduct and shared expectations. All told, 90% of a team’s fate has been decided before the team ever begins its real work.
I thought this was really fascinating given the emphasis Part 1 placed on the ability members of a cross-functional team have to help each other not only deliver, but to grow. It highlights the need to make smart choices about how the teams are formed like Chris Fry mentions in his description of the Twitter Engineering Culture. Does this mean that our cross-functional model doesn’t work? No. It just means that team composition has to take into account other elements (e.g. leadership, experience) than the simple axes we’d outlined in the description of our model. Just as Roy Rapoport said in his Flowcon presentation, “You can’t put smart people in a dumb organization to make the organization smarter”, the choices we make about how to compose our teams are critical to its success. Without the cross-functional aspect however, they are probably without any hope of having a successful deployment.
Defining roles may be the most important thing a team does
Clarifying who is going to do what— identifying distinct roles— is one of the most proven ways to increase the quality of teamwork. The egalitarian notion that team members should be equal in status and interchangeable in their roles is erroneous. Teams work best when participants know their roles, but not every role needs to be equal. Dr. Eduardo Salas, at the University of Central Florida, is one of the most widely cited scholars studying team efficiency. He has devoted his life to understanding the vast sea of team-building and team-training processes— analyzing teams used in the military, law enforcement, NASA, and numerous corporate settings. The only strategies that consistently deliver results are those that focus on role clarification: who’s going to do what when the pressure gets intense.
This quote really threw me for a loop. I had been making an argument that each team member should share responsibility for a variety of roles (dev, system, qe, etc.) on a cross-functional team and here it said “The egalitarian notion that team members should be equal in status and interchangeable in their roles is erroneous”. When reasoning about the possibilities of why this may or not be true, I looked at the teams they studied (“military, law-enforcement, NASA, and numerous corporate settings”). For the first group, it seemed to make sense. If I’m in the military and the guy next to me doesn’t know how to use the grenade launcher as well as I do, I sure want to be the guy using it in a firefight. But, how does that fit with the “numerous corporate settings” team? Our service delivery team is definitely in a corporate setting. Does this mean that the sysadmin should only ever do systems administration, and the developer likewise?
Then I re-read it with the last sentence “who’s going to do what when the pressure gets intense”. That’s when it actually made sense. When we have a production outage and we identify a problem, the developer is probably not going to be the one responsible for troubleshooting overruns in the TCP queuing if there are sysadmins or network engineers who have more experience and the goal is to get the site back up as fast as possible. That doesn’t mean that under normal circumstances the developer cannot come up to speed on network tuning (or that they must, they can contribute in their own way), just that when the “pressure gets intense”, the team needs to play to its strengths.
To use a sports analogy, in football, the cornerback genrally runs with the wide receiver, and the safety generally is his backup down the field. When the ball is snapped (our production outage situation), each plays the role they are assigned. However, that after each play is over they walk over and discuss with each other what they thought about the previous play and what they saw. Maybe after enough time playing together, they understand better and better how those roles are complementary to one another. That kind of open communication is essential for a team to function at its highest levels when the “pressure gets intense”. That is exactly how the team (be it sport team or service delivery team) gets better.
A cross-functional team is still necessary to achieve the 1:1 flow we’ve learned about from Toyota manufacturing. Agile emphasizes the advantage of cross-functional teams and we know that for a team to be effective in delivering a service in an infrastructure as code environment, they need to have all the skills required to deliver that service. We’ve also learned that the composition of the team goes beyond simply plugging in the correct functional area but there are other components that don’t just help, they actually determine the success of the team from the outset. In a high pressure situation, the cross-functional team is still effective, but team members are more likely to fall back to their core strengths in order to get past the stressor. In our corporate environments, cross-functional teams can be one of our most effective tools in helping us realize the benefits of practicing DevOps principles.
Special thanks to Seth Katz and Alan Caudill for helping me sort much of this out and make it understandable. I hope I was able to make their efforts a reality.