Happier Teams
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?
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.
!
– 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.
Dev Teamautomated
testsfeature
continuous deliverymaster
timed releaseproduction
review and merge
review and merge
push
Dev Teamautomated
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