How do you make sure you’re rewarding, instead of punishing, your utility players for their versatility?
Managing variability is a key agile practice and it’s one where many teams stumble. Some feel the pain in “story sizing” or “estimation”; teams doing timeboxed iterations may encounter it when they scramble to finish what they committed or struggle to interpret and apply their velocity metrics.
There’s also variability in work types and roles, whether that’s the balance of code vs. test or specific coding skillsets like data vs. business logic vs. UI. I blogged about it a while back as How Flexible Should an Agile Team Be? A preferred way of managing variability while still allowing the specialization and deep expertise teams need is to cultivate T-shaped skillsets: deep in a few areas, with meaningful breadth across a range of others.
This carries the implication that the T-shaped individuals on your cross-functional teams will cooperate, flex, and share workloads. That’s the point. That’s what you have them for.
It also implies that at least some of the time, your T-shaped individuals will be working in their areas of breadth rather than depth—what Myers-Briggs would call out-of-preference.
That’s where a lot of teams hit a wall. It turns out, just because someone on your team can do something in their breadth areas doesn’t mean they want to. Doesn’t mean they love it. I think we need to handle this situation carefully. T-shaped individuals can be quite valuable and we don’t want to burn them out or alienate them.
In talking through this challenge with my current customer, I came up with two things that any T-shaped individual needs to know when you’re asking them to work on something that isn’t their depth:
First, they need to know and believe that you don’t expect them to work in their out-of-preference zone forever, or even very often. They need to see a light at the end of the tunnel. If breadth work takes over the stuff they actually love doing, you’ll lose them, which sucks for everyone. If you find it necessary to drag them out-of-preference too much of the time, your team has a resource problem which you should solve with HR.
Second, they need you to fully understand, appreciate, and accommodate the fact that they’ll be slower and less effective in their out-of-preference areas than an expert in those areas would be. If you have perfectionists, this’ll drive them crazy: they’ll hate delivering less than the theoretical best, and they’ll need reassurance that their effort is not wasted.
What do you think? Have I missed something that you look for from your management team?
Update 4th April: Thanks, commenters! Y’all’ve got me thinking about another principle. I assert that it is never possible for the team or management to dictate someone’s depth skills. They have to love a thing in order to get to be any good at it. And can the team define someone’s breadth skills for them? They can try, but they probably shouldn’t.
When we talk about how valuable T-shaped individuals are, we mean people who have natural strengths and interests and are flexible in how they help out the team at any given time… not minions who get assigned crap work because “somebody’s got to do it”. (If you’re a sincere T-shaped individual who’s getting all the crap work, you’re insanely undervaluing yourself. Go update your résumé.) On the flip side, if your team members refuse to do out-of-preference work, maybe they’re not T-shaped at all; maybe they’re one-trick ponies…
Great post and something I have been thinking a lot about lately. Just because I have a aptitude to do something doesn’t mean I want to do it. I want to make sure my company doesn’t push me in a direction for their long term future that isn’t what I want for myself.
Yeah this is a great post – I have been struggling with this lately as well. I think you hit on a couple of important things:
1) The *TEAM* needs to be able to handle any work that it asks for..not any single contributor on the team.
2) Everyone has different skills, passions and preferences – the important part is that the team members complement each other appropriately. That has the less than comfortable implication – that for any given team, there may be players that are not complemented and/or don’t complement the rest of the team in a helpful way.
I love the “T” player idea – but what are the alternatives to being a “T”… can you be a “_” or an “I”? :)
Also – it’s important to note that people don’t have to have a skill in order to complete work based on that skill. I hear too frequently about folks that are fearful of doing things they’ve never tried….that goes along with perfectionism – which, IMO, is a huge problem – developers should seek to build the best possible thing – knowing they’ll never do it (regardless if it is or isn’t an area of particular strength for them). This freedom to “fail” is part management support but is also largely based on the character of the individual.