Understanding the Team Skills Profile, and
why “un-teaming” kills delivery of value.
Every team has a Skills Profile, like the unique fingerprint of technical and business abilities of the group as a whole. My friend Tim Ottinger (who you should follow) often uses the term “ Un-teaming “. He is primarily referring to the “scatter / gather” anti-pattern, where teams still don’t fully grasp the power of moving one single item (the most valuable) forward as a group. In Tim’s “un-teaming”, each person grabs a piece of work and scatters to the winds. This anti-pattern is often a defense mechanism for Imposter Syndrome. If Dave the developer is working alone in his home office, on a separate piece of work, no one hears him say “I don’t know how I’m going to do this”, or look up answer on Stack Overflow, or YouTube videos.
There’s another way in which teams can be worse off, by following a heuristic that seems intuitively beneficial. It’s a special case of “un-teaming”. First we need to understand two specific benefits of a high-performing team: Robustness and Anti-Fragility.
Robustness is the ability to do work, a lot of work, heavy work, different types of work. Robustness is a resistance to fragility inducing stresses. Robustness is like being a strong, flexible cross-training athlete. A healthy all-around athlete can lift heavy things and can do more than one specialized exercise. One stressor will not defeat a Robust system.
Anti-Fragility is the ability to recover from fragility testing conditions stronger than before. When an athlete lifts weights, the muscle tissues suffer micro-tears, and the body rebuilds the muscle stronger than before. Broken bones heal to be stronger at the break. Poke an anti-fragile system, and it bounces back beyond the original peak.
Un-teaming by leveraging a team’s individual skill advantages is a common, intuitive tactic that leads to an unintended outcome. In practice, this means Dawn is the team’s brilliant DBA and data science expert. The team, or someone who dictates parsing out the work, decides having Dawn work on a new data warehouse feature is helping the team by taking advantage of her expertise. It will be done well, and quickly.
The Team Skills Profile
Every team has a unique combination of knowledge, skills, and experience of each individual member. It’s like an imaginary fingerprint that I call the Team Skills Profile. This could be multi-dimensional, including factors of time, multiple experience contexts, general expertise, academic knowledge and many more factors. For our purposes, we’ve collapsed this into two dimensions. The example below shows a team’s self-rated skills level (Y-axis) across their range of technical and process skills (X-axis).
Any individual line (like Frederick in green) shows that person’s skills profile. In Frederick’s case, he has just joined the team as an intern. He has only been developing for about a year. Learning Python at home, he became incredibly proficient at it. He’s a deep dive kind of guy, but he’s been in his own fishbowl. Frederick hopes to get hired on as a junior developer, and he’s eager to augment his deep Python knowledge in a broader context of version control, interfacing with other technologies, testing, awareness of customer needs, and how to plan and track his work.
The beauty of the Team Skills Profile is seeing the maximum capability the entire team is capable of delivering. As an individual increases a specific skill, the top-line profile only moves up. It will decrease in variance from the bottom up. Theoretically, the top line never comes down. (The exception would be the loss of one member, but following the principles from understanding the power of Robustness and Anti-Fragility, the effects of sucj a loss should be minimized).
It doesn’t matter if one or more developers have a lower skill than others. No one can bring the top-line down— it’s not an average. The top-line profile also shows the team’s peak skill and the team’s weakest skill, making it easy to identify areas for rockstars to share knowledge (Anti-Fragility). Frederick could get a big ego boost and gain some appreciation from his new team by hosting a lunch-and-learn on Python. It’s visibly clear which topics could increase team-wide weak skills (Robustness). Ashlyn, Kevin, and Felipe could research some advanced CRUD techniques and host a team session.
Does it matter if one developer is the weakest across all skills? Argee’s line isn’t even visible because he’s rated himself a “0” on everything. Should he be nervous? No! Because the team is responsible for delivering the work. This understanding should increase Psychological Safety for all team members and helps create a safe space for new team members, or junior developers. The top-line Team Skills Profile is a “defense shield” protecting learners and noobs.
The converse is also true. When “un-teaming”, we’re decreasing robustness and increasing fragility, because we can only utilize the Skills Profile of one person, or even a pair, which mathematically will always be below the top-line profile. If we imagine calculating the delta space between an individual, pair, or mob Skills Profile to the Team Profile, that is the value we are throwing away whenever we un-team.
A common pattern seen comparing “intuitive” tactics to empirical systems like Lean, Theory of Constraints, Scrum, or XP— “intuitive” ways of dealing with apparent obstacles often accomm _ odate _ a problem rather than _ solve _ the problem at the root. And this brings us to the problem of un-teaming. Every individual has high and low areas of skill. The black top line is the Team’s skills profile. No individual can have a skills profile as robust as the whole-team skills profile. It’s very common for a team, dev lead, manager, or even Dawn herself to decide she should take the new data warehouse feature.
To optimize the company’s Goal, our team’s Goal, and individual developers’ Goals, we need to consider the second-order effects of this decision. What will happen when Dawn continues to take the data work, Kevin continues to take the API work, and so on? The Team Skills Profile increases in contrast. Dawn’s skills in other tech will get dusty, and she will increase her expertise in data. In fact, because she’s already highly adept, she will notice lessons during the data problem solving that Marvin (who is moderately skilled with data) may not notice. High expertise combined with more practice compounds. The more Dawn’s peak data skills outstrip the rest of the team, the more likely she will be assigned all data work in the future. This is a negative feedback loop. It seems temptingly positive at creating a better data wizard and getting work to Done quickly (both are Local Optima). But it lowers Robustness and decreases Anti-Fragility. The long-term effects include “black swan” events, like Dawn going on vacation, or leaving the company because she feels burned out and plateaued on data expertise.
When a Team works as a Team, even if Dawn is leading a session to solve a data problem, every member on the team gains a little skill.
Scrum is named after the rugby formation where all players of all skill positions link arms and push in the same direction at the same time to move one ball forward. In custom software development, there are techniques that leverage major advantages of the nature of software itself, and the complexity and uncertainty of product requirements. Operations Management experts in physical manufacturing would be insanely jealous of these. These advantages are what allows Scrum teams to see increases in Flow of Value in the 200%, 400% range (or more). It’s nearly impossible to do that on a Toyota truck assembly line.
A customer software development team that does not use the techniques leveraging unique advantages of software cannot see performance gains greater than a team that does not have these advantages.
Un-teaming is a major loss. And using a Team Skills Profile with self-assessment and period team discussion is a great way to increase the Robustness and Anti-Fragility of your team. You competition might be doing it right now.
Top comments (0)