“T-shaped” people model misuse

In Hand­book for new em­ploy­ees (PDF, 4 MB), Valve in­tro­duced on page 47 a con­cept of “T-shaped” peo­ple. What it means that peo­ple who want to work at Valve are ex­pect­ed to be both gen­er­al­ists—“high­ly skilled at a broad set of valu­able things” and ex­perts—“among the best in their field with­in a nar­row dis­ci­pline.”

This mod­el was used by nu­mer­ous oth­er com­pa­nies, but not in its orig­i­nal form. A pop­u­lar ap­pli­ca­tion of the mod­el is the ex­pec­ta­tion that a team mem­ber will be able to per­form not only a spe­cif­ic sub­set of pro­ject tasks which cor­re­spond to his ex­per­tise, but also vir­tu­al­ly any task re­lat­ed to the pro­ject. For in­stance, a de­vel­op­er with a strong back­ground in Java and work­ing on a web ap­pli­ca­tion should not lim­it him­self to serv­er-side pro­gram­ming, but is ex­pect­ed to han­dle a fea­ture which also in­volves client-side (which could, for in­stance, in­volve Type­Script, Re­act, HTML and CSS, as well as a de­cent knowl­edge of HTTP) and op­er­a­tions (which can also in­volve a bunch of tech­nolo­gies and pro­to­cols). Ag­ile and De­vOps en­cour­aged this vi­sion.

In this per­spec­tive, the orig­i­nal mod­el ap­pears over­ly sim­plis­tic. Peo­ple are not just “T,” “I” and “‒.” Things are way more com­plex than that. Every skill has a rel­a­tive val­ue on a mas­ter­ing scale.

While the per­son is rather a Java de­vel­op­er, he is knowl­edge­able when it comes to op­er­a­tions tasks with the tech­nol­o­gy stack used by the team; he knows damn well HTTP pro­to­col; he has a good un­der­stand­ing of Re­act—not as good as if he were a full client-side de­vel­op­er work­ing with Re­act since 2013, but good enough to per­form well enough most of the tasks which in­volve Re­act... I think you get the point. By mea­sur­ing many of the skills and or­der­ing them by the in­verse of ex­per­tise lev­el, one can build a curve:

Oth­er per­sons may have dif­fer­ent curves. In the case of A, the per­son has a broad range of skills, but no strong spe­cial­iza­tion—Jack of all trades, mas­ter of none. The chart B shows a per­son with in­ter­est­ing skills, but they are lim­it­ed to a nar­row do­main: it usu­al­ly means that the per­son will not be in­clined to con­tribute to oth­er do­mains. Those two di­men­sions—the spe­cial­ized pro­fi­cien­cy and the range of skills—is al­ready rep­re­sent­ed in the “T-shaped” peo­ple mod­el. What is miss­ing, how­ev­er, is the falloff, i.e. how fast the skills of a per­son de­crease out­side his do­main of ex­per­tise.

The falloff is es­sen­tial. If ac­tive in­volve­ment of a per­son is re­quired in all facets of the pro­ject, he should have a de­cent un­der­stand­ing of every tech­nol­o­gy be­ing used. If this is not the case, the team mem­ber will be a bur­den most of the time, ei­ther re­quir­ing con­stant help from oth­er team mem­bers, or im­ple­ment­ing things on his own with­out the ba­sic un­der­stand­ing of what he's do­ing.

Im­por­tant note: the chart of the skills of the per­son is pro­ject-de­pen­dent, since it strict­ly in­volves the skills di­rect­ly use­ful for the pro­ject. In the pre­vi­ous ex­am­ple, if the per­son is pro­fi­cient in C, his C skills are most­ly ir­rel­e­vant, and won't fig­ure in the chart.

So we got those charts for sev­er­al can­di­dates. How does it helps us choos­ing the one we'll hire?

Most pro­ject will val­ue can­di­dates with a de­cent ex­per­tise lev­el for the pri­ma­ry skill, a cov­er­age of most tech­nolo­gies used by the pro­ject, and a smooth falloff. De­vi­a­tion from one of those three as­pects would prob­a­bly lead to sub-op­ti­mal pro­duc­tiv­i­ty.

But what about “T-shaped” peo­ple mod­el? It was mis­un­der­stood. Valve is not just an­oth­er soft­ware com­pa­ny, and their mod­els don't nec­es­sar­i­ly ap­ply in oth­er com­pa­nies. Valve's hand­book is very clear about the in­ten­tions of their mod­el:

We val­ue “T-shaped” peo­ple, that is, peo­ple who are both gen­er­al­ists (high­ly skilled at a broad set of valu­able things—the top of the T) and also ex­perts (among the best in their field with­in a nar­row dis­ci­pline—the ver­ti­cal leg of the T).

This recipe is im­por­tant for suc­cess at Valve. We of­ten have to pass on peo­ple who are very strong gen­er­al­ists with­out ex­per­tise, or vice ver­sa. An ex­pert who is too nar­row has dif­fi­cul­ty col­lab­o­rat­ing. A gen­er­al­ist who doesn't go deep enough in a sin­gle area ends up on the mar­gins, not re­al­ly con­tribut­ing as an in­di­vid­ual.

Two things should be high­light­ed here:

• At Valve, it is not a ques­tion of be­ing a good Java de­vel­op­er. It's a ques­tion of be­ing “among the best in their field,” which is not the case of 99% of soft­ware de­vel­op­ers (and I'm ways too kind here).

• The gen­er­al­ist as­pect Valve wants from their em­ploy­ees is not need­ed to force peo­ple to work with stuff they don't mas­ter. The goal is to en­sure that peo­ple don't have dif­fi­cul­ty col­lab­o­rat­ing. With­out ba­sic un­der­stand­ing of oth­er do­mains, col­lab­o­ra­tion with peo­ple work­ing in those oth­er do­mains will nec­es­sar­i­ly have a neg­a­tive im­pact.

This has noth­ing to do with the goals of oth­er com­pa­nies, who need spe­cial­ized per­sons who are also able to han­dle them­selves tasks from oth­er do­mains. For Valve, “T-shaped” peo­ple is the ap­pro­pri­ate mod­el; for oth­er com­pa­nies, it is only mis­lead­ing, and should be re­placed by the falloff mod­el I pre­sent­ed here.