#t-shaped

At 9:20:

So for example, I'll give you at LinkedIn we used to have product managers, we had designers, we had front-end engineers and then we had back-end engineers and so on. So what we did is we sort of took those first four roles and combined them. In fact, increased scope and said, let's they're all full stack builders. So I like that because that's a structural change that allows for us to increase the change both the work and the workflow between these functions.

at the same time as you can imagine if to build an AI product today there's a complete new workflow right it starts with eval right so basically there's this eval to science to infrastructure and so eval are done by these full stack builders and what have you and product managers in the new form. The infrastructure is built by the systems engineers at the back end because they support the science that supports the product.

So in some sense there's a new loop uh and you have to structurally change and so a lot of what is happening inside a tech is that change uh which is I think going to be pretty massive uh and at the same time a company like ours I have to do everything it's not like I can just so go live in the future I have to make sure we're doing a fantastic job of doing hot patching on Windows is done with quality uh while at the same time building the evals that are improving co-pilot quality right and so both of those have to be first class. – Satya Nadella

The business needs engineers that can adapt to the dynamics of the modern world. Professionals that are self-sufficient and won’t go into paralysis when the DevOps is out on holiday. Ideally, any person in the team should fill any other role if needed - from small tweaks on the UI, to debugging the CI pipeline.

This is easier said than done, though. Acquiring the skills to be productive in multiple areas requires years. You also need to be exposed to different parts of the product. A company with strong silos between teams won’t give you that opportunity.

At the same time, when complex work needs to be done, a team of generalists may lack the experience to take proper decisions. When the database’s performance needs improvement or architectural decisions need to be made you need a person that’s deeply focused on that topic.

The evolution of software development methodologies required a new kind of engineers - specialised generalists.

Thus, the term “T-Shaped Specialist” was coined. It is used to describe a person whose knowledge distribution looks like the letter T. The horizontal line describes a broad working knowledge in multiple areas. The vertical one is for specialization in a topic.

A back end engineer who can put up their own interface, style it reasonably and deploy it may fall into that category. A UI engineer that can spin up an Express service when needed and can debug an API endpoint could also be considered T-Shaped.

Having a team of specialised generalists means that work can be prioritised without worrying about the available developers. This breaks the silos around teams and helps everyone to get more involved in the project.

Problems of T-Shaped Engineers

Having T-Shaped specialists is not a silver bullet. It doesn’t mean that anyone can do any job and do it well. While they have broad knowledge this doesn’t mean that they can perform exceptionally everywhere.

The business may sometimes falsely expect such engineers to be experts in everything. T-shaped engineers can adapt and get up to speed with different technologies. But they still have a main area of focus.