We often optimize our software for performance, but what also optimizing our development teams for happiness? Take a look at how the tools you choose for your development team can impact developer happiness, and learn how to keep your teams happier and more productive. *The graph on slide 3 is fabricated data, because studies also show that people are more likely to believe statements accompanied by scientific data.*

1. HappierTeams
Laura Frank @rhein_wein
Software Engineer @codeship

2. Happy people are
productive people.

3. Happiness and Productivity

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

5. Yes.
(duh)

6. Each process and tool impacts how
developers spend their time.

7. The Happiness
Equation

9. 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

10. Track Your Happiness

11. 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?

12. Time-based pressure is nearly
universally negative

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

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

15. – 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.”

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

17. Team Communication

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

19. All incoming communication needs
to have a process behind it.

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

22. Treat your task manager as a means
for persistent communication

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

24. Persistent communication is
essential to a remote team.

26. A clear, persistent record of business
decisions.

27. 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.

28. Meetings
ಠ_ಠ

29. – EVERY PERSON EVER
“This meeting could have been
an email.”

30. Unnecessary meetings are disruptive
and expensive 💸

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

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

33. My team uses Google Docs in place
of many meetings.

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

36. Architecture Patterns

37. – MELVIN CONWAY
“Organizations which design systems
are constrained to produce designs
which are copies of the
communication structures of these
organizations.”

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

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

40. super-cool application

41. super-cool
subsystem
super-cool
subsystem
super-cool
subsystem

42. The interaction between
components reflects how well teams
communicate.

43. Similarly, a unified team will self-
separate to tackle a problem with
discrete components.

44. super-cool service super-cool service super-cool service

45. super-cool service super-cool service super-cool service

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

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

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

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

50. Continuous Deployment

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

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

53. We call this
Repository-Driven Deployment.

54. DevTeam
automated
testsfeature
continuous
delivery
master
timed
releaseproduction
review and merge
review and merge
push

55. DevTeam
automated
tests
continuous
delivery
timed
release
feature
master
production
review and merge
review and merge
push

56. • 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

57. – NICK GAUTHIER, CODESHIP
“Embrace the green button, Laura.”

58. I hate(d) the green button.
😡

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

60. Incident Management

61. Interruption is sometimes necessary…

62. Don’t confuse priority with urgency

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

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

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

66. – NICO APPEL, TIGHTOPS.COM
“You pay for urgency with
interruption; and you should
understand whether or not you are
getting a good deal.”

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

68. 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 🏆

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

70. PagerDuty wakes me up 🚨
I fix stuff 🐛
I merge my fix and it deploys automatically 🔁
Verification 🏆
Incident 💥
Sleep 😴
Post-mortem 📖

71. – 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.”

72. #alwayskeepshipping

73. thanks!