HappierTeams
Laura Frank @rhein_wein
Software Engineer @codeship
Happy people are
productive people.
Happiness and Productivity
Can a team’s choice of tools
make developers happy, and therefore
more productive?
Yes.
(duh)
Each process and tool impacts how
developers spend their time.
The Happiness
Equation
University of Warwick
Study
• People treated with positive stimuli were, on average, 12%
more productive than the control group
• People treated with negative stimuli were similarly less
productive
• Still, hard to quantify what we consider ‘negative’ and ‘positive’
• tinyurl.com/warwickhappiness
Track Your Happiness
Happiness Metrics
• How do you feel?
• What are you doing right now?
• Do you have to be doing what you’re doing?
• How productive are you being right now?
• Do you want to do what you’re doing?
Time-based pressure is nearly
universally negative
Fun Fact
Commuting to and from work is
typically the unhappiest time in a
person’s day
The Real Happiness Equation
autonomy
+
no interruptions
+
no time pressure
happiness =
– DR DANIEL SGROI, UNIVERSITY OF WARWICK
“The driving force seems to be that
happier workers use the time they
have more effectively, increasing the
pace at which they can work without
sacrificing quality.”
There are several areas within
development where we can
maximize for happiness ✨
Team Communication
Employees report feeling stressed
when they are either being
unproductive or interrupted
All incoming communication needs
to have a process behind it.
Centralized Manager
(Pivotal, Trello, Jira, ZenDesk etc)
Treat your task manager as a means
for persistent communication
Remember that commuting to and
from work is typically the unhappiest
time in a person’s day?
Persistent communication is
essential to a remote team.
A clear, persistent record of business
decisions.
This type of communication is ‘pull-
based’. You can choose when to
consume it and it’s not as disruptive
unless you allow it to be.
Meetings
ಠ_ಠ
– EVERY PERSON EVER
“This meeting could have been
an email.”
Unnecessary meetings are disruptive
and expensive 💸
Meetings are good for complex
discussion…
But they go against the pattern of
persistent communication.
You MUST document the discussion
and outcome of a meeting if you
intend to have a team that can
function remotely.
My team uses Google Docs in place
of many meetings.
Choose one mode of communication only
Try to make it as least disruptive as possible
Document the discussion and outcomes
Architecture Patterns
– MELVIN CONWAY
“Organizations which design systems
are constrained to produce designs
which are copies of the
communication structures of these
organizations.”
Conway’s Law
Any piece of software reflects
the organizational structure that
produced it
If you have three engineering teams
working on one piece of software,
you’ll probably end up with three
pieces of software
super-cool application
super-cool
subsystem
super-cool
subsystem
super-cool
subsystem
The interaction between
components reflects how well teams
communicate.
Similarly, a unified team will self-
separate to tackle a problem with
discrete components.
super-cool service super-cool service super-cool service
super-cool service super-cool service super-cool service
In a SOA or microservices
architecture pattern, each of the
services is autonomous and can
operate independently
A service team can choose the correct
tools — like languages, deployment
processes, and incident management
systems — specific to their component
The pattern for people and the pattern
for software mirror one another.
Conway’s law in action
Smaller teams with a targeted focus
have autonomy over the software
they build.
autonomy happiness
Continuous Deployment
A human-initiated and monitored
deployment is a huge disruption,
distractor, and demotivator.
Deployment should be an automatic
step triggered by a change to a
designated branch in your repo.
We call this
Repository-Driven Deployment.
DevTeam
automated
testsfeature
continuous
delivery
master
timed
releaseproduction
review and merge
review and merge
push
DevTeam
automated
tests
continuous
delivery
timed
release
feature
master
production
review and merge
review and merge
push
• The team shares responsibility for deployment, and each
engineer is empowered to control the flow of his or her code
into production
• Your customers are always getting the best product you have
to offer
– NICK GAUTHIER, CODESHIP
“Embrace the green button, Laura.”
I hate(d) the green button.
😡
If the checks pass, merge it.
From bed. Or from the U-Bahn.
Or wherever.
Incident Management
Interruption is sometimes necessary…
Don’t confuse priority with urgency
Priority measures how important a
task is, relative to other tasks.
Urgency is a measure of how quickly
the task must be completed.
A P0 incident is urgent, and
communication for this incident
requires interrupting people in order to
accomplish the task
– NICO APPEL, TIGHTOPS.COM
“You pay for urgency with
interruption; and you should
understand whether or not you are
getting a good deal.”
Have policies, training, and docs that
allow each developer to solve
incidents assigned to them.
Incident 💥
PagerDuty wakes me up 🚨
I wake my boss up, because I don’t have access
to production logs without his sign off 💩
My boss opens a ticket with the NOC 😫
NOC gives me temporary log/deploy access ✅
I fix stuff 🐛
I merge and manually trigger Jenkins 👔 tasks to deploy
Verification 🏆
With a better system in place, I can
have more autonomy and reduce
the duration of the interruption
PagerDuty wakes me up 🚨
I fix stuff 🐛
I merge my fix and it deploys automatically 🔁
Verification 🏆
Incident 💥
Sleep 😴
Post-mortem 📖
– CAPTAIN OBVIOUS
“If an engineer is on call, make sure
he or she has access to logs, metrics,
and the ability to deploy new code to
production.”
#alwayskeepshipping
thanks!

Happier Teams Through Tools