Why And Where Is

Teamwork Important?
Comment Now
Follow Comments

Edmond Lau, Quora Engineer
Working effectively as part of a team is
incredibly important for output quality, morale,
and retention. My professional experience involving
teamwork has primarily been within software
engineering, but most of the takeaway lessons arent
limited to engineering.
From the perspective of efficiency, a traditional
argument against staffing large teams comes from
Frederick Brookss The Mythical Man-Month. A man-
month or person-month refers to the unit of work that
one person can accomplish in one month. The basic
premise that Brooks argues against is the notion that a
software project that takes one person a year to complete
(twelve person-months) can have its timeline shortened
to a single month simply by staffing the project with a
dozen engineers. Upon seeing projects falling behind,
many managers want to put schedules back on track by
simply adding more engineers to the project.
The problem with this logic and the reason its a myth
is that each additional engineer added to a project
incurs both communication and coordination overhead
with everyone else on the team, and so the time to
complete a project doesnt actually decrease linearly with
increased staffing. This leads to what is commonly
known as Brookss Law, that adding manpower to a late
software project makes it later. [1]
Because of this line of reasoning, managers or technical
leads sometimes over-correct and attempt to maximize
efficiency by staffing single-person projects to reduce the
communication overhead down to zero. Some
companies, likeGoogle, even emphasize in their
promotion processes that an engineer has to
demonstrate ownership in a project, which incentivizes
engineers to define and prioritize individual projects so
that they can be the indisputable owners of those
projects and increase their chances for a promotion.
The reality is that there are a number of downsides and
risks to working alone that affect output quality and
morale:
Working alone makes it harder to get early and
continual design feedback, thereby decreasing
output quality. A tight feedback cycle is critical to achieving
a productive state of flow [2], and the earlier that you can get
feedback, the less likely that youll waste time going down the
wrong path and earlier youll know to correct your course. In
practice, one place where this shows up in software
development is that its significantly easier for someone to
review your code and to give good feedback if they actually
work on the same team as you and share the same project
context as you; its much harder to for someone on a different
project to give you code. Brian Fitzpatrick and Ben Collins-
Sussman capture this notion well in one of their taglines
in Team Geek: software development is a team sport. [3]
Working alone reduces learning. One part of this is
related to the first point, where there are fewer people with a
shared context to challenge your ideas. Another is that
because the project takes much longer to complete, each
individual working along works on fewer projects over time.
Working on a team increases the bus factor for a
project. The bus factor [4] of a project refers to the number
of team members that can be hit by a bus (or gets sick, leaves
the company, goes on maternity leave, etc.) before a project
comes to a complete halt; a higher bus factor reduces risk on a
project. It also helps prevent obscure and undocumented
shortcuts taken by a single individual and forces team
members to spread knowledge and to do things in a way that
other people on the team can pick up if necessary.
Working on a team increases accountability. Peer
pressure is a powerful force. Particularly if youre working
with people whom you respect and dont want to let down, the
motivation to help your team succeed can override the dips in
motivation that you encounter on days when youre not at
your best.
Slower project momentum from working alone
reduces morale. Project estimation is hard, and projects
tend to slip behind schedule. [5, 6] In single-person projects,
a single stall can put the project to a halt, just like how in a
grocery store with only one checkout line, one problematic
customer or one item that needs a price check can put all
sales to a temporary halt. With at least one additional person
on the project, there can still at least be some forward
momentum.A related point is that people tend to think about
time spent on a project in terms of time elapsed and not time
invested, so even if youve only been working part-time on a
project for two months spread out over half a year, its hard
for you and others within the organization to internalize that
and not think the entire project proceeded slowly and took
half a year to complete. This disappointment at the time
elapsed to a finish a project can also reduce overall morale
and excitement.
The lows of a project are more demoralizing when
working alone. Sand traps that you struggle to get out of,
monotonous work that you need to grind through, and bugs
that seem to defy all understanding become less draining and
more bearable when theres someone else to share the pain
with.
The highs of a project are more motivating when
working as a team. Celebrating an achievement with
teammates is a great way to boost morale. If you work alone,
who are you going to high-five when you get something
working?
The lower morale from solo projects also tends to mean
lower employee happiness and consequently lower
retention. For all these reasons, I strongly believe that
one-person teams should be avoided in growing
organizations and that the minimum team size should be
two. In any project, there might be one-person tasks, but
grouping those tasks thematically into a shared team
context so that people are still working together toward a
shared goal rather than working separately mitigates a
lot of the above risks.
For companies with many ongoing projects or for
products with large surface areas, its tempting to argue
that because theres so much to get done anyways, it
makes sense to just staff a number of one-person teams
(an oxymoron) on orthogonal projects to make some
progress on everything. This can be a symptom that the
organization is undisciplined enough to prioritize and
either cut or serialize projects. InCrossing the Chasm,
Geoffrey Moore argues that one reason many high-tech
companies fail to take their product into the mainstream
market is due to this lack of discipline in limiting the set
of projects to focus on: [7]
This isnt rocket science, but it does represent a kind of
discipline. And it is here that high-tech management shows
itself most lacking. Most high-tech when it comes down to
marketing choices, will continue to shy away from making
niche commitments [T]he claim is made that, although
niche strategy is generally best, we do have time or we
cannot afford to implement it now. This is a ruse, of
course, the true answer being much simpler: We do not
have, nor are we willing to adopt, any discipline that would
ever require us to stop pursuing any sale any time for any
reason.
All of this doesnt mean that working on a team is easy.
Weve all probably had our share of project experiences
where slackers who dont pull their own weight take the
fun out of teamwork. But given the above risks, that
doesnt mean we shouldnt figure out and practice how to
build effective teams.