Everyone Does Everything: How To Work on Teams of Generalists | Hacker News Reader

Everyone Does Everything: How To Work on Teams of Generalists

medium.com

137 pointsjongold71 comments

My opinion based having always been a multidisciplinary generalist spanning hardware, software and mechanical design forever:

While launching or validating, being a generalist (or having a small team of generalists) can be a huge advantage. Massive. However, you are going nowhere fast with generalization. You need to divest yourself of subject area responsibilities as quickly as practical by bringing in a team of specialists. An accomplished generalist can be very effective at managing such a team due to having a good understanding of each of the pieces.

You need people who will give specific areas of your business a focused approach full time as opposed to time-slicing your business.

Scenario: You can code, assemble electronics, test, develop the website, sell, run quickbooks and ship. Great! You should not run the business this way for too long. Maybe while you are in the garage. Almost anyone will agree that getting a real accountant ASAP is a no-brainer. As the business grows you should replace yourself for each of the above tasks by hiring specialists. Either you pick one area to focus on or take on a supervisory position running the operation. Nothing else will allow you to scale.

In general terms, I don't see teams of generalists being a good thing at all. For a rapid product development or launch, yeah, sure. To run and grow a company for ten years or more? No way. Bad idea.

These have been my exact thoughts as I've started working with Arduinos and looked into starting a robotics shop -- I can learn to do everything, etch frame solder code make each component myself, but I get passed up by teams of specialists like the Spark Core [1], who are focusing solely on that component.

Thinking of times when I've worked on teams, I've succeeded because I could leverage the synergy of my multiple disciplines, excuse me, because I could take ideas from different fields and use them together. But teams of generalists are just wasting their time, as each generalist will just be specializing in one area or another, and a specialist in that field would be more effective.

Generalists do make good managers, teachers, librarians, etc.

[1] http://www.sparkdevices.com/

It's interesting this focus I see lately on "full stack developers", which, to me, is just somebody who knows how to write applications.

I don't work with people who can't do the whole thing. So having a "generalist" team doesn't sound like anything special, even though I'm aware this is an odd thing in the corporate world. Remember that on each project each person is supposed to be stretching their skills, so a "generalist" team, to me, is just a bunch of guys that each, if necessary, could pull off the entire project with enough work.

Having said that, what I usually do is have folks decide what they want to deep-dive in. Maybe the UI guy has always wanted to take a few months to learn the back-end. Or maybe the all-around guy wants more time tweaking DevOps. Let them "specialize" in that, but still rotate stuff around. Projects should be learning experiences.

Love the pairing idea, especially for tricky problems.

The thing that I think befuddles me is that all of these skills are useful to all of the pieces of the app, no matter what your temporary "specialty" is. If you're doing back-end, you're going to be automating a lot, perhaps writing an half-assed UI to do some testing and system status. If you're on the front-end, you'll be automating testing, and so forth. I think even if you specialize, you need all the development skills for a full application, all of the time. Otherwise you're going to be sucking wind compare to another team.

So yes, this is a "getting out of the other guy's way" problem, but in practice it's not a very difficult one, especially if you communicate well and rotate stuff around.

> I don't work with people who can't do the whole thing. So having a "generalist" team doesn't sound like anything special, even though I'm aware this is an odd thing in the corporate world.

Where do you work? and are you hiring?

I haven't met a company (even a startup company) that would prefer to hire a generalist over a specialist. At every startup I've worked at, being a "generalist" means you fill whatever position hasn't been hired for yet. I typically spend a few months in a specific job role and shift to a different one whenever a specialist is hired.

My preferred method of working is the same as the OP's: I like implementing whole features from start to finish. In my 10 years of experience, I've been able to do that in exactly one job and it only lasted 6 months before the product was finally sunset.

There's two glaring problems for me: generalists and ops is a route to pain, you just may not know it yet; and every generalist solves a problem differently, and may not understand the short-term vs. long-term tradeoffs that they're making.

From a sysadmin troubleshooting angle...

Say, you discover a memory leak in your application which sits on top of Apache httpd and mod_php/mod_wsgi.

Do you:

a) set up a cron to restart the web server every X minutes?

b) change httpd from the default of MaxRequestsPerChild 0 to some non-zero number?

