Generalists are highly valuable for many types of orgs and projects especially nascent projects. But sometimes you need the precise output of a specialist to achieve something.
If my business has a product that is highly dependent of let's say OpenGL, then an OpenGL specialist will generate more specific output that someone who knows a little of OpenGL and a lot of other things.
However, there's always the counterargument that generalists can compensate with their holistic view and understanding of problems throughout the whole stack. I understand this and agree with it, but I think there's a point in every innovation where the generalist contribution declines sharply. And I'm saying this as a generalist.
If you are a generalist and you feel undervalued, you're likely in the wrong project or too involved in phases of a project where your contribution can't move the needle significantly anymore.
I've had a conversation with a few bosses where at some point I stopped to say words to the effect of, "It's like you think I expect everyone a the project to be like me. I don't." <looks of surprise> A project with just me would have problems too. But every project needs at least a couple of people who think like me, which we aren't accomplishing.
This whole expert thing isn't tenable on a long term project. The expert will get bored and wander off, at which point all the mistakes they avoided will just be explored in their absence. Unless they built up people, documentation and processes to take over the work.
My read of Kernighan's Law, back-ported onto my own philosophy, is that most of the time you don't want the most capable person working on a solution. You want the 2nd or 3rd most capable person on it, have them reach consensus with the other two. Maybe 10% of your code should be as clever as you can manage. Most of the rest should be so boring that only the junior people find it interesting. The bottom rungs of an orchard ladder everyone is trying to climb.
And from then it’s a mentoring role. The expert spends more time PR-ing and adding to the framework than building end product features. They build stuff that touches every feature.
Force multiplier is the game.
Personally I'll take a generalist any day since specialists suffer from the "if you only have a hammer everything looks like a nail" syndrome.
Having said that, my 1 career advice to anyone would be, become a specialist in 1-single thing, and then become a generalist in everything else. I'm not that, but I feel that that I would have been best served if I had been that.
The article isn't saying that specialists aren't valuable. In fact is says the opposite: "If you know exactly what you need, and you need it right now, choose depth." It is just saying that perhaps the short fat engineer would be the one who realizes they need an OpenGL specialist on the team in the first place because the graphics are hitting a bottleneck and slowing down everything else. The author is merely pointing out that in the nascent portion of projects their contributions are, at times, under valued.
to expand on this, I've found most of my happiness as a generalist in early stage startups. to me, a larger company looking for a generalist with no concrete role is a sign that they don't have their stuff together. obviously there are exceptions to this rule - some companies just prefer generalists - but usually once teams get big enough, people settle into specific roles, even as a generalist.
Or that their culture is such that they have entrenched, stovepiped personnel that don't venture out of their specific knowledge domains and they need somebody to bridge that gap.
An analogy that I've used far too often when describing software deployment in traditional orgs is one of the dev team and IT playing tennis with the grenade that is the software. With each volley back and forth they give each other nigh-useless information - the operations team will tell the dev team that it crashed without sending logs and that it's because of random setting X that they pulled out of a hat, then the dev team will tell the ops team that said configuration value is hardcoded but that can't be the problem because it runs perfectly on their dev machine, and so on and so forth. Having somebody to mediate this interaction so that it's actually productive is inherently invaluable to, y'know, getting actual work done.
Unfortunately it's not particularly valuable from a business perspective because if your org is operating this way then it means that they place greater value on the performance of "software engineering" than the actual value added by the software produced. So basically what you said.
Generalists could also be the people in the project who get things done: they may have sufficient domain knowledge to implement the recommendations of a specialist. In poorly-managed or understaffed teams, a generalist might feel a bit frustrated because they're a go-to for any Job That Needs Doing Right Now, even if it falls outside of the field of their deepest experience.
My general take is that generalists would excel in small scrappy disorganized organic teams, while "specificists" would do well in teams with high level of organization and management structure. Unfortunately, large organizations tend to push out generalists, as structure increases, and their value in the eyes of management decreases.
I think a large organization should have both kinds of teams. This kind of alludes to Clayton Christensen's Innovator's Dilemma -- "well managed" big orgs should be internally disrupted by small-scale "startup" style teams, and those scrappy organic type of teams need generalists.
The point is there are less project slots for generalists to be in right now.
That why as another post commented they move into management or product at larger organizations. They get to move the needle and apply their generalist knowledge even to mature projects.
I'm still interested in why engineers who know FAT should be valued more. It seems like an interesting thing to look up
A secondary point is that a correlation between height and cognitive ability existing in a world where children suffer poverty/malnutrition/exposure to lead does not imply that a correlation between height and cognitive ability exists in a world without that suffering, so studies using data from the 50s and 70s might have limited relevance for the present day.
He also used to ruffle the feathers of HR. Once, when a woman from the talent acquisition team tried to give him generic instructions about conducting interviews, he told her “Lady, I don’t need all this, I’ve been doing this since before you were born”. (She was born in the mid-80s.) She reported him to HR, and obviously they didn’t do anything, since he was one of the most valuable engineers at the company.
He had a great breadth of knowledge and experience, and was really good at what he did.
So what you’re stating doesn’t necessarily always hold true.
If lower IQ correlates with obesity ("a 10‐point decrease in IQ was associated with a 1.10‐fold increase in the odds for obesity."[2]) either way - a lower IQ person is more likely to get fat, or the metabolic changes of getting fat negatively affect cognition as well - over a large group of skilled people would you expect thinner people to earn more?
If height and IQ are correlated ("Taller people tend to be smarter. Although the relationship is modest, height and IQ are consistently correlated at ∼.10–.20"[3]), would, etc.
[1] https://www.mdedge.com/neurology/article/193699/alzheimers-c...
[2] https://onlinelibrary.wiley.com/doi/10.1002/lim2.11
[3] https://journals.plos.org/plosgenetics/article?id=10.1371/jo...
IQ doesn't decline with age. Pretty simply because IQ is deliberately determined in an age agnostic way: your IQ score tells how well your problem solving skills are compared to your age group.
Fluid intelligence does decline with age, but most people are said to be able to keep up fairly decently by utilizing (and building) crystalized intelligence. Now, of course, your usefulness as an engineer may very well decline with age. Though there are different roles that you can take on in most organizations. It's anecdotal, but my mother used to be a software engineer until her retirement in her sixties, as well as her colleagues she used to work with when I was a child. They started their careers in the 70s and 80s and most of them never left the field.
Up until around age 35 or so, I was generally very lean and did not get noticably fat regardless of my lifestyle.
I know I haven't gotten any stupider. Hormonal changes are the most likely difference for me.
I bring this up because I think there is a very good analogy to the point that the author is making and the distinction between PM and Engineers. Broadly put, PM's are good at figuring out the theta, and Engineers are good at the r.
I think that with the perspectives that short fat engineers have, they can play enormous roles as "PM" or "Engineering Manager", and definitely as ICs during early stages of startups. But they clearly don't enjoy depth, and this can be counter-productive for that 1% of the time where you really, really want depth.
I don't buy the knowledge vs wisdom thing though, there's plenty of wisdom to be gained from going deep into a subject. I'd actually claim that wisdom can only come from depth - though what depth means is different for different roles.
"Short and fat" is a transitionary state. Staying there is just logistically hard, not to mention handicapping in situations where being deeper in one specific area would help.
I'll go so far as to say that they don't really exist. I'm not sure how you can spend 5 years and not learn at least one thing in depth. You'd have to rotate technologies every 6-12 months and there's not that many technologies.
That's kinda how SV is these days though. It's very common for engineers to jump companies every 1-2 years for a long period of time and the companies very frequently undergo a shift in technologies while engineers are there. So, unless you join FAANG or some super stable company - I could see it being natural from just how the market works that you end up having a very short fat engineering career.
For myself, the only consistent thing from my five jobs over the last 7-8 years is that they've all had JavaScript (actually - one had CoffeeScript but then we migrated to JavaScript when I was leaving) - but that's mostly just because of the nature of web development. In the middle of my sixth job search right now and it's looking to be a backend role that won't be in JS now. So, there goes that stability...
Personally: fullstack LAMP -> fullstack Python + Django -> frontend role with backbone/knockout/angular and majority of vanilla JS and CSS -> fullstack Python + Django + CoffeeScript -> Fullstack Angular + Node -> Backend Node with shift to TypeScript near the end
I'm only familar with the options definition of theta and the reproductive strategy of r. Could you expand? Something like, PM's are good at long term (e.g. our product needs this feature, then this feature) and Engineers are good at fine detail (e.g. the feature should work like this)?
Thus PMs are good at figuring out in what direction to concentrate their effort, and then the engineers make progress in that direction. That's how I interpreted it at least.
I also switched careers 10 years ago. I have found that having this broad experience has helped me to make better decisions, understand different points of view and to work with others better.
But I usually have no ability to directly apply the experience from my first career, and very few organisations would ever want or allow me to. It's a pleasure when I can, but it's rare.
When I tell my friends how I feel about my knowledge and expertise they say I am only suffering from imposter syndrome. May be with more years I do become really good at one or two things.
Skillsets are highly complex assemblies that can't be summed up or generalized. Doing things like that give us the hilariously misguided strategies that make HR folks hand out Myers Briggs tests for culture fit checks. I know for myself that a lot of my skills are actually just fancy applications of thought processes and theory, expressed in code. Trying to box that into this goofy trichotomy will just confuse someone.
It's also what I consider myself. It's basically the result of being a generalist who is also willing to dive deep in order to solve a problem rather than stackoverflow my way to a workaround.
"Key-shaped" might be another word here, for someone who does have an area of focus, but not as extreme as a T shape. For example, someone who does full stack web dev with a frontend specialty, but not so focused on one particular frontend framework.
And the more tools you have used the quicker you can figure out new ones, at least for what you need.
I know just enough of basically everything to get by or as a starting point, but I lack that really deep knowledge that comes from using a small group of skills and tools for years. I feel that switching languages and frameworks and tools and OSes a bunch of times early in my career has really held me back.
I don't mind supporting my team, what I don't like is how companies will structure an entire team as support around one or two people. I am not a rock star but I am still capable of contributing more than "support". I want to build real features.
Especially when I know I'm capable of doing the things those devs do, just maybe not at the speed they do.
I often half joke about how I don’t know any programming languages which is unfortunately kinda of true. I’ve toyed with a lot of languages, including ones that your average developer may not have even heard of, but at the end of the day it’s just toying.
My point is that both the "short and fat" and "spikey" approaches have their pros and cons.
Maintaining legacy stuff.
A lot of companies are focusing on hiring "short fat" engineers. Especially companies having "dev ops" engineering model, where engineers must be able to work on all stages of the product lifecycle - from design, development, testing, to deployment and operations.
This is what DevOps is _supposed_ to be but often not what "DevOps Engineers" are hired to be. In my experience most companies hire DevOps Engineers that are one of two things:
1) Sysadmins that also know Python and whichever public cloud dominates the vertical the company operates in
2) Developers that don't actually develop but spend all of their time managing CI/CD pipelines, SCM, JIRA, etc.
In either case their roles are obviously secondary to the developers that build actual solutions; they are the mechanics for the software engineers, which inherently means that their contribution to the value stream is not holistic and it's just another way of enforcing the traditional dichotomy between people that build solutions (developers) and people that keep them from falling over (operations).
I've held the title of "DevOps Engineer" at least once professionally and when I would talk to recruiters or new employers about a software engineering position they'd often ask me what "got me into DevOps" or why I'm trying to "get back into coding". If you know and like working with dev tools and infrastructure then my advice to you is to be a Software Engineer that does DevOps, not a "DevOps Engineer".
Anyway.
Nice little coincidence seeing your comment suggesting exactly the same thing. Of course, google just calls those people “SREs”...which in the best of worlds is a “Site Reliability Engineer”, in past orgs though it’s really meant “Sometimes Responsible for Everything”
Things are far more challenging these days.
Really, this is why programming languages are my "home base" of expertise. It's the study of formal ideas and their communication.
I think the idea of "you have to spend years and years to know the internals of X" is a bit flawed - you can get quite a good feel in ~6 months that's not equivalent but not terribly far off. If you do "height on demand" for long enough, you end up with a good number of these. As someone called it, a "comb" engineer, if you will.
can you expand on this? i feel like i do this but not quite sure what you mean
By default being extremely skeptical of all things computing related, and general being dour about the mainstream trends also helps. Skepticism is what allows separating the accidental and essential complexity, as some term it. Only learn the essential parts.
I have also seen a lot of people hired in at high pay due to their laser-like career focus and years of experience in just the right area, who turned out to embody the peter principle. They lacked the brains and creativity to do anything new and still get stuck when a new twist comes up. Meanwhile I know generalists who are great at figuring things out, and got bored when they had more or less mastered the technology so them move on to a new challenge.
Is staying short and fat really an option? Aren't you always specialising in the problem domain / tech stack that you're currently working with?
The other thing is that you often just need problem solvers where it doesn’t even matter how wide their experience is. You just need someone who knows the basics and is adaptable.
No, it really doesn't. If you haven't ever gone through the work required to become great at something then you lack that perspective completely. If you have gone through that journey at least once you start seeing that journey in other domains as well which gives you a lot of understanding about the field, about engineers, about what projects actually require etc. I really don't see how you can be considered wise without having seen that, not as a software engineer at least. Maybe you could be a great product manager though.
An uppercase theta should be used for "Big Θ time complexity" regarding algorithms but for angles like in the article, it should be the lowercase theta that looks like this: θ.
No one would or should say "short & fat".
And yes, generalists are undervalued.
A wide profile is typically what you want as a boss/executive/entrepreneur. With technical knowledge but also artistic, legal, people and of course business skills. This is what you need to run a company. And as you reach your limits, you start to hire experts.
- Their deep domain knowledge makes them sound a lot smarter than they are... Especially to non tech-savvy managers who don't know better. So they can be extremely persuasive in arguments. They only participate in arguments that they can win but their ability to constantly win those niche arguments gives them extra general credibility which is not deserved.
- They are excellent at implementing solutions within their narrow area of expertise but they tend to miss a lot of alternative solutions which may have been better. They could spend years working on a solution whose problem could have been solved much faster and more elegantly via a different solution which happens to lie outside of that individual's immediate domain of expertise. People who wield absolute top-of-the-range, world-class hammers but have no other tool in their toolbox have a very strong incentive to see and portray every problem as a nail.
When you're a bigger product organization, more specialized approaches can work better since you're better suited to find the right trade-off of "speed" vs "future-proofness".
This can backfire too though - many specialists can get lost in the weeds and over-engineer solutions that can cripple a business with maintenance costs simply because they want to increase their depth.
I think this entire contextualization is kind of ridiculous though. If you were to categorize short fat vs tall skinny vs T, you might see something like:
fullstack eng vs ML researcher vs backend engineer w/ ETL experience
The fact is that fullstacks _are_ utility players. I don't know that they're really at liberty to "take the helm" if they're not well-versed in the technology that differentiates the company (or team).
They understand what the technology in question can do and cannot do. They know what other technologies can be paired and cannot be paired with the current one and they understand the performance, development, deployment and maintenance aspects of all the combinations.
They can then design applications or platforms, learning as they go.
Take, for example NodeJS. Ryan knows what V8 is capable of, knows what it's not capable of outside the browser sandbox, and built himself an alternate sandbox. The implementation details, while complex, are minor in the grand scheme of things.
I saw that a lot in consulting, where people with what would objectively be a very superficial skillset in some area or another "branded" themselves as being a deep expert, and became the go-to for anything that was perceived as relating to their area.
So I would maybe rephrase as "skinny engineers brand more easily"
First of all, there's a tendency for depth engineers to be more visible. But this is extreme; there's a handful of top names in StackOverflow for a tag like csharp or django, but that doesn't mean number 1000 in a given tag is an amateur at it, he's likely pretty good. Similarly, not everyone writes respected blogs, but the people who do tend to be ones who spent a heck of a lot of time in one niche. That doesn't mean you need a known blogger for your project.
Second, there's a tendency for hiring firms to want a dev fully trained in some vertical. This may sound sensible but often isn't. If you have some person who did a lot of work in RoR, but you have a Py/Django project, couldn't you expect him to get up to speed reasonably quickly? I think in a lot of cases, yes. Whether you'll be allowed to take that risk depends on the situation, and often you won't be. This works the other way too: a lot of devs will decide not to bother applying.
Third, diminishing returns. Like a lot of knowledge stuff, there's a sort of pareto principle here. You can learn most of anything in way under half the time to learn the whole thing, if that's even possible. If your project is not super specialized in one vertical, but still requires a lot of verticals, you benefit from having a guy who knows a lot about a lot of stuff.
I wonder what is the average time for an experienced engineer to transition into a different, but similar technology (like RoR -> Django) and be able to work productively in it.
It can’t be very long. Maybe 2 weeks? If you had a number, you could calculate the costs as part of a standard onboarding process. You’d just need to make sure that you hire someone who can demonstrate a willingness to learn the new thing.
This seems like it could be much cheaper than hiring an expert with the most years of experience in the particular combination of technologies in your stack, without compromising on quality.
And the perspective from someone with a breadth of knowledge is more likely to yield innovations that provide your company/project with a competitive advantage, compared to the expert that has been working on the same thing for many years.
As someone who's done this probably too many times (Perl cgi -> cakePHP -> Play framework -> Spring -> Node.js/Express -> Flask -> Sinatra) I'd say your two week estimate sounds about right, at least given my personal experience.
After switching you quickly notice patterns and apply your past experience from other languages and frameworks. After a few weeks to a couple months you produce idiomatic code indistinguishable from your peers.
And those examples are just web framework transitions. As someone with not enough sense to stay put, I've wandered as far as:
* embedded C and assembly for microcontrollers
* writing kernel modules and device drivers
* designing, programming and assembling custom hardware (pcbs, enclosures)
* writing mobile applications (iOS/hybrid)
* being a frontend engineer (jQuery -> moo -> knockout -> backbone -> redux+react)
I've jumped fields from robotics research, social networking, healthcare, fintech, and consumer electronics.
It's been a wild ride and looking back I honestly wouldn't change much in hindsight.
As a generalist I work best on the early side of projects where I end up "wearing lots of hats." 'Tend to stick to a place for 5 or so years until everyone becomes specialists, then move on. As you say though the key is the willingness to learn.
As far as your point on generalists being cheaper than experts--I've found that pay honestly has more to do with soft skills than "expertise." (Good communication, self advocacy skills, etc.)
Going all wide or all narrow is a recipe for a team wipe.
The “short fat engineer” is the early-career nothing-to-lose startup founder, and that’s a vital role that is arguably correctly valued by our industry in recent decades.
A wise generalist manager deftly guiding the skills of a bunch of deep specialists probably makes for a great team, and a team that can be expanded without much friction. A team with too many ‘wise’ people (or people who perceive themselves that way) might just waste all day arguing.
I'm also personally somewhere between a tall-skinny and t-shaped engineer. Admittedly jobs seem to be a little harder to come by, but there are some jobs (especially with small startups) that really appreciate engineers who have a wide range of skills.
I'd love to see some data, confirming this. I suspect OP is right, but I don't think "short and fat" engineers are under valued as a rule, it's more that 90% of the time companies are looking to hire someone with a very specific skillset to fill a very specific role.
People who think they know something are more likely to be wrong than people who don't think they know anything on a topic. There's a "competence gap" between knowing you know nothing and actually having deep knowledge; it's the "just enough to be dangerous" zone.
Depending on how tall precisely "short fat" is, that can describe an engineer that, more often than not, makes the wrong choice because they know enough to have opinions but those opinions are raw.
The problem with focusing too much on one area is that you can only deal with one particular type of problem and maybe only with one particular type of solution.
Cases where someone has actually gotten progressively "deeper" as they continue to work in the same area are (anecdotally) outliers. It's much more common to have just spend a lot of time doing more of the same.
Ive always been amazed by the “tall” devs and have one or twice (or more than I’d like to admit) tried to deep dive something always eventually giving up because I have no idea where to obtain the deeper knowledge. Perhaps more realistically, I just have a different type of fat.
EXAMPLE: Why would I care if my plumber also moonlights as a surgeon if all I care about is getting my faucet fixed without him passing the buck due to perceived complexity?
Those things are great in a dinner party setting, but in the professional workplace you want professionals not dabblers. Whenever I meet a self styled "generalist" nowadays I scoff. It's not hard to read HN daily and pick up on the lingo and memes and fake your way to 99% of a "generalist" in both knowledge and impression, but that doesn't make one a good engineer.
I find most specialists useless when it comes to architecting and building a full system, and often when they are a part of a team, focused on their specialty, they build in a way that is difficult to fit into the whole.
Obviously there are good things, too: my knowledge of things like data science and graphics is limited; if a part of a project called for deep knowledge in those areas, I'd be happy to have a specialist on the team. But unless they are more of the "T-shaped" type the article talks about, they need a lot of hand-holding when it comes to anything outside their domain.
Generalists bridge that gap, and handle necessary concerns that most specialists don't even consider, let alone know how to handle.
(Full disclosure: I consider myself a generalist, though at times I have ended up diving deep into particular areas when projects have required it.)
A specialist will tend to underestimate how much a generalist can accomplish, when they choose to specialize, and a generalist will tend to underestimate how deep any given specialty really goes.
Someone should study that.
width is a hedge - you don't get paid as much, but you can land a job quickly, because you can plug into any team
I generally like your model, but mobility is upstream of salary too. If you're very intentional about your career, mobility is the ace up your sleeve, letting you slot into the places you need to to maximize your current and future salary.
I've always been a pretty width-first engineer; it just fits my personality. But time and again, I've been able to open doors for myself because my established excellence in one area provided an "insurance policy" for teams to take a chance on me working in another (in-demand, specialized) area. After the first iteration or two, it's been a virtuous cycle, where I make lots of money with my established skill in the currently-hot thing and trade off a small portion of that to grow the skill in the next-to-be-hot thing.
Though perhaps this doesn't generalize well. I've been studying/working in AI for well over a decade and it's been a remarkable boom for my chosen field. Perhaps during the next AI winter, I'll have to face the depth/width trade-off a little more directly. But even in that case, it seems like width maximizes my expected salary.
Can I rubber duck you with another question? As someone who is also trying to maximize mobility and width, how do you feel about the idea of "it's not who you know vs what you know, it's who knows what you know"? In other words, when you move teams/jobs, how to you gain credibility? Do you do anything to promote/show your 'track record'?
What are accomplishments of tall.skinny vs short.fat engineers?
Linux was driven by Linus T, javascript by Brendan E, Apple by 2 Steve’s, etc.
Innovation and creativity are more highly valued, which are byproducts of short.skinny type.
> On a long enough time line, wisdom is always more valuable than knowledge.
In practice, context is everything. That’s why for every expert, there is an equal and opposite expert.
I would imagine that this type of engineer needs to be carefully managed to stay on tasks that add business-value.
As such, it's not unfair that they are seen as juniors. They are juniors.
It's the stick of the T.
As value is largely determined by scarcity (supply and demand), this would cause "short fat" to be of lower value.
It doesn't work that way because coordination costs are a big part of the cost.
Elon Musk is a great example who is able to answer deep technical questions on many subjects, and I think he needs people who understand their own project deeply, not ,,short fat'' engineers.
> Everyone should read "Range By David Epstein" https://www.amazon.com/Range-Generalists-Triumph-Specialized...
> In most fields, especially those that are complex and unpredictable. Generalists, not specialists, are primed to excel.
