The Limits of T Shaped Teams

We talk a lot about T shaped skills in agile teams. For those who aren't familiar with the terminology, think about a capital "T". The vertical line is the team's core skill, they have deep expertise in that. The horizontal line is all the other things the team is capable of outside its core skill. A good team should have skills that are T shaped (broad as well as deep), rather than "I" shaped - deep in one area with no ability to work outside that (like traditional silo teams). We don't want a team that can only work on the back end of the website, we want teams that can deliver end to end. We don't want teams that can only deliver on the shopping cart, we want teams that can deliver in other areas as well.

The more T shaped our teams are, the more flexible we can be in organising work. If we have a lot of shopping cart enhancements, we don't have to wait for the shopping cart team to become free and deliver them all, we have a bunch of teams who can pick up the work and deliver it. This is a very good thing. There are however, a few key misconceptions about T shaped teams that I have observed over the years, that are worth pointing out and correcting.

The first thing to point out is that T shaped teams are T shaped. They have deep expertise in one area and shallower (but still useful) experience in others. T shaped teams still have a core skill where they are most effective. The expectation of T shaped teams seems to be that they can pick up any piece of work and deliver it as effectively as any other team. They can certainly pick up the work and deliver it, but if it's outside their core skill set, they will not be as effective as a team where that work is part of the core skill set. The shopping cart teams will still be more effective at delivering shopping cart features due to their deep expertise in that area. They are T shaped not square shaped with equal expertise in all areas.

This means that T shaped teams are not a silver bullet for scheduling conflicts. They can help but you will often be sacrificing speed of delivery for an earlier start. It may be more efficient long term to wait for the more skilled team to finish and have them deliver it than giving it to a less skilled team. Of course by doing that work, the less skilled team becomes more skilled in that area and will be faster next time, so there is a three way trade off between speed (and often quality) of delivery, the desire to start early, and upskilling teams.

The second misconception about T shaped teams is that they should be able to to pick up any piece of work the organisation chooses to throw at them. This may be the case in relatively simple environments but in complex environments, like a large bank that might have 2000+ IT systems, no team of 7 (plus or minus 2) can possibly know, or even get to know all of them. There will be limits to their skillset. We can't expect our web teams to suddenly be able to pick up work on legacy mainframe systems.

We can't have individual teams that can deliver right across a complex environment without making the teams unfeasbly large. In a real, complex environment you would be looking at teams of 50+ to get all the relevant skill sets included. That isn't a team it's a hoard.

In complex environments no single team can do end to end delivery. We need more complex structures - a T shaped team of teams for example - to deliver end to end. Even then, our team of teams will still be built around a core capability like online banking, and will be less efficient at delivering in other areas. Unless we want to somehow arrange our entire IT organisation of thousands into some huge team of teams construct which will be all but unmanageable (just like our current IT organisation, which is why we are organising into teams). So again, even at scale we aren't building generic, "deliver anything" machines. We are building capabilities around core skill sets, probably based around organisational value streams or platforms, with limited (but still significant) ability to help out in other areas.

The last misconception I want to cover today is at the other end of the scale spectrum - the individual team member. In a T shaped team, we need team members who are also T shaped.They need to be able to work outside their specialist area to help the team deliver. We want coders who can help with testing, testers who can help with analysis and so on. This is good. I have however seen a trend towards expecting team members to be able to do anything the team needs to do. We don't want a front end developer who can do a little backend work if they have to, we want a developer who can do both equally well.

What we end up doing is chasing unicorns. Mythical beasts with wonderful powers. Developers who can develop in any language on any system and do analysis and testing as well. I have even seen this in teams of agile coaches where every coach is expected to be equally good at technical coaching, team coaching, portfolio coaching and executive coaching. Wonderful though that would be, like unicorns, such beasts are mythical. Our systems are complex enough that no one person can understand everything about them. That's why we work in teams. Our T shaped people, just like our T shaped teams have a deep skill and shallower experience outside that. They aren't square shaped and equally good at everything.

So T shaped skills are really important. They give us flexibility and promote learning by getting teams and individuals to work outside their key skill areas and develop in new ways. Just don't make the mistake of thinking that T shaped means everyone is equally good at everything. T shaped is T shaped, not square shaped.