c) ask Slicehost/Rackspace/etc. to increase the amount of memory for your VM (or in EC2, migrate to a larger instance)?

d) increase the number of application instances, and add them to the load balancer?

e) write a script that frequently polls the application server, and when a failure is detected, bounce the server (or remove it from the load balancing pool, and re-add it later?)

f) do some combination of all of the above, and add this question to your list of interview questions, while posting an opening on StackOverflow Careers for a sysadmin/techops/devops candidate?

g) sit down with a staging instance, valgrind/gdb/memprof/rbtrace/etc., a method of generating traffic, and the top 20 URLs from affected production instances?

If you picked G, how many people on your team are actually proficient with those tools? How many other team members would have picked the same option as you?

While still on this option, how many people actually start working on the problem? One person, or divvied up amongst multiple people? What do you do when that person hits a wall? What happens to the rest of your deadlines?

After all of that, are you still a generalist?

First off, i'm the G guy. But just because i'm a halfway decent software dev doesn't mean i'm not a generalist. I'm not the SQL guy (though I can write it), and i'm not the SAN guy (though I know how to carve out new volumes). I can work on pretty much any problem, but my strengths will lead me to work on the things I know the best.

So often i'll take on a bug if I know how to fix it. But if i'm busy, someone else might take care of it (perhaps the A guy). Doesn't really matter. If he needs help, he'll ask me or someone else, otherwise he'll figure it out.

Generalists are great at figuring things out that they don't understand. But they also have to be willing to admit when they're stymied and ask for help.

In somewhat neat response to option 'g' and the phrase "generalists and ops is a route to pain", my view is that 'g' should be an automated part of your test suite and release process. Certainly, if not before then during the period you are resolving the issue... as a matter of principle.

I would do c) if it can be done without hassle, then e) and then g). The load balancer should do e) by default - don't forward to broken servers.

g) takes time and concentration, and you don't want any interruptions while debugging.

OP here - I think I was stretching it a littttle bit far to claim we're all good at sysadmin :) In reality—at least on my team—we're really good at UX -> visual design -> front-end MV* -> Rails

> a) set up a cron to restart the web server every X minutes?

Jeff Bezos was literally a billionaire, and many of his team millionaires, before Amazon.com deprecated that solution.

a) is a much simpler solution to generate, design & implement than g). From an engineer's perspective, I can appreciate how g) feels like the correct solution, because it's solving the underlying technology problem. From a business perspective, pursuing g) could take a lot of time which could be used to build other parts of the service, which might make the issue disappear.

Really, it's a cost-benefit question -- which takes more time, writing a) and dealing with lots of rebooting, or having someone pursue g)? Or maybe c) is cheaper than g) -- how many programmer-hours equals an extra 16GB of RAM? And if the memory leak isn't that bad (let's say 20 hours between these reboots), then a) can be said to make your service cheaper for your customers too.

G is for generalist, right?

Obviously. Though the options appear so shockingly poor that they limn generalists as idiots (i.e. option a), hence my sardonic posit.

G means choice g in this case, which helps you find the root problem. The other choices just treat the symptoms.

Alright, I have a solution. The last time I worked with a team of generalists we would get into sticky situations of division of work. We came up with the idea of appointing "First Speaker"[1] for each project. Though the Wikipedia article doesn't say much, in the Foundation book, first speaker is someone who spoke first and it does not indicate hierarchy. The first speaker is someone who first initiates or formulates a (reasonable)plan of execution. The rest of the team would follow with inputs on the same plan making it better(instead of creating new plans). It was more than shouting "dibs".

One of the reasons I think it worked out was because the team members were all of the same work and skill experience(i.e equally bad or equally good). We also had equal stakes in the project. I don't see an all generalist team working out at all if they are not of equal mileage.

[1]http://en.wikipedia.org/wiki/First_Speaker

It should work smoothly as long as no one is as stubborn as a "mule" ;)

Unless the team itself is one giant organism.

Yeah, it might be nice to have a mule for every project (might affect the dynamic well, slow things down etc.) and if somebody specialized in being the mule, it'd be funny, but it might work.

That's an absolutely brilliant idea - thanks; will definitely try it out :)

Not really relevant to the article, but I've been worrying a while about being 'too general'.

