
Everyone Does Everything: How To Work on Teams of Generalists - jongold
https://medium.com/words-about-design/12e0882c51d1
======
robomartin
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.

~~~
stephengillie
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/>

------
DanielBMarkham
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.

------
oogali
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?

~~~
twistedpair
G is for generalist, right?

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

------
realrocker
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>

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

~~~
realrocker
Unless the team itself is one giant organism.

~~~
pessimizer
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.

------
nubbie
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?

~~~
realrocker
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.

~~~
porker
> 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?

~~~
twistedpair
"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.

~~~
realrocker
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.

------
sid6376
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.

~~~
senko
_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).

~~~
antoko
_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."

------
halisaurus
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.

~~~
jongold
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 :)

------
Spooky23
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.

------
ionforce
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.

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

------
jonstjohn
"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.

------
agentultra
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.

~~~
porker
> 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
:)

------
VuongN
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.

~~~
rhizome
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."

------
mcgwiz
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".

------
Fuxy
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.

------
noloqy
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.

~~~
twistedpair
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.

------
htss2013
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.

------
coffeemug
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.

~~~
twistedpair
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.

------
scrozier
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.

------
onedev
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.

------
swalsh
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.

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

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

Thankfully Pocket does the job.

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

~~~
shaydoc
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.

------
lotsofcows
Nice kanban board - have you tried trello.com ?

~~~
jongold
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.

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

------
jjellyy
good overview but lacking a solution

