As an agile coach I work with many companies and the terms “cross-functional” and “T-Shaped” get tossed about quite a bit. Do they mean the same thing? Certainly, many people use them synonymously.
To avoid confusion when organizing agile teams and larger agile ecosystems, I have found it useful to distinguish between these two terms. In this article I will share how I define these terms and illustrate when I find each to be useful.
Cross-Functional
Cross-functional is an adjective that describes some entity (e.g., team or larger organizational entity) that includes people who do different types of work.
Although the image above shows people coming from different functional areas of the organization, that is not a requirement for the resulting team to be cross-functional (it’s just quite common). The essence of cross-functional is multiple people collectively covering more than a single functional area, regardless of where they report within the organization.
T-Shaped
T-Shaped (also an adjective) is a metaphor used to describe a person with deep vertical skills in a specialized area (such as UX design) as well as broad but not necessarily very deep skills in other relevant areas (such as testing and documentation).
Completely Cross-Functional Teams and Ecosystems
The following will discuss cross-functional and T-Shaped against three different-sized entities: individual. team, and ecosystem. The meaning of individual and team is obvious. By ecosystem I mean a coordinated collection of teams and people working towards a common goal (e.g., an ART in SAFe, a Nexus, a Spotify Tribe, etc.).
For the sake of the comparison, I want to use the concept of completely cross-functional, which means that not only does the entity have people who do different work, but collectively the entity has people who can do all the necessary work to get the job done.
Whenever possible, my goal is to have completely cross-functional teams and ecosystems to eliminate shared dependencies with entities outside the teams or ecosystems. In other words, a team or ecosystem can get the job done without needing the assistance of an entity not on the team or in the ecosystem.
Can we describe individuals as cross-functional? Of course – perhaps your organization uses the term “full-stack engineers” (such engineers are cross-functional)! The problem in many organizations is when the stated goal is to have individuals be completely cross functional.
In other words, an individual can do all the various types of work necessary to get value delivered by the team or ecosystem. Even full-stack engineers are not likely completely cross-functional (e.g., can they do UX design work, or do legal review of content, etc.?).
I have no expectation, or need, that an individual be completely cross-functional. Of course, it would be helpful if a specific individual could do more than one type of work, but I have no expectation that a single person can do all the types of work. I do have the expectation that the team or ecosystem can do all the necessary types of work to get the job done.
From my perspective, the concept of completely cross-functional should only be applied to teams and ecosystems, not individuals.
Somewhat T-Shaped Individuals
Whereas the term completely cross-functional principally applies to teams and ecosystems, T-Shaped, principally applies to individuals. For example, I want to say that Ravi is a T-Shaped Java developer who can also do automated testing and write documentation. At a grander level, my goal is to have a team or ecosystem comprised of T-Shaped people.
To be clear, a completely cross-functional team could exist where every member of the team is a functional-area specialist that has no ability to work outside of his or her specialty area. Such a team would meet the definition of a completely cross-functional team but would be fragile in the presence of uncertainty. For example, what if a particular specialist on the team goes out sick and no one else can do that work? Then the team is more at risk for not delivering on its goals.
On the other hand, if the team or ecosystem is completely cross-functional and comprised of people with T-Shaped skills, then such teams or ecosystems would be more resilient when things change (e.g., someone gets sick and is unavailable and someone else with coverage of the sick person’s primary skill area can shift over to do the work).
T-Shaped individuals on the same team or ecosystem would also reduce the probability that intra-entity dependencies could become blockers. Let’s say that only one person on the team does testing, then everyone else on the team is dependent on her availability before a work item can be tested and completed. If many people could do testing, then the chances of getting blocked waiting for the “tester” are reduced.
Can we apply the concept of T-Shaped at the team or ecosystem level? For example, does it make sense to say: “Team A is T-Shaped?” I have certainly seen people say so. You might conclude that they are saying Team A is completely cross-functional and comprised of T-Shaped individuals. That might be a reasonable interpretation, but that is almost never what they mean. Rather, they mean to imply that the team or ecosystem can do more than one type of work. For example, Team A can work on Product One or Product Two.
Personally, I find this use of “T-Shaped” at the team or ecosystem to be odd and would prefer to avoid it. I would just say Team A is cross-product capable.
Summary
Within an agile organization, I want to have completely cross-functional teams and ecosystems that themselves are comprised of T-Shaped individuals. I have no expectation the individuals on these teams and ecosystems are completely cross-functional.
I find using the terminology in this fashion is clear (at least to most people) and it communicates a target state that has many desirable properties.
What do you think? Do you agree with my definition and use of these terms? Leave your comments below so we can have a discussion!
To learn more about the importance of cross-functional teams and ecosystems and T-Shaped individuals and how they affect the flow of work at scale, you can attend my upcoming live online instructor-led course Dependencies Are Killing Your Agility: Learn to Fight Back on January 27-28, 2022.
Also, if you want to get notified when I published new articles, please sign-up for my periodic newsletter.