I'm 6 months into my first full time job, but did work with the same company for the equivalent of 6 months while I was still at uni. During this time, I've done backend development under 4 different platforms, fixed database issues, designed UIs (thanks bootstrap!), solved some basic server issues.

I enjoy my work and I'm learning a lot of new things every single day, but am I spreading myself out too thin? I don't feel like I know any one thing very well. Will I get to a point where I have 4 years of experience, but I won't be able to get any jobs because I'd only have 1 year worth of Rails, 1 year of Django, 1 year of Java and another year of Javascript?

It's good to start with a generic base. Couple of years down the line, you will find out that there are skills you are particularly good at. At that point of time, you would be making an informed choice of what specialization you should take up. It's better than a picking up say, "Front-end Engineering", sticking with it for 5 years and being average at. Who know's you might have a natural flair for writing system applications? >Spreading myself out too thin? You feel that way now because you have still not understood the work of "Masters" and how they do it. It's like someone who has only seen fireflies while never having seen the sun.

That's a great way to look at it, thanks!

In fact, this has already happened. I have a combined Commerce and Science degree and always thought I was going to be an Actuary. Sort of stumbled into this career and have been loving it since.

> You feel that way now because you have still not understood the work of "Masters" and how they do it. It's like someone who has only seen fireflies while never having seen the sun.

I'm confused by this - how do "Masters" do it?

