Why T-shaped people? (2018)

Tangent, but what is it with corporate teambuilding and this sort of games? I had to participate in one where people had to crawl on the floor, blindfolds on, while the "master" gave commands....... I mean come on, sounds like a fun evening, but in that context it left me quite uncomfortable.

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.

That said, your example merely indicates that corporate workshops are bullshit. It does not contradict the value of T people.

In my experience, two highly specialised but disjoint people can only produce rubbish. This is where you need some entry-level intersection of knowledge.

In your case, I don’t expect a FE dev to care about persistence, nor a BE dev to worry about form validation. But both need to be aware of the customer, the business, and robust API design.

If you are large enough for corporate training events, chasing T shaped people probably isn't that important.

If you work on a product team then it really helps to know a bit of everything, architecture, writing frontends, writing apis, databases, designing scalable services, managing hundreds of servers and other infra through automation, ci/cd, data engineering, ux, testing, talking to users, talking to stakeholders, gathering requirements, managing a project, managing yourself. From time to time you may ask the help of an expert.

It was bad implementation clearly. You don't get to be generally good at different stuff without first being a lowish worker on each of those, having a person to hold your hand. You can't just declare that everybody should do anything after 2 hours of generic presentation and call it a day.

I believe you, but I have so many questions. Where the devs prevented from chatting with each other before starting to hammer on the keyboard? Were the backend devs not curious when they had to import a new dependency (jquery in this case)? Who did the code review?

Having a backend dev do frontend is not different from a junior employee starting at the company. People have to support them, with advice, tips and reviews. Did the company failed at regular onboarding this bad too?

Honestly the whole thing sounds like malicious compliance. People didn't want to do a thing and they made sure it will be done badly.

A single anecdote of a misguided manager ruining it for their team does not invalidate the idea of T-Shaped people.

So suddenly the graphic designer is writing HTML and CSS, the front-end developer starts writing SQL queries, and the product manager starts writing JavaScript.

The experiment lasted about a month with a lot of hurt feelings, because essentially all the code just had to be totally reverted.

The graphic designer knew how to write CSS for his browser and screen resolution, but didn't have the faintest idea how to deal with window resizing, browser quirks, unexpectedly long text, or how to integrate with our established frameworks at all. Just threw a lot of CSS straight into "style" fields instead of CSS files. The SQL queries fell apart in production because the front-end developer didn't know how indexes worked at all, or to aggregate values on the database server instead of client-side. While the PM's JavaScript was similarly just modifying the DOM directly instead of using the framework, leading to total spaghetti code (and global variables everywhere).

The worst part wasn't even the wasted time, but the damaged personal relationships. Because nobody had even the level of expertise to understand why their code had been reverted, so they blamed it on politics instead. The PM thought it was totally unreasonable to require usage of the framework, the front-end dev blamed the database architecture because indexes didn't seem like something anyone should have to deal with, and the graphic designer similarly could never be convinced of any good reason why CSS shouldn't be inlined into HTML. All of them wound up blaming the actual team member experts for getting jealous of their turf and trying to unjustly sabotage the new people's contributions.

Just a disaster all around.

Now obviously that was kind of a worst-case scenario. But nevertheless, ever since I've been extremely wary about people picking up development outside the area of expertise they were hired for, simply because people don't know what they don't know. In other words, they don't even ask to get assistance on how to do something properly, because they're totally unaware there's a proper way that's different from what they just naturally hack together.

It makes sense in single team context, say one person being very good at SQL but rest of the team having some basics will mean most of the "simple" tasks related to can be done by anyone instead of shoving everything onto expert.

Or say having just enough frontend skill that backend team can create their own internal admin panel for a service without involving frontend/UX in it and paying communication tax.

Fast forward to 2020, when I went from a 60 person startup to working at AWS in Professional Services where I do the same type of enterprisey things as a billable consultant, I realized that in most of those areas, there are plenty of people who can run circles around me.

But, my “specialty” is that I am a generalist and can go into your typical enterprise and talk to everyone in the organization from sales, to finance, to security, to developers, to the infrastructure people, etc and I’m self aware enough to know what I don’t know and know when I need to bring in a specialist.

