T-Shaped People: What and How

T-Shaped People in a cross-functional team will solve capacity problems much easier than limited domain experts. In general, agile methodology calls for T-Shaped People. Unfortunately, there may be cases where the basic approach may not work, or worse: be counterproductive.

Skill can be learned

Developers learn each of their domains, such as Java, C++, Python, PL/SQL etc. Picking up basics in a skill usually doesn't take more than a couple of days - mastery will take long, however. The more frequent a skill is utilized, the more fluent developers become. For example, simply confronting a front-end developer with the Unix Shell will permit them to pick up enough bash to get basic stuff done. Over the months, the developer will gain sufficient expertise and confidence to do even more intricate tasks in the new domain without relying on help.

Not everything is worth knowing

Certain skills may simply require a high level of expertise before they are actually valuable. For example, basically knowing Testing is not valuable in and of itself - if you don't understand what you must look for to catch the hidden bugs, your test may provide a false sense of confidence and cause more harm than good - so the team actually has to decide whether this specific skill is actually worth distributing in the required depth.

It is good to have more than one test expert on the team, but whether everyone should be able to pass the ISTQB Foundation Level without studying - is a completely different question.

For T-Shaped growth, apply the simplicity principle: Acquire as much skill as necessary to resolve potential bottlenecks, but do not revel in domains that are not your own.

Maintain Diversity

Do not confuse "T-Shaped People" with an anonymous mass of developers where everyone is equal. People still have individual strengths, individual focus and personal goals. One developer may really dig numbers, while another digs performance. Diversity is good. A Cross-Functional team should celebrate diversity rather than blending towards equality.

Again, the goal for T-Shaping is not to make everyone equal, but to resolve bottlenecks.

Not everything needs to be T-Shaped

One lesson of T-Shaping that is difficult to understand: Some people are simply not fit for certain tasks.
While our environment can force us to be more or less plan-oriented or more or less creative, the inherent brain-orientation will limit our performance in a specific domain. For example, a Left-brainer can learn how to use a drawing tool or a Right-brainer how to use a planning tool - but their approach will still be different, and - consequently, the result.
In some cases, this is actually desirable. In other cases, it is a clear reason for that person not to take on a specific task. In these cases, it's still viable to consider passing the buck on that one.

When "good enough" is too high

In rare cases, the limit for "good enough" is so high that only domain experts should take on a task. A specific case here would be the design of graphics and sound. Such artwork is either "good" or completely unacceptable. There is not much middle ground.

While you can train a Java developer to use a paint tool, the result of taking on a "paint a landscape" task will most likely be underwhelming. In such a case, it is definitely not worth considering shaping a "T".
The benchmark definition of "acceptable" set in the specific domain may occasionally turn the business value of T-Shaping so negative that it is simply not worth considering.
In this case, the organization must find different alternatives.

Summary

The simplest approach towards T-Shaping is simply picking up what you need on the go. However, you must ask the question "Will we need it?" and "Will the output actually be valuable?". If the answer to either of these questions is "No", then the organization must find different ways of ensuring that the specific skill does not become a bottleneck.