T-shaped knowledge is hokum

You’ve almost certainly come across job adverts that say they look for ‘t-shaped people’.

This is not some weird obsession with people with very broad shoulders. What they mean is they want to hire people who have a broad general knowledge, but are specialised in one or more narrow areas.

t-shaped diagram showing broad general knowledge and deep expertise

The unspoken implication is that if you have a team of t-shaped people with varying deep specialisms, you end up with pretty good coverage of the whole knowledge space required by your team, plus some flexibility in how you work:

multiple t-shaped people with different expertise

This is, frankly, hokum.

Firstly, the unstated assumption is that if you have a deep knowledge of something, and work comes up in that area, that you will be able to just work on autopilot, and you’ll produce amazing work. This isn’t true.

Instead, even when working in an area we are extremely comfortable with, we’re very likely to dip into reference and learning materials to clarify specific use cases. The knowledge provides a nearby base from where to learn new things.

Secondly, the t-shaped visualisation doesn’t represent reality. Knowledge and skills are very much less knowable than we think.

When we estimate the extent of our own knowledge and skills, we get it drastically wrong. W assess others’ skills very innaccurately too.

If we’re going to use a simplistic 2-dimensional view of someone’s skill set, it’s probably more like dripping paint, with more very narrow specialisms, and much less of an even general knowledge baseline.

dripping paint

Deep knowledge isn’t really like this, though. It’s esoteric, specific and grounded in highly individual experiences. Two front-end developers will have very different sets of knowledge and skills, and will apply them in different ways.

Perhaps we need to use finer grained skills to make this model more useful? HTML, CSS and JavaScript? Or do we break JS up into foundations and framework-specific skills? Knowledge of array functions? Specifically how to use Array.reduce? Go fine enough and we’ll end up with a fractal rather than a simple diagram. This just isn’t useful as a representation.

When it comes to hiring and assessing the skills in your team, I’ve come to accept that looking for specific pre-existing knowledge just isn’t very useful.

I’ve seen teams with very little specific domain knowledge work together very effectively to learn what is required. They use collaborative approaches to amplify their learning and make connections across the gaps in their collective expertise. This is why they are more than the sum of their parts.

By the same token, I’ve seen disjointed teams of t-shaped ‘experts’ produce terrible work because they didn’t share their expertise and collaborate effectively to come to a balanced solution. Instead, the work was done in individual silos and preciously guarded from others.

If I were to hire a team today, I would look for signs of potential: mentoring, learning and collaboration skills. Yes, specific expertise is also useful, but only when these other characteristics are present too.

All the best,

– Jim

Receive emails like this in your inbox

I write about front-end engineering leadership every weekday.

Sign up now and get my Front-End Engineering Responsibilities Laundry List PDF for free.

You'll get regular emails about front-end development. Unsubscribe at any time.