Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Happier Teams Through Tools


Published on

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

  • Dating for everyone is here:
    Are you sure you want to  Yes  No
    Your message goes here
  • Instantly Hard-Wire Your Mind For Millionaire SUCCESS ▲▲▲
    Are you sure you want to  Yes  No
    Your message goes here
  • How to start a wildly profitable 7 figure marketing business and get your first commission check tonight, click here 
    Are you sure you want to  Yes  No
    Your message goes here
  • Why is my hair falling out? 9 triggers of female hair loss 
    Are you sure you want to  Yes  No
    Your message goes here
  • How can I improve my memory before an exam? How can I improve my study skills? learn more... ■■■
    Are you sure you want to  Yes  No
    Your message goes here

Happier Teams Through Tools

  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
  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’ •
  9. Track Your Happiness
  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?
  11. Time-based pressure is nearly universally negative
  12. Fun Fact Commuting to and from work is typically the unhappiest time in a person’s day
  13. The Real Happiness Equation autonomy + no interruptions + no time pressure happiness =
  14. – 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.”
  15. There are several areas within development where we can maximize for happiness ✨
  16. Team Communication
  17. Employees report feeling stressed when they are either being unproductive or interrupted
  18. All incoming communication needs to have a process behind it.
  19. Centralized Manager (Pivotal, Trello, Jira, ZenDesk etc)
  20. Treat your task manager as a means for persistent communication
  21. Remember that commuting to and from work is typically the unhappiest time in a person’s day?
  22. Persistent communication is essential to a remote team.
  23. A clear, persistent record of business decisions.
  24. 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.
  25. Meetings ಠ_ಠ
  26. – EVERY PERSON EVER “This meeting could have been an email.”
  27. Unnecessary meetings are disruptive and expensive 💸
  28. Meetings are good for complex discussion… But they go against the pattern of persistent communication.
  29. You MUST document the discussion and outcome of a meeting if you intend to have a team that can function remotely.
  30. My team uses Google Docs in place of many meetings.
  31. Choose one mode of communication only Try to make it as least disruptive as possible Document the discussion and outcomes
  32. Architecture Patterns
  33. – MELVIN CONWAY “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”
  34. Conway’s Law Any piece of software reflects the organizational structure that produced it
  35. If you have three engineering teams working on one piece of software, you’ll probably end up with three pieces of software
  36. super-cool application
  37. super-cool subsystem super-cool subsystem super-cool subsystem
  38. The interaction between components reflects how well teams communicate.
  39. Similarly, a unified team will self- separate to tackle a problem with discrete components.
  40. super-cool service super-cool service super-cool service
  41. super-cool service super-cool service super-cool service
  42. In a SOA or microservices architecture pattern, each of the services is autonomous and can operate independently
  43. A service team can choose the correct tools — like languages, deployment processes, and incident management systems — specific to their component
  44. The pattern for people and the pattern for software mirror one another. Conway’s law in action
  45. Smaller teams with a targeted focus have autonomy over the software they build. autonomy happiness
  46. Continuous Deployment
  47. A human-initiated and monitored deployment is a huge disruption, distractor, and demotivator.
  48. Deployment should be an automatic step triggered by a change to a designated branch in your repo.
  49. We call this Repository-Driven Deployment.
  50. DevTeam automated testsfeature continuous delivery master timed releaseproduction review and merge review and merge push
  51. DevTeam automated tests continuous delivery timed release feature master production review and merge review and merge push
  52. • 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
  53. – NICK GAUTHIER, CODESHIP “Embrace the green button, Laura.”
  54. I hate(d) the green button. 😡
  55. If the checks pass, merge it. From bed. Or from the U-Bahn. Or wherever.
  56. Incident Management
  57. Interruption is sometimes necessary…
  58. Don’t confuse priority with urgency
  59. Priority measures how important a task is, relative to other tasks.
  60. Urgency is a measure of how quickly the task must be completed.
  61. A P0 incident is urgent, and communication for this incident requires interrupting people in order to accomplish the task
  62. – NICO APPEL, TIGHTOPS.COM “You pay for urgency with interruption; and you should understand whether or not you are getting a good deal.”
  63. Have policies, training, and docs that allow each developer to solve incidents assigned to them.
  64. 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 🏆
  65. With a better system in place, I can have more autonomy and reduce the duration of the interruption
  66. PagerDuty wakes me up 🚨 I fix stuff 🐛 I merge my fix and it deploys automatically 🔁 Verification 🏆 Incident 💥 Sleep 😴 Post-mortem 📖
  67. – 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.”
  68. #alwayskeepshipping
  69. thanks!