I think it can be beneficial to show people where you can start learning a new subject but they have to choose to learn

Yikes, what a terrible take. To me, "T-shaped" people have at-least-minimal competence across a broad spectrum of the business. They don't do the work of other specialties, but they use their knowledge to avoid making excess work for those other specialties -- for instance, they make better-informed suggestions in brainstorming. Your backend devs know how the frontend stuff works, so they don't make tortuous APIs; they know how QA operates, so they plan for testability; they know the pitfalls of UX so they don't make rigid state-machines that punish users. And, if a disaster strikes and a team needs a helping hand in a pinch, maybe somebody with some depth outside of their role can pitch in. Making everybody do everything always is not T-shaped, it's, I dunno, #-shaped.

> Dave Rooney uses a metaphor of “icicle-shaped”, that is, people who pick up whatever skills they need when faced with a problem to solve. This matches more closely to how I actually operate. https://medium.com/@daverooneyca/icicle-shaped-people-45f364...

And, of course, since software has been eating the world, domain knowledge about the field in which your software is actually used is one of the most valuable traits to have, because it matters very little how perfect and elegant your solution is if it is a solution to the wrong problem.

If you commit to maintaining an expertise-level of knowledge in all the domains you mentioned, you're going to spend 75% of your life reading instead of doing.

I like to say that my skillset follows a pareto distribution. That is, roughly 80% of my knowledge is accumulated to the top 20% of my areas of interest. But that doesn't mean I suck at the bottom 80% of my areas of interest. It just means that I'm fully committed to constantly bettering myself in my core domain (in my case, front-end development), and also keeping up to date with the latest advances.

I also know how to work with databases, and I'm somewhat familiar with newer ideas and trends (Snowflake, Planetscale, CockroachDB, etc). But aside from some basic marketing copy, I couldn't really explain why these new databases are any better than what we had previously. And I certainly wouldn't want to be trusted to make a decision on which one to use. I know I could figure out how to work with them, and I'm content with that.

And then I started working at a company where there are actually people who are considered some of the best in the world in every conceivable area that I thought I was good at.

Every week there is an announcement about a new service or feature at AWS. For instance, my specialty is supposedly “serverless”. I didn’t know that Fargate (serverless Docker) supported Windows for over a year.

Even if you think more generically like front end development, there is always something new.

What about body building? You aren't T-shaped with a broad base and shoulder?

Similarly, π-shaped skills (after the Greek letter pi) refer to "a broad mastery of general management skills atop a few spikes of deep functional or domain expertise".[5]

what is this MBA gobbledegook

Once a client demanded that we worked with some encryption framework that required open ports. A delegation of the crypto company had to come to spend the day and hold some meetings because the networks people couldn't take my word for it.

All I can do at decent level is computer related stuff, call me one trick pony.

Meanwhile I know people who are perfectly capable making money of truck driving, drilling, a lot of construction related work, simple mechanics, and a lot of more.

The drawback was that they were pretty much only interested in that specialty. They might be curious about other things, but they were genuinely happiest doing what they loved.

I specialize in solving problems.

I've never found anyone with my capacity for researching, understanding and quickly putting together a plan to address some exigency.

Whether that be triaging an issue in an opaque production environment or crafting a marketing plan to help tell the story of what my local community does well, that's what I specialize in.

Sometimes it's a true passion for a field, other times it's because there would be so much friction switching tools or learning the internal standards and tools of a business. For instance programming means not only coding, but also familiarity with the tools, libraries, and coding standards of a coding shop, which take time to learn.

Sometimes it's just due to human nature, that larger organizations become silo'd, and practicing two skills means navigating the politics of two silo's, twice the number of meetings, etc. Also, if you belong to silo A, and help out with B, then the manager of A gets annoyed with you. So in a sense specialization is a way to find a comfort zone in a typical human organization, even in what are considered to be good workplaces.

This shift is so far limited but important, it means some have realized too many have lost the big picture and we need it to keep anything working well...

It's very difficult to become one of the best in one field, but it's much easier to become one of the best in the cross-section of two fields.