Happier Teams Through Tools

If you like this presentation – show it...

Slide 0

Happier Teams Laura Frank @rhein_wein Software Engineer @codeship

Slide 1

Happy people are productive people.

Slide 2

Happiness and Productivity

Slide 3

Can a team’s choice of tools make developers happy, and therefore more productive?

Slide 4

Yes. (duh)

Slide 5

Each process and tool impacts how developers spend their time.

Slide 6

The Happiness Equation

Slide 7

Slide 8

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

Slide 9

Track Your Happiness

Slide 10

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?

Slide 11

Time-based pressure is nearly universally negative

Slide 12

Fun Fact Commuting to and from work is typically the unhappiest time in a person’s day

Slide 13

The Real Happiness Equation happiness = autonomy + no interruptions + no time pressure

Slide 14

“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.” – DR DANIE L SG ROI , UNIVE R SIT Y OF WARWICK

Slide 15

There are several areas within development where we can maximize for happiness ✨

Slide 16

Team Communication

Slide 17

Employees report feeling stressed when they are either being unproductive or interrupted

Slide 18

All incoming communication needs to have a process behind it.

Slide 19

Slide 20

Centralized Manager (Pivotal, Trello, Jira, ZenDesk etc)

Slide 21

Treat your task manager as a means for persistent communication

Slide 22

Remember that commuting to and from work is typically the unhappiest time in a person’s day?

Slide 23

Persistent communication is essential to a remote team.

Slide 24

Slide 25

A clear, persistent record of business decisions.

Slide 26

This type of communication is ‘pullbased’. You can choose when to consume it and it’s not as disruptive unless you allow it to be.

Slide 27

Meetings ಠ_ಠ

Slide 28

“This meeting could have been an email.” – E VERY P ER SO N EVER

Slide 29

Unnecessary meetings are disruptive and expensive

Slide 30

Meetings are good for complex discussion… But they go against the pattern of persistent communication.

Slide 31

You MUST document the discussion and outcome of a meeting if you intend to have a team that can function remotely.

Slide 32

My team uses Google Docs in place of many meetings.

Slide 33

Slide 34

Choose one mode of communication only Try to make it as least disruptive as possible Document the discussion and outcomes

Slide 35

Architecture Patterns

Slide 36

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” – M E LVIN CO NWAY

Slide 37

Conway’s Law Any piece of software reflects the organizational structure that produced it

Slide 38

If you have three engineering teams working on one piece of software, you’ll probably end up with three pieces of software

Slide 39

super-cool application

Slide 40

super-cool subsystem super-cool subsystem super-cool subsystem

Slide 41

The interaction between components reflects how well teams communicate.

Slide 42

Similarly, a unified team will selfseparate to tackle a problem with discrete components.

Slide 43

super-cool service super-cool service super-cool service

Slide 44

super-cool service super-cool service super-cool service

Slide 45

In a SOA or microservices architecture pattern, each of the services is autonomous and can operate independently

Slide 46

A service team can choose the correct tools — like languages, deployment processes, and incident management systems — specific to their component

Slide 47

The pattern for people and the pattern for software mirror one another. Conway’s law in action

Slide 48

Smaller teams with a targeted focus have autonomy over the software they build. autonomy happiness

Slide 49

Continuous Deployment

Slide 50

A human-initiated and monitored deployment is a huge disruption, distractor, and demotivator.

Slide 51

Deployment should be an automatic step triggered by a change to a designated branch in your repo.

Slide 52

We call this Repository-Driven Deployment.

Slide 53

push Dev Team automated tests feature review and merge continuous delivery master review and merge production timed release

Slide 54

push Dev Team automated tests feature review and merge continuous delivery master review and merge production timed release

Slide 55

• 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

Slide 56

“Embrace the green button, Laura.” – NICK GAUT HIE R , CO DE SHIP

Slide 57

I hate(d) the green button.

Slide 58

If the checks pass, merge it. From bed. Or from the U-Bahn. Or wherever.

Slide 59

Incident Management

Slide 60

Interruption is sometimes necessary…

Slide 61

Don’t confuse priority with urgency

Slide 62

Priority measures how important a task is, relative to other tasks.

Slide 63

Urgency is a measure of how quickly the task must be completed.

Slide 64

A P0 incident is urgent, and communication for this incident requires interrupting people in order to accomplish the task

Slide 65

“You pay for urgency with interruption; and you should understand whether or not you are getting a good deal.” – NICO APP E L, T IGHTOPS.COM

Slide 66

Have policies, training, and docs that allow each developer to solve incidents assigned to them.

Slide 67


Slide 68

With a better system in place, I can have more autonomy and reduce the duration of the interruption

Slide 69


Slide 70

“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.” – CAP TAIN O BVIO US

Slide 71


Slide 72


Slide 73