The assumption that a little more focus on one particular thing will make one a specialist. To become a specialist or a master you not only need undivided attention but a natural flair for it. You can practice music all your life and still not compose like Mozart or Bach.Or even someone like Jiro Ono(http://www.thedailybeast.com/articles/2012/03/11/jiro-ono-co...). Most of us will never become Masters, being no more than experienced hacks. That doesn't mean one shouldn't target for it. "Stretching oneself too thin" is a common refrain among technologists implying that if they rather focus on one skill, they are bound to become Masters. In my opinion it's as much about serendipity as it's about perseverance.

"Master" is a bit of a baroque moniker. Can we agree that a "master" ought to be much further along than a "specialist?" i.e. the Java master should understand byte code and personally know folks of the original Sun Java team?

Otherwise it just sounds like I can become a Javascript Master in a few months.

I prefer the phrase "experienced in x". In my opinion specialist and master should have the same weight. Calling someone "specialist" can be a misnomer for a master if the scale for measurement is not agreed upon.

It's important to remember that we don't really know what languages/framework etc will still be used in the future - if you specialise in something you run the risk of that technology becoming obsolete or just being ignored.

Don't worry about it.

I've worked in IT for 13 years, programming in everything from Java EE to Perl and Python. I've configured Apache HTTP servers and Glassfish servers, worked with databases such as MySQL, PostgreSQL, MS SQL and DB2. Emacs, Eclipse, IntelliJ IDEA, it doesn't matter. Whatever technology that gets the job done is important. I've even been a manager for a 10 - 13 person team for a short while, but went back to being a developer.

All in all I feel that working with varied technologies has made me better.

If you work at a large corporation, this is called rotation. Larger companies like to rotate their fresh-out-of-university employees through different roles so that they have a chance to discover what they really like to work on.

Usually this is explained to you upon hire and it is generally expected that after the rotation period (anywhere from 6 months to 2 years), you will choose a path.

Hasn't the 1 year in Java made you a better Javascript programmer? I assume you haven't just been learning language syntax, but have been developing patterns that are deployable across languages. Of course, you would have been a better Java programmer if you'd spent 4 years with Java, but don't underestimate the value of the generalist approach you've taken.

It definitely has; I think programming in any language makes me a better programmer in any other language.

However, my concern is applying for jobs relevant to my level of software engineering experience, but requiring X amount of experience in Y. In a situation where I believe my ability is equivalent in Y, is the solution to exaggerate a little on my time spent on Y? Maybe it's not even a big deal in the first place :D

I've worried about that every day for the past few years.

But then I consider the alternatives — either designing flats in Photoshop/Sketch, or coding someone else's work?

I might be spreading myself thin but I'm enjoying it and delivering the most value I can be.

In my experience I would like to move in the other direction specialization. As a generalist by circumstance (First engineering hire and then I became the only developer at my startup when my CTO left) it gets grating after a while. Particularly when the newer hires automatically assume if there is something unpleasant or even slightly outside their defined work, it's your job. What i also observed that as a generalist there is a cap on what you can learn in a specific field. This works for a while, I learnt a lot at my startup particularly since I was coming from a non web background, but my learning hit a cap a year after I joined and I was constantly juggling production bugs, sys admin tasks and database optimization sometimes all at once, which hardly left much time to become an expert in anything.

Particularly when the newer hires automatically assume if there is something unpleasant or even slightly outside their defined work, it's your job.

It is your job as their lead to make them understand "Somebody Else's Problem" is poisonous for their team (if that's how things are working in your team; when the organization gets large enough to make it worthwhile to have somebody else fix that problem, the same behaviour can be beneficial).

In my company (7 of us), every new hire gets an unassembled chair and an uninstalled computer and are expected to take care of it themselves on their first day (I guess you could say it's part of our company culture).

Heh that sounds awesome. A very real demonstration to a new hire what's expected of them - "Stuff needs doing? roll up your sleeves and get it done."

That is really clever. I had to build my own chair and desk on my first day and didn't even give it a second thought as to why that was the case.

I agree with the "No one knows how to work with generalists" statement, and I have found myself scrambling to answer the "What exactly do you do?" question a few times. It feels like a small few appreciate the idea that I just like to build things and don't mind moving around to address issues in different "areas." Others expect to put me in a seat with a label on it and focus on whatever tasks require the person in that chair. I invariably get called something I'm brought on to the team and then switch gears unexpectedly. ("I didn't know you code.")

Your idea for pairing generalists is awesome, and I wonder if it's viable to do independently and "sell" two generalists as a team to recruiters/companies. Just like the art director and copywriter combo, two generalists sell themselves as a duo able to address any challenge from the server to sales.

That's a really great suggestion. We only work on our own products, but if I go back to client services it's definitely something I'd like to explore :)

That idea is probably worth a lot of money. Pairs of contractors knocking out massively scoped quickly needed solutions that can afford to be (mildly) wonky if they're timely. Like you might end up with a billing system written in Haskell, but you'll have it next week:)

I think that the premise here is wrong. Working with a group of generalists is about managing employee skillsets and professional growth.

Whether you have people with deep, focused expertise or generalists with broad expertise, that doesn't change the fundamentals of managing an organization. The company is a machine... you take labor, knowledge and machines and produce a work output more valuable than the cost of those parts individually.

You don't generalize accountability. You don't breed chaos.

The beauty of small teams is that roles don't need to be fixed (vs. large companies that breed teams with tightly defined scopes). The downside of small teams is that you don't have the time to give non-core functions the focus they might demand elsewhere. You may be accountable for sysadmin tasks today, but not next month. The key secret to being successful (which is much easier in small organizations) is to effectively communicate.

I've done a lot of theorycrafting regarding specialists vs generalists. If we could take a detour to the Warcraft/Final Fantasy arena...

Being a generalist is like being a Druid/Shammy/Paladin/Red Mage. They will never be as good as a pure Warrior or Mage, but the key here is that they can satisfy (sufficiently) both roles as one person. Let's say you're on a DPS-heavy team, you would most likely take up the role of healer. So as other posters have said, generalists are good at filling the gaps of whatever team they are on. Their role will be dictated by the voids created by their team mates.

Let's say you have a team of all Red Mages. Instead of having them all heal and all fight, which can be chaotic management-wise, you might choose to have one function as a healer and the other two as DPS. Treat them as a specialist team even though they are generalists underneath.

As with a real business that scales, I think specialization really is the only way to have truly high, spectacular output. That said, there may be a place, at small scale, where generalists shine, where context switching occurs more often. Maybe we could call them "micro opportunities". Let's say you have three Red Mages and no one needs healing. Great, everyone is on DPS. Let's say one round, you need to pop a heal. One mage becomes a healer, temporarily, and then switches back to DPS. Compare this with specialization. Sure your Priest/White Mage can "DPS" but the output is negligible. They are effectively healing full time. So, while there is no context switching in the specialization scenario, there is also missed opportunity. Again, not an opportunity of scale, but a micro opportunity.

Personally, I love the idea of generalists. I think it's good to have perspective on a lot of things and it breeds empathy and familiarity. I think the best would be general specialists. So not "a Ruby guy", "a JS guy", and "an ops guy" but maybe "backend dev", "front end dev". I know a lot of people like that so it's not a completely foreign idea.

See also "T-shaped" people from the Valve company handbook. They are people that essentially "implement" both specialization and generalization.

The classes are from Final Fantasy, not D&D. Just to save some googling to some people :)

"Everyone does everything" has been the developer mentality at the company that I work for, which is a small software company of about 14 devs and 3 teams. We're an agile/scrum shop and all developers work on front-end, back-end, devops, etc. We do have a UX person, product manager and sysadmin. All developers work on all products, as well.

The advantage is that knowledge is shared between all developers and any can do most tasks. The downside I see is that nobody is really the specialist in an area and thus less efficient at getting their work done.

In my experience this doesn't seem like an industry evolving towards having more generalists. In fact it is breeding more specialization than ever (what with the unbelievably high enrolment rates in university across the board). Almost every programming job I've interviewed for in the last four years has involved some kind of domain specialization. Perhaps that's just where I am and gravitate towards but with the role of "web developer," being divvied up into "front end developer," "UX designer," "graphic designer," and "backend developer," it does seem to me that specialization, not generalization, is the way we're going.

In other words, it's getting complicated enough that the case of one person being able to do it all is getting more and more rare. Sure you can figure out the gist of the entire stack but in order to deeply understand it to the point where you can push the boundaries of what's possible will require a focus on just one part of it.

> but with the role of "web developer," being divvied up into "front end developer," "UX designer," "graphic designer," and "backend developer," it does seem to me that specialization, not generalization, is the way we're going.

And yet someone has to 'glue together' the roles and understand what each specialist is doing. I feel that's where I, as a generalist, fit in. It's not Project Management per se, lead developer with oversight for the project?

I haven't figured it out yet - I like this role, but it's not hugely hireable :)

