How to develop T-shaped people

Jason Yip
3 min readApr 8, 2018

--

Let’s say we accept the reasoning for why T-shaped people are valuable. How do we go about developing this in our teams?

It’s most useful to start cross-training for adjacent processes.

Creating T-shaped people is not instantaneous. The most valuable place to start is with adjacent activities in your workflow, that is, any point where we have one role handing off to another one. Cross-training at adjacent activities helps smooth out hand-offs.

Cross-training at adjacent activities helps smooth out hand-offs.

It’s easiest to cross-train on similar skills.

It’s easier to learn skills and technologies that are similar to the ones we already know. This is a nice way for a team to start trying out cross-training if they’re sceptical.

It’s easiest to cross-train similar skills or technology

Make cross-training gaps visible.

Addressing key person dependencies, aka the “bus factor”, is a good argument for cross-training.

If we make it obvious where there are skill gaps on the team, it encourages people to cross-train where there is the least capability. I generally like using a cross-training matrix for this.

Cross-training matrix shows where cross-training would help reduce key person dependency the most.

Pairing leads to very rapid cross-training.

Pairing, especially so-called “promiscuous pairing”, facilitates cross-training very quickly.

If your team is unwilling to pair all the time, an alternative is to encourage pairing on tasks where only 1 or 2 people have the relevant skills.

Pairing facilitates cross-training very quickly

Cross-functional work items encourage cross-training.

When work is broken down based on incremental outcomes, they tend to require multiple skills. This tends to encourage cross-training.

When work is broken down based on skills required, this tends to encourage specialisation.

Cross-functional work encourages cross-training

Generalised titles de-emphasise specialisation.

Specialised job titles, like “Front End Developer”, “Back End Developer”, etc. encourage people to specialise. Instead, a more general title, like “Developer” keeps things open.

Job titles can encourage specialisation or cross-training

--

--

Jason Yip

Senior Manager Product Engineering at Grainger. Extreme Programming, Agile, Lean guy. Ex-Spotify, ex-ThoughtWorks, ex-CruiseControl