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.
I just had the same in the opposite direction (to an extreme degree, hand waving away an enormous amount of complexity). The blade of Dunning Kruger cuts both ways.
Though what you describe sounds awful too. Hopefully with the recent era of tooling and discipline on the frontend side, we'll see less of that.
Yes, that kind of arrogance can definitely come from the front-end side as well. I've just noticed a pattern with a certain type of back-end developer. Similar to the old XKCD physicist comic, there is a personality type that seems to think they can spitball an ad hoc solution to a problem that is better than the work of specialists in the field.
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.
I think T-shaped people are usually specialists-turned-generalists, for example good software developers who later on became managers. As a manager you have to be a generalist, and you usually have hundreds of small tasks, so no deep dive in one topic, but surface level in many.
In my experience these people are definitely better managers (unless they suffer of old physics prof disease), but I don't see the large benefits for more specialised roles. The more I switch to being a generalist, the less I can actually deep-focus, and talking to friends and colleagues, it doesn't seem like I'm the only one.
That said, interest and curiosity about other fields, especially the ones you actively work with or neighbour is probably always a great quality to have.
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.
Well the team obviously wasn't thinking about a lot of things.
But it had nothing to do with an open channel. Everyone was literally sitting next to each other. But my point at the end was that it doesn't solve anything because nobody even thinks to ask in the first place.
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.
That's what it is. You do scrum, you write your code, you do the work of 4 but earns as one.. and that's because its fun, t-shaped people don't like to stay in their comfort zone. /s
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.
V shaped, or U shaped, people get mistaken for I shapes (man, how I love those management-sized oversimplified concepts, especially those putting people in boxes) when only one side of the U/V is used. Has all kinds of funny side effects, my personal favorite is when people realize, after having classified you as a I, that there is more to you. And then, using the biggest about faces possible, to recognize it, because of course once you are classified as something this cannot change.
I've got a background in Agile consulting (yeah, sorry), frontend work from way back in the day, and low-level systems and optimization work. None of this is factored into my current job, and I've lately been labeled the "database guy" ... when that's one of my newest and not particularly impressive competencies.
I still have yet to find a way to manage external perception of my abilities to even a minimal degree. Very draining.
In my current job, I just gave up on it. I am the "process guy", and lately, due to pressure from IT (of all people, since I am in Supply Chain Operations), the "ERP guy". The latter I did last 10 odd years ago, the former is a side effect of thinking about why things in my domain are the way they are, some lean training and, mainly, being good at operations. Operations being, I'd say, my true core competency from which everything else is fed.
No chance to sell that where I am now... I'll see what I do about it come Jan.
> 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.
Even more fundamentally there are people who at Amazon, Google, and Microsoft who are
- creating their own languages that are used by millions
- writing and optimizing databases used by millions
- writing a custom micro VM (the open source Firecracker project that is the basis of Lambda)
No matter how good you get at any of these areas, unless you focus on one, you will never be as good as someone who eats, drinks, and breathes those things everyday and have to make sure they scale to millions of transactions
Sure, I can optimize a database for a small to medium size company. But when I reached the limit of my knowledge and skills, it’s nice to be able to reach out to the team that makes sure that the databases underlying Amazon retail are running smoothly.
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.
Maybe I didn't understand the article correctly, but are there any people, especially on HN, that identify as specialists? By that I mean, they only know one skill, and that's it, they don't consider themselves T shaped.
I’ve hired plenty. They were sometimes the best engineers at my company, specifically at executing tasks that were very difficult but they were experts at, and others would have had to take time to spin up and learn the art.
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.
Reminds me of that joke story about a needle-point sharpener guy who's better than anyone else in the world at it, but then surprised when he accidentally learns about the needle eyes. After all, the needle eyes are not his specialty, he's not required to know about them!
I've seen a good amount people that identify themselves as DB people or QA people or sysadmins and wanted to know nothing outside their corner of the woods. As in "don't even explain that to me, just do your part" that was often a source of problems.
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.
Maybe the militant single domain focus posture is not driven only by personal values but has something to do with how organization pressures and rewards people? Chastising people for doing things out of the scope of their responsibility is a thing I hear.
That's me most of the time. I used to describe my position as troublemaker. Of course I also used to do things to compensate that perception.
Anyway, whatever the reason, for the company it's interesting to have both the right people and the right policies.
I'm not sure what made that people not even wanting to take a look at firewall permissions. It was obvious that the ports were closed. Actually I learned that my workstation had a public IP address, totally useless anyway because all ports were closed from the outside.
If you don't forage/cultivate your own food, weave your own clothes, and build your own shelter, you're a specialist. All humans are specialists and this is probably our single biggest evolutionary advantage. The trend toward increased specialization is obvious to me so this and the previous discussion about being a generalist vs. specialist are strange.
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.
This comment reminds me of a great article I read ages ago and had to track down. When you're deeply focused in one area, you're most keenly aware of all the aspects of that area that you aren't an expert in. For example, I consider myself to be a complete novice at relational DBs, but from the perspective of your example truck driving, drilling, construction working, mechanic, I might as well be an expert. I guess it's important to keep in mind the scope domains that you're considering for any given situation.
hmm, I didn't meant expert level, just proficient enough to be able to make money off it, so not very low bar, but as you pointed - probably not expert.
I think yes. I have colleagues that are in certain fields because those things really are their passion, and they want to get as good as possible at them. For instance a mechanical or electrical engineer who really doesn't care what the GUI for using the product is going to look like.
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.
> are there any people, especially on HN, that identify as specialists?
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.
Recently I went through a phase where I volunteered extensively with the expressed goal of teaching others something to which I'm privy from which they should benefit. I learned more my students, specifically that the exercise was largely wasted time. The uptake by the recipients just wasn't there.
I don't write for the benefit of others, but I do write for the benefit of me, to keep that skill sharp.
I'll tell you my secret sauce, which is being gifted with some intelligence and applying oneself relentlessly. It's a straightforward recipe for success and it's only remarkable in an ocean of mediocrity.
I worked at a small company for 7 years and had to work with databases, server management, product ownership, front-end/back-end, styling etc. With only 4 developers, we all were expected to do everything. I always thought this was normal expectation for a full-stack developer.
Then I switched jobs to a bigger organization and became surprised by the number of people who claim to be full-stack but are uncable of developing an application from nothning.
This is very common coming from small shops and moving to larger orgs. I am happy to have started my career gradually going from very small to medium to larger orgs. I think it's made me a much more well rounded dev. A lot of people that go straight into very large organizations have the disadvantage of narrowly focusing on a piece of software and often their learning is slower because of organizational complexity. At (good) smaller companies you have much more freedom to experiment and make mistakes, which is essential for learning fast.
The first time I heard this term was around the same time as the article (around 2018) from a couple of McKinsey folks who were consultants to our company.
That was some of the top rate BS I had to encounter.
The elephant in the room for almost every management-type article you ever read is that they're all correct: you just don't have the space in your head or the minutes in your day to implement five hundred different good ways of doing things.
That, and resources. Every company would like to have a top tier dev team, and a top tier sales team, and competent managers at every level, and a hundred other things. But those things cost tons and tons of money, if they can be found at all.
A thing have changed starting from few years ago: while before people prize specialization as the best route for anyone now some start prizing generic vast knowledge.
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...
Any reasonably large organisation probably needs both types of person. There’ll be the deep problems that require a true specialist to deal with (Netflix blogs about optimising network transfer spring to mind here), and people with broad experience who can bring that to bear on new problems, put together prototypes, and understand which specialisms to involve as it develops.
There’s huge value in understanding the entire stack in the early stages of development so you’re not having to rope in five different departments just to get something live, but you also need to know when you’re out of your depth and it’s time to call in the people who do nothing but deal with a small subset every day.
That's sure, but I mean the "general adage", most current narrative is "specialized is good, cool, the way to go, nobody want to be generic, ..." while actually all rulers, broad leaders etc need to be generic.
To seems like keep crying "do not be rich! It's bad!" and now I see something I call a small reversing trends where more and more sources start stating "we need more generic/wildcard/T-shaped/$choose-a-label-not-to-say-generic-directly". I call it "a bit late, but still good".
The value of T shaped people is overhyped. We know the benefits of in depth study in an area as well as entry-level study in many areas: eased collaboration, cross-disciplinary thinking, etc. My problem with T-shaped people is not the concept, but that the concept doesn't go far enough. I have at various times used the phrase 'Pitchfork People' and 'M-Shaped people' to represent what I think our goals should be. M-shaped people have an entry level understanding across a broad area of subjects, preferably cross-discipline, and a deep dive specialist-level understanding of two and possibly three areas.
Heinlein said it best, "Specialization is for insects"
If it takes X years experience to gain I-shaped expertise and Y years experience to gain generalist expertise, it should follow that it takes roughly X + Y years to gain T shaped expertise
It might not be exactly linear, but you should consider that by committing to a team of T shaped engineers you’re also committing to a team of very highly qualified and very expensive engineers.
I was greatly disappointed - I was expecting an analysis of the T-shaped monoliths at Gobleki Tepe which are adorned with carvings indicative of them representing people. I have suspected for years that the peculiar "T-shape" to the heads was due to the columns being used as supports for a wooden roof which has long since disappeared, and the humanization carvings were just secondary decoration.
Ah well I didn't even know there was a loop to be so far out of...
Does anyone feel like this model is stretched really thin? Like, tech has a problem of easily identifying who's competent or not and has to do tech interviews to (try to) establish that.
I feel like establishing if someone is an expert or represents one of these shapes is going to be even harder.
First time I heard about T-shaped people was at a course at Stanford University in 2010s.
The idea was that you could be an excellent biologist or developer, but you always need the transversal skills like interpersonal communication, public speaking, entrepreneurship...
The definition of a t-shaped person here is wrong. I always understood it as: An individual who has empathy and ability to collaborate across disciplines coupled with deep knowledge in a specific area. Based on Tom Kelly (IDEO), probably 2005
Based on the EU job postings I browse on LinkedIn, since hiring freezes started there is a trend towards hiring specialists over T-shaped guys. 2020-2022 was a T-shaped heavy market.
The main benefit of being T-shaped is that you can innovate more effectively within your area of (deep) expertise. Since you have a good understanding of the solution space and a “good enough” understanding of the problem space you can search from both sides so to speak, finding the most valuable problem that can be solved economically.
It’s very hard for an I-shaped engineer working with a (problem) domain expert to be as innovative: no matter how much they communicate it will always be a tiny fraction of the internal bandwidth of a single brain.
If you start looking for T-shaped people, you can be sued. The Tetris Company owns the copyright and trademark on all seven tetrominoes. And why waste time? All you need is the 10x "Heaven" person: https://xkcd.com/888/
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.