I think it's just crappy hiring practices. In my experience, the team of generalists will almost always beat the team of specialists. But managers like pretending they are assembling the A-Team: there's my UI guy, my DB guy, my master-of-disguise guy, etc.

I think the problem is quite timely. In an early-stage startup, everyone needs to be a generalist. As the team grows, generalists need to evolve into domain-accountable roles.

For instance, my team starts with just me. I needed to push a fullstack web app out the door. Then we got more money and the team grew to 4. I can't be the same generalist anymore or else I will work myself into a bottleneck.

I still require everyone on my (web) team to be generalists or know the fullstack. This way, no one can be a bottleneck and everyone can solve problem or implement a new feature independently.

The problem is "integration", or when the projects become too big for just 1 person. In those instances, we solve a lot of frictions by having a final "dictator" for technology decisions and a "team manifesto" in term of best practices.

So far so good. Now, if I can get a ops guy to help me then I can sleep with both eyes closed :)

-V.

A problem I've seen is when the CTO/DirEng is kind of green and they defer or abdicate establishing a code practice and development direction in favor of "meritocracy" or "flat hierarchy."

Interesting article. However, it presupposes that all "generalists" (whatever exactly they are) are the same. This is obviously wrong and therefore IMO it weakens the entire article and invalidates the sub-title.

Even if all "generalists" had equal aptitude in the same set of technologies, there remain varying degrees of creativity/experience, varying preferences of technologies to work with, varying preferences for problems to solve, varying ability to weigh cost/benefits of tasks from the strategic business perspective, etc. I've worked on many "generalist" teams and, because of our technical and non-technical differentiation, there was never any awkwardness about "who does what".

Generalists are great hell I'm a generalist but choosing and developing one specific skill (the skill you're best at) is a must.

I'm still a generalist and I still know a lot of things about hardware, software engineering, etc. but I have found a niche I can be a specialist in and I can say with confidence I can play with the best of them.

Still being a specialist gets boring sometimes so I like to mix it up with some of my generalist skills.

Nice article. Unfortunately we see that in big projects there may be too strong of a reliance on specialists performing certain tasks. This isn't only because of the potential specialist nature of the task, but also for an important part because workers have an incentive to become a specialist. Generalists are expendable, while specialists are not. This implies that a specialist in a given domain has greater job security within the project, and thus has an incentive to protect his specific domain.

Then again, depending on the frameworks in use (i.e. GWT) that frontend and backend are all in the same code base. This can be great for some applications and undesirable for others. However, I'm frequently surprised by the desire to break every tasks out into a role.

