Here’s the Thing About T-shaped People

Here’s the thing about T-shaped people… It’s about “T-shaped” teams too!

One of the challenges for organisations when they move to agile ways of working is that they need to build teams made up of “T-shaped” people. We can also describe this as a cross-functionality. The Scrum Guide describes cross-functionality as:

“Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.”

The “T-shaped” metaphor comes from the idea that an individual can possess deep skills in a few areas, as well as a broader range of shallower skills.

T-shaped people

The Challenge

For many people this concept can be a challenge because:

  • Historically, organisations are built around teams of similarly skilled individuals or components of the system. For example, QA team or “Backend” Team
  • Management lines follow these organisational structures too, e.g. Development Manager
  • People build entire careers- by specialising in highly sought after skill sets, e.g. Front end developers
  • A common misunderstanding is that because each person should be T-shaped, each person must therefore possess every skill needed to deliver.

The Problem

The traditional approach of building teams around common skills and components has a number of problems in the complex world we now inhabit:

  • There is a large coordination cost in order to move a piece of work through all the required areas. It is traditionally the role of project management to manage the dependencies that this causes
  • Knowledge will be lost during the handoffs between various specialisations. Decisions made up the chain will be lost as work moves through various teams
  • Individuals become highly siloed in skill set and product knowledge. The motivation to expand skills and knowledge becomes more difficult
  • The “it’s not my job” attitude can become prevalent where individuals have no motivation to be responsible for anything more than their specific component

A Common Misunderstanding abou T-shaped people

The common misunderstanding within many organisations that a specific person has to possess every skill is a challenge. In reality,  an individual person within a team doesn’t have to possess every skill in order to be T-shaped. Rather, the whole team does. The following diagram illustrates this point. Each “T” represents a different team member with a slightly different set of skills:

T-shaped teams

The concept is not a new one. In fact, Takeuchi and Nonaka documented the idea in their seminal paper, The New New Product Development Game back in 1986:

“They [team members] also acquire broad knowledge and diverse skills, which help them create a versatile team capable of solving an array of problems fast.

Such learning by doing manifests itself along two dimensions: across multiple levels (individual, group, and corporate) and across multiple functions.”

The Benefits of a T-shaped team

By building a team with a mix of skills, rather than around a specific skill set, the organisation will be able to:

  • Minimise dependencies between teams, resulting in fewer challenges with coordination and differing priorities
  • Reduce handoffs between knowledge silos, avoiding information loss
  • Broaden and deepen the individual team members skills over time through collaboration
  • Foster team ownership of the whole solution rather than specific slices

The same model applies to larger organisations that have many teams. The analogy scales nicely. You can’t expect every team to have all the skills from day one. Yet across all the teams, you will have the blend of skills needed.

Now this could conceivably cause problems where a small number of teams (maybe even a single team) possess a very specific set of skills. Such teams will essentially become a dependency to the other teams, going against the idea of cross functionality.

There are three options which can mitigate this problem:
  • If the skill set is highly specialised, expensive or regulated then you will probably have to live with this dependency. Prioritisation will be a challenge and requires careful consideration. Over time you should look to uncouple this dependency but it may not be possible
  • If the skill set is less specialist but it’s still difficult for the wider group of teams to be totally proficient then their are a couple of approaches you could take:
    • apply a model where the specialist team supports and enables the development in other teams. This is the approach that Spotify take for their client apps teams
    • Large Scale Scrum suggests the concept of a traveller developer who rotates teams every couple of sprints, with the aim of sharing skills and knowledge.
  • The last and most desirable option for the long term would be to reorganise the teams so these skills silos no longer exist, either by training or a better distribution of skills in the teams. A warning on this, frequent changing of teams is highly destabilising and changes should not be a considered lightly.


The types of changes described here will be difficult to overcome for many organisations. However, careful planning, consideration, and understanding of what makes a successful high-performing team will result in an organisation that is better placed to deliver value to its customers.

If the challenges mentioned in this article resonate with you and you’re curious how AWA can help your organisation, please talk to the AWA Team today.

Leave a Comment

Your email address will not be published. Required fields are marked *