Maybe we should call this U shaped people: Multiple specialisms. For me, T shaped people know their speciality, but know enough of the surrounding context. I'

Maybe we should call this U shaped people: Multiple specialisms. For me, T shaped people know their speciality, but know enough of the surrounding context. I've seen people write technically perfect but practically useless software, because the program didn't fit the business context. I've seen installation horrors where devs and infras took weeks to do a simple deployment, because they couldn't describe to each other what network config needed to be done or what was possible. And of course, the architects that used to be good devs but are now locked in an ivory tower and have no idea that their specs are unusable expensive dreams. So for me, T shaped people can communicate to other people. They do their thing, but can explain how that thing fits in the whole. They can troubleshoot outside their part if the stack. The boundaries between specialities should be owned by multiple people instead of nobody, and T shaped people make this possible. This mostly depends on the organization. If you have only access rights for a tiny sliver of the system, you can only be an expert. If technology swaps faster than your underwear, you can't specialize. If people don't get a chance to fail and grow, they won't become neither specialist nor generalist. So a T shaped course should be given to the CxOs and high level managers as they are the ones who can make it happen.