For example one person to write the queries, one person to put the HTML into a JSP page, one person to create a backend service, one person to setup the server, one person to run the CI, one person to write some tests.

Let's look at other industries. Remember back in publishing and design. There used to be a ton of people there too. The type setters, the people designing layouts and then others physically compositing and scaling those elements for photographing and making into plates. There were tons of people involved in any good publication. Now they're all out of work and one person can do all of their jobs with the right software suite and farm out the printing.

I posit that we'll see a greater fusion of roles. A Java dev can crank out hibernate queries all day (I know, they'll be ugly and slow) and just drop in some stuff from a Bootstrap template to spice it up. Wait for the next economic contraction in IT and you'll see the disposable roles become apparent.

Generalist vs. specialist is a question of org size and, on a personal level, whether you want to be a manager or a practitioner. It's basically a 4x4 matrix.

1) large org, practitioner: be a specialist 2) large org, manager: be a specialist or a generalist 3) small org, practitioner: be a generalist 4) small org, manager: be a generalist

Even if it's arguable that small orgs would perform better with specialist practitioners, in reality few have the budget to hire large teams of specialists.

Ahh, a team of generalists where nobody is spectacular at anything in particular. Throw in a Kanban board, and you've really got a recipe for success.

I've seen teams of "specialists" be about as doomed before. I knew a few "Rubyists" who would not touch any other language than Ruby. No JS, No HTML, No SQL. Only pure Ruby.

Get in a bind and need a full court press to get some unit tests out, QA automation, or some queries tuned? Too bad. Everyone is in their silo and heading home at the steam whistle at 5pm.

On my teams of devs that all knew a lot of areas, we could pivot to get whatever had to be done complete at the end of the release rather than being marooned on our daises.

That's one extreme. Middle ground would be to recognize and capitalize on strengths, while taking advantage of anyone's ability and willingness to fill in a role until the better qualified individual comes off his urgent assignment or personal issue.

This shouldn't be the case. You can be spectacular at X and still very good at Y and Z. Even more likely, that broader view and experience would help to be specacular at something.

I do see generalization happening more and more, but I think it's a result of more and more smart, but untrained, people entering web development, rather than any natural or desirable trend toward generalization. I invoke Crozier's Rule of 10: when you rank your level of expertise in 2 or more fields, the sum is never greater than 10.

I don't think there's much long term value in being a generalist. I think people benefit much more from the perspective of being a specialist; it's much more proprietary and can't really be replaced.

Generalism propagates mediocrity at many levels rather than valuable competency at a few levels.

I don't think there exists a team of generalists. Every person has individual strengths and weaknesses. As a lead, i feel my main role is to identify what those strengths are, and play to them. I think his main problem though is, i can't tell if they even have a lead.

"I’d love to be in a position where Natalia and I could pair all day"

I can't get this article to work on my nexus 7, the whole browser just freezes!

Thankfully Pocket does the job.

Eesh, sorry! I'd like to think it's a Medium problem — either that or your browser decided my article wasn't worth reading ;)

No your article is very good, reading it on pocket at the moment.

I think in terms of development I think its good to have a good idea what's going on end to end, I would consider that normal. However, its good to have a specialism too, that is be a master of one or two things. Its not much to ask someone to be proficient in a programming language or 3 and a database of some description, I don't think.

Man, that ff-tisa-web-pro font is genius. Even though it's rendered differently by Chrome, Firefox, and IE, it looks really good. In fact it looks so good in FF that I stopped to investigate!

Oh... and the content is good too ;)

Had same problem. Works with Firefox though. Must be a chrome issue.

Nice kanban board - have you tried trello.com ?

Yup - that was actually an old job, but at @MakeshiftHQ we have a streamlined real-world version for each project we work on.

We're a small team (4 designy-devs + 3 others at the moment) and we're almost always in the same room so it's quite nice to have the liberty of having a real, physical, 'can pick up the card and put it next to my monitor' board, but we also keep our Trello up to date in case we're working from home.

In a similar position and fantasising about being able to afford a monitor big enough to stick on the wall...

Trello is indeed awesome. Just add a task, bug or an issue and it can be picked up by someone, anyone for that matter, without the need to assign it to anyone in particular.

good overview but lacking a solution

Reply on news.ycombinator.com