I was working a corporate job a few years back and I guess our boss heard about the benefits of "T-shaped" people / teams.
Anyway to improve productivity it was decided the whole dev team would participate in a half day training course about "T-shaped" people. It was your typical corporate training nonsense, a hour of watching videos, weird team activities including making animal noises with blindfolds on, playing with lego, etc.
The training was concluded by explaining we should no longer pigeon-hole ourselves to duties that fit our job description and if we have capacity in our sprint to pick up other duties.
The whole thing was a disaster. We had backend devs doing frontend development with jQuery when we were using Vue. Frontend devs started doing UX design and things looked like trash. QA was done by basically anyone so as you can imagine bugs started appearing everywhere.
I think this is one of those things that makes sense in theory, but is kinda hard to implement within a corporate structure. As a generalist and someone who came from a startup back ground, I used to find the way corporates pigeon-hole individuals into specific roles quite constraining, but I've come to appreciate that having experts and very explicit duties does make a lot of sense from a quality and accountability perspective. Smaller companies and teams can probably benefit from having their employees wear different hats, but in larger teams I think it's good to exploit the specific expertise of individuals as much as possible.
> We had backend devs doing frontend development with jQuery when we were using Vue.
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.
Having worked on both sides of the divide, I can say it's sadly common for back-end devs to underestimate the complexity of front-end development and discount the advice and opinions of their front-end colleagues. I've even seen scenarios where back-end devs were allowed to dictate standards to their front-end peers just because they had more seniority in the company.
Sounds like a very hostile environment. In my team we learn from each other and have fun doing so.
Some times managers do things to shake things up a bit. Some times they are right, some times they are wrong just like ordinary humans.
But what it takes to ruin the environment is not always a poor manager but just one stubborn grumpy senior dev who refuses to comply, and get some people along with him.
That training sounds absurd and forcing people switch roles for a sprint is worse.
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.
I'm not sure that's "T shaped" as much as it is "cross functional", which can be done without requiring anyone to know about anything outside their silo, as long as someone crosses silos and communicates. That's more of a systems engineering model, where a specific role forms the bridge and only the bridge, and specialists form the teams. It's a very Aerospace model of doing business.
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.
If you're part of a software factory and only turn a psd into a html/css website then yes, knowing a programming language and doing backend doesn't help. If you work at a company which sells expertise to others, then they will want you to be an expert at something.
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.
Well if you interpret it as "do completely different jobs of different teams" of course it doesn't work.
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.
This comment is a classic example of misreading the philosophy behind T-Shape people. T-Shape or 'paint drip' people is a term used for generalists who have acquired a diverse skillset during their career and how these generalists have an upper hand over a specialist in certain domains. The book Range by David Epstein also goes deep into this philosophy.
A single anecdote of a misguided manager ruining it for their team does not invalidate the idea of T-Shaped people.
I'm here to bump the book Range but for me T-Shape theory is more about Tetris for Teams so you have overlap at the conversation level and enough depth in the direction(s) of travel. My hot take is Management Theory by 2D Shape Jargon is going to find its stride so in a few years xyzGPT will be classifying us as hyper-dimensional dodecahedrons anyway. /s.
But T-Shaped people are specialists aren't they? That's the | part of the T. Specialists with enough curiosity and flexibility not to be afraid to go beyond their expertise and get a surface understanding of many other things that might indirectly enrich their core competency.
At least that's how I understand it.
Unlike generalists, they have gone through the tough process of going very deep into something. They understand that there's a lot of detail under the surface of any domain and they know how to get there when needed, whereas a generalists would disregard or be ignorant of any complexity.
Ha, I had the exact same experience a bit over a decade ago! Only it came from a total misunderstanding of what agile teams were supposed to be, the idea that anybody on the team should pick up any story they wanted to.
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.
This sounds to me like your team did not think about what it means work together.
Particularly now with so much technology support from remote working you can just keep an open channel. As soon as you get stuck or want to ask something, you just share your screen and ask for some help. Not much more difficult than that.
This reads like nobody involved knows about code review and just commits straight to master. 'Hey this sql is fine but slap an index on name field' is not some shocking development if you just had three rounds of refactoring of a piece, let's say CSS. Or Java.
>It was your typical corporate training nonsense, a hour of watching videos, weird team activities including making animal noises with blindfolds on, playing with lego, etc
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.
> I think this is one of those things that makes sense in theory, but is kinda hard to implement within a corporate structure.
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 spent most of my career until mid 2020 at small companies. I was “good enough” at pre-sales, writing SOWs, project management, designing and developing your typical enterprise online or analytics/ETL solution, “polyglot persistence”, “DevOps” at least if you gave me an empty AWS account and admin access, I could create your “Well Architected”, “12 factor architecture”, etc.
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.
It’s valuable at the management level when dealing with cross-disciplinary teams. You don’t need to understand what any one individual function does to any real depth, but you need enough passing familiarity to ensure the team works well together and focuses on the right components.
> We had backend devs doing frontend development with jQuery when we were using Vue. Frontend devs started doing UX design and things looked like trash. QA was done by basically anyone so as you can imagine bugs started appearing everywhere.
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.
that's what full stack developers are all about. You should do everything. From planning to deployment. From backend to web design. Tune your cluster and fix your CSS.
I heard about T shaped people before, and several years ago, I thought, why stop at T? I wanted to become a block shaped person. I wanted to be like the autodidacts and polymaths of old, Newton, da Vinci, Franklin, and I wanted to know as much as I could about as many things as I could, at least in the software world.
Since then, I started teaching myself concepts from the ground up in any software field you could imagine; compilers, programming language theory, category theory, functional programming, low level embedded systems, front end web design and development, backend development, devops, networking, data structures and algorithms, databases, distributed systems, operating systems, you name it, I've done at least some of it. So far it's been the best intellectual investment of my life. I just know so much about how stuff works now that I didn't before and it feels great.
I'm also interested in entrepreneurship and building SaaS products, so I also had to teach myself sales and marketing, product design, the UX process including interviewing potential customers, and so on, which are whole fields in themselves, but now I can confidently say that I can design and code a product from scratch, market it, and have a decently high chance of it being successful.
If anyone else has the time, I highly recommend getting acquainted with these various fields, you may think they're unrelated but you'd be surprised, I've often found overlap between disparate fields where they fixed the very problem I was facing in a different field.
TBH, familiarizing oneself with several subfields of a single field is still not very polymath-y though. Of course, all fields are just much bigger than they were in the 15th or 18th century, so this is more difficult if you want to be actually useful, but IMO being a real polymath still entails being knowledgeable of various disjoint subjects. Like poetry, marine biology, and systems programming.
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.
> TBH, familiarizing oneself with several subfields of a single field is still not very polymath-y though. Of course, all fields are just much bigger than they were in the 15th or 18th century, so this is more difficult if you want to be actually useful, but IMO being a real polymath still entails being knowledgeable of various disjoint subjects. Like poetry, marine biology, and systems programming.
Agreed, which is why I tried to limit it to CS only. If I were to do it for many subjects, that'd be impossible.
I think it's important to note that the OP totally agree with you and even provided a link to a better suited metaphor in the last section of his post.
> 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...
Hm, this is not exactly how I went about it. I didn't actually have a problem I needed to solve, I just followed the topics due to an innate curiosity, so I'm not sure that Rooney's definition fits mine.
I honestly don't think it's possible, and I don't think what you've described is a block shape. You can gain near-expertise in all the fields you mentioned, but true expertise means keeping up with the changes in your relevant area.
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.
I think the best professionals I have worked with have been "wedge-shaped" people, not "T-shaped." People who are very familiar with their area, still intimately familiar with surrounding concepts, less familiar with things around that, and so on. Interestingly, I think this kind of person often gets mistaken for being "I"- or "l"-shaped.
> I honestly don't think it's possible, and I don't think what you've described is a block shape. You can gain near-expertise in all the fields you mentioned, but true expertise means keeping up with the changes in your relevant area.
> 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'm more so talking about the fundamental concepts of these topics, such as implementing an OS or database from scratch, rather than the latest trends in the fields. If there is a major trend then I'll look into it. Taken that way, it doesn't take as much time as you might expect, since it's not about learning and using the latest libraries, it's about things that haven't changed for 50 years, like database ACID transactions.
I also thought I was very good at a lot of different areas.
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.
Well, I'm talking more about the fundamentals, like implementing an OS or database from the ground up, which most people don't necessarily learn, rather than using the latest library.
Teach Yourself CS [0] is a great resource. For other fields, I just went through courses on Coursera, MIT OpenCourseWare, etc or the various recommended books and followed along. For example for learning about interpreters, I'm using the book Crafting Interpreters [1] and doing it in Haskell, learning it from the book Haskell Programming From First Principles [2].
If you go to any school's CS degree program and go through their list of courses, you can basically do them for free by watching the videos and doing the assignments. This is what Scott Young did [3].
Rather than trying to be T-shaped, I think it is better to be curious and follow up learning paths on those innate feelings for exploration. Maybe your skill set becomes fractal looking. I think this can be the basis for unique value creation. (E.g. the typography course Steve Jobs did as a student, leading to care/attention to fonts on the early Macs).
I do agree with the basic idea of being T-shaped, however. I've personally seen project teams having fragile delivery capability due to a lack of skills, or lack of skill overlaps, which made the team reliant on individuals that could be off sick, on vacation, or assigned elsewhere.
My first boss talked about "F shaped" people and encouraged me to try and develop in that way. I later discovered he was paraphrasing and extending this "T shaped" idea.
This was originally described by Tim Brown of IDEO [0] fame, but as the OP explains has been extended and adapted since.
I think it's a really good thing to consider earlier in your carrier, helping to enable you to be a better, rounder and more valuable contributor.
In many ways HN has helped me to develop as a "F" shaped person, the breadth of content on here is invaluable for developing a wide area of knowledge. But also the depth of insight available can pull you in and take you on a development journey where you become an expert in an area.
X-shaped for leadership
I-shaped for individual depth-skill without communication skills
tree-shaped for a person with depth in many areas or branches of a field
Multiple Mountains shaped (coined by Forrest Z. Shooster) for individuals with depth in overlapping several fields rather than a shallow depth in many or a singular depth in one field who specialize in the overlap between those fields
Γ- and Μ-shaped individuals (gamma and mu, respectively) have been described by Brittany Fiore in her ethnographic work of data science research communities to indicate people with supporting strengths in computationally- and software-intensive fields.[3][4]
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]
T-shaped is good, but preferably skills are organically acquired. In my previous work, the T-shaped mantra has been naively pushed and used as an excuse to put employees on all sorts of disjoint activities and trainings that took time away from the main deliverables. This caused people to leave. I instead prefer "JIT learning".
JIT learning is a great skill to have but if it's all you do, it becomes unrewarding over long periods of time. There's something very satisfying about executing stuff that you know how to do well, and you're missing out on time spent in a flow state if you're constantly JIT learning. The quality of your work is lower when JIT learning too. Of course if you only do stuff you know well, you stagnate and get bored, so you need to balance it out.
JIT is great if the things happen to interest you. JIT suuuuuucks if you don't like what you're learning and someone is always telling you what to learn.
But even the first situation can fail if you are under constant pressure and deadlines with no breathing room because it sours the enjoyment of learning.
I feel the same. It's also just very mentally taxing to learn on the fly. Because usually, I'm trying to develop a feature and I feel the pressure of delivering on time. I find it difficult to learn even on the best days, and if I'm stressed, it makes it much harder to concentrate.
I like to do JIT on a prototypes and then use the knowledge to fall into flow state when working on the real product.
Once that gets boring time for a new prototypes
Keith Adams worked on kernels at VM Ware. Then virtual machines. Then search performance at Facebook. Then the HHVM implementation of PHP. Then machine learning. Now he’s Chief Architect at Slack. In between he worked on hundreds of little projects that lasted hours or days or weeks. Keith is a Paint Drip Person.
I was a big fan of the T model of skills, introduced by David Guest in 1991: know about a lot of things, be really good at one. The more I taught it, the more unhappy I got with the metaphor:
- Skilled people are good at several things.
- Skilled people’s interests develop over time.
- Skilled people don’t plan their next focus area. Sometimes it seems completely unrelated to their previous focus area.
- Skilled people are always exploring, just for the sake of curiosity.
- Skilled people resurrect interests sometimes.
All of these metaphor fails led me to the paint drip model of skills.
- You draw a brush across the top of the canvas.
- Sometimes enough paint accumulates that a drip starts to roll.
- Once a drip starts to roll, it’s not clear how far it will go.
- You keep drawing the brush across the canvas, regardless.
“Moving the brush” is the curious exploration. Keith reports that he tries a project a week or so, but that most “don’t go anywhere” (I beg to differ). The drip rolling down is an area of specialization. Once it starts rolling, it’s not clear how far it will go. In any case, the brush keeps moving. Eventually the last drip stops and a new one starts.
In my career I often found myself thrown into a situation where I have no expertise whatsoever. That was always a little anxiety inducing.
How is this white midwesterner who knows only English going to handle displaying Japanese ruby text in epubs? Or implement the epub table of contents (TOC) for vertical Japanese? I didn't even know Japanese ruby existed before the task of implementing it landed in my lap.
Thanks top the web, googling, and a few coworkers with a little expertise (and CoreText on Mac OS) was how. I am by no means an expert now in Japanese ruby, or even CoreText, but I love how I am a lot less ignorant about these things too.
Ignorant of PDF until I was told to support it more deeply in Cocoa (Mac OS).
Ignorant of color theory and color management until I was pulled into the ColorSync team.
Ignorant of image metadata, XMP, or even XML parsers until image metadata support also landed in my lap.
Display prefs, display calibrator, Common Cartridge.... It's funny how many things land in your lap when you are a kind of "gofer" for your team, ha ha.
Each time, as I said, I felt disoriented, anxious, worried I would be able to implement the feature. But after so many weeks of struggling, and eventual success, I have come to treasure those experiences.
Just like you, I was once thrown into color science without knowing anything about it. ColorSync helped me a lot in understanding how gamut mapping worked. Thanks for your work.
Readit News
Anyway to improve productivity it was decided the whole dev team would participate in a half day training course about "T-shaped" people. It was your typical corporate training nonsense, a hour of watching videos, weird team activities including making animal noises with blindfolds on, playing with lego, etc.
The training was concluded by explaining we should no longer pigeon-hole ourselves to duties that fit our job description and if we have capacity in our sprint to pick up other duties.
The whole thing was a disaster. We had backend devs doing frontend development with jQuery when we were using Vue. Frontend devs started doing UX design and things looked like trash. QA was done by basically anyone so as you can imagine bugs started appearing everywhere.
I think this is one of those things that makes sense in theory, but is kinda hard to implement within a corporate structure. As a generalist and someone who came from a startup back ground, I used to find the way corporates pigeon-hole individuals into specific roles quite constraining, but I've come to appreciate that having experts and very explicit duties does make a lot of sense from a quality and accountability perspective. Smaller companies and teams can probably benefit from having their employees wear different hats, but in larger teams I think it's good to exploit the specific expertise of individuals as much as possible.
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.
Some times managers do things to shake things up a bit. Some times they are right, some times they are wrong just like ordinary humans.
But what it takes to ruin the environment is not always a poor manager but just one stubborn grumpy senior dev who refuses to comply, and get some people along with him.
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.
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.
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 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.
A single anecdote of a misguided manager ruining it for their team does not invalidate the idea of T-Shaped people.
At least that's how I understand it.
Unlike generalists, they have gone through the tough process of going very deep into something. They understand that there's a lot of detail under the surface of any domain and they know how to get there when needed, whereas a generalists would disregard or be ignorant of any complexity.
I'm not really clear if David Epstein merging the two ideas is the 'true' idea of T-Shaped people in the hive mind of the internet or not.
tldr: T-Shaped could include multiple specialties (which make it not look much like a T)
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.
Particularly now with so much technology support from remote working you can just keep an open channel. As soon as you get stuck or want to ask something, you just share your screen and ask for some help. Not much more difficult than that.
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.
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.
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.
If you are large enough for corporate training events, chasing T shaped people probably isn't that important.
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.
I think it can be beneficial to show people where you can start learning a new subject but they have to choose to learn
Deleted Comment
Since then, I started teaching myself concepts from the ground up in any software field you could imagine; compilers, programming language theory, category theory, functional programming, low level embedded systems, front end web design and development, backend development, devops, networking, data structures and algorithms, databases, distributed systems, operating systems, you name it, I've done at least some of it. So far it's been the best intellectual investment of my life. I just know so much about how stuff works now that I didn't before and it feels great.
I'm also interested in entrepreneurship and building SaaS products, so I also had to teach myself sales and marketing, product design, the UX process including interviewing potential customers, and so on, which are whole fields in themselves, but now I can confidently say that I can design and code a product from scratch, market it, and have a decently high chance of it being successful.
If anyone else has the time, I highly recommend getting acquainted with these various fields, you may think they're unrelated but you'd be surprised, I've often found overlap between disparate fields where they fixed the very problem I was facing in a different field.
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.
Agreed, which is why I tried to limit it to CS only. If I were to do it for many subjects, that'd be impossible.
> 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...
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.
> 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'm more so talking about the fundamental concepts of these topics, such as implementing an OS or database from scratch, rather than the latest trends in the fields. If there is a major trend then I'll look into it. Taken that way, it doesn't take as much time as you might expect, since it's not about learning and using the latest libraries, it's about things that haven't changed for 50 years, like database ACID transactions.
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.
If you go to any school's CS degree program and go through their list of courses, you can basically do them for free by watching the videos and doing the assignments. This is what Scott Young did [3].
[0] https://teachyourselfcs.com
[1] https://craftinginterpreters.com
[2] https://haskellbook.com
[3] https://www.scotthyoung.com/blog/myprojects/mit-challenge-2/
What about body building? You aren't T-shaped with a broad base and shoulder?
I do agree with the basic idea of being T-shaped, however. I've personally seen project teams having fragile delivery capability due to a lack of skills, or lack of skill overlaps, which made the team reliant on individuals that could be off sick, on vacation, or assigned elsewhere.
This was originally described by Tim Brown of IDEO [0] fame, but as the OP explains has been extended and adapted since.
I think it's a really good thing to consider earlier in your carrier, helping to enable you to be a better, rounder and more valuable contributor.
In many ways HN has helped me to develop as a "F" shaped person, the breadth of content on here is invaluable for developing a wide area of knowledge. But also the depth of insight available can pull you in and take you on a development journey where you become an expert in an area.
0: https://en.m.wikipedia.org/wiki/T-shaped_skills
X-shaped for leadership I-shaped for individual depth-skill without communication skills tree-shaped for a person with depth in many areas or branches of a field Multiple Mountains shaped (coined by Forrest Z. Shooster) for individuals with depth in overlapping several fields rather than a shallow depth in many or a singular depth in one field who specialize in the overlap between those fields
Γ- and Μ-shaped individuals (gamma and mu, respectively) have been described by Brittany Fiore in her ethnographic work of data science research communities to indicate people with supporting strengths in computationally- and software-intensive fields.[3][4]
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
But even the first situation can fail if you are under constant pressure and deadlines with no breathing room because it sours the enjoyment of learning.
The original used to be available without needing to log in, but now it appears to be hidden behind a login at https://www.facebook.com/notes/373922293851423/
The text of it:
Keith Adams worked on kernels at VM Ware. Then virtual machines. Then search performance at Facebook. Then the HHVM implementation of PHP. Then machine learning. Now he’s Chief Architect at Slack. In between he worked on hundreds of little projects that lasted hours or days or weeks. Keith is a Paint Drip Person.
I was a big fan of the T model of skills, introduced by David Guest in 1991: know about a lot of things, be really good at one. The more I taught it, the more unhappy I got with the metaphor:
All of these metaphor fails led me to the paint drip model of skills. “Moving the brush” is the curious exploration. Keith reports that he tries a project a week or so, but that most “don’t go anywhere” (I beg to differ). The drip rolling down is an area of specialization. Once it starts rolling, it’s not clear how far it will go. In any case, the brush keeps moving. Eventually the last drip stops and a new one starts.How is this white midwesterner who knows only English going to handle displaying Japanese ruby text in epubs? Or implement the epub table of contents (TOC) for vertical Japanese? I didn't even know Japanese ruby existed before the task of implementing it landed in my lap.
Thanks top the web, googling, and a few coworkers with a little expertise (and CoreText on Mac OS) was how. I am by no means an expert now in Japanese ruby, or even CoreText, but I love how I am a lot less ignorant about these things too.
Ignorant of PDF until I was told to support it more deeply in Cocoa (Mac OS).
Ignorant of color theory and color management until I was pulled into the ColorSync team.
Ignorant of image metadata, XMP, or even XML parsers until image metadata support also landed in my lap.
Display prefs, display calibrator, Common Cartridge.... It's funny how many things land in your lap when you are a kind of "gofer" for your team, ha ha.
Each time, as I said, I felt disoriented, anxious, worried I would be able to implement the feature. But after so many weeks of struggling, and eventual success, I have come to treasure those experiences.