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?

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.

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

thanks!