How to Create Happy Teams

Industry

Reading Time: 6 minutes

As developers, we spend a lot of time optimizing the software we work on. Whether it’s code performance, service availability, or user experience, making things better is a top priority. But we rarely think about how keeping the people that write software happy can also have a positive effect on the quality of our software.

Having worked on remote teams for the last four years, I’m especially interested in how happy teams communicate and work together. Having a highly productive remote team isn’t easy, and there are a lot of choices to consider. I recently gave a talk at Codemotion World Berlin that summed up some of my experiences. I’ll share the main points with you here, and my slides are available at the end of this post.

Why Are Happy Teams Important?

First off, it’s no surprise that happier people are more productive. We have test coverage and uptime reports to measure the performance of software. But is there an easy way to quantify happiness?

Some researchers at the University of Warwick have attempted to come up with a so-called ‘Happiness Equation.’ And a researcher from Harvard created an app, aptly called Track Your Happiness, to attempt to quantify the reasons and conditions relating to happiness. The results of both of these studies have a few common threads.

Universally, people feel happiest when they don’t have a time pressure, aren’t being interrupted, and have autonomy over the task they’re doing. Keeping those three pillars of happiness in mind, we can make some changes as to how our development teams operate in order to keep developers happy and therefore more productive.

Have a Process for Team Communication

It’s common for all types of teams to use a communication platform like Slack, even if they’re located in the same physical office. Slack is a bit trendy, so take care to evaluate how meaningful it is to your team.

Very importantly, all communication must have a process behind it, as well as clearly defined expectations. If a developer is getting communication from multiple channels, it can be a huge interruption and overwhelming. Instead, funnel all incoming communication to a centralized task manager, whether it’s Tracker, Jira, ZenDesk for support, etc. This makes it much easier to manage what requires attention, and is less disruptive than checking Twitter, email, GitHub, and Slack independently.

Additionally, if you intend to have remote employees, it’s imperative that all team communication is persistent. A task manager is a good fit for this because it allows for the communication record to be persistent and searchable. If another engineer has a question about business logic related to a certain feature, it’s much easier to read through a conversation on a Tracker ticket than to reach out to individuals to try to piece together the decision logic.

Make Your Meetings Persistent

“This meeting could have been an email,” says every person that’s ever been to a pointless meeting.

Meetings are disruptive and expensive — when they aren’t needed. A necessary meeting, when a complex topic needs a lot of discussion, can be extremely productive. But pulling engineers away from their work in order to attend a meeting about something like project status or for information dissemination can be incredibly frustrating.

To boot, the discussions that happen during the meetings aren’t persistent, and it’s hard to communicate the meeting’s discussions and outcomes to those who weren’t there. Persistent communication is vital to a highly productive remote team.

If a meeting is necessary, make it persistent by recording it or by typing up meeting notes (like we’re in the 1970s!). A good meeting alternative is a Google Doc. Everyone can read and comment, and all of the communication is recorded in the document. Here at Codeship, we use Google Docs for everything from HR discussions to planning engineering sprints.

Sign up for a free Codeship Account

Consider How Software Architecture Influences Team Organization

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” So says Melvin Conway, a somewhat-famous computer scientist, in what has now become known as Conway’s Law. In clearer terms, Conway’s Law states that any piece of software reflects the organizational structure that produced it.

If you ask three teams to work on one piece of software, you’ll probably end up with three components. Similarly, if you ask a unified team to work on three pieces of software, that team will self-separate into smaller teams. Imagine if you asked a team of 25 people to work on a design for a car. It’s not likely that all 25 people will sit in a room and work on all parts; instead, some people will work on the engine, some on the user controls in the interior, and some on the safety features. People self-organize into smaller units in order to have autonomy over their processes.

With this pattern, we can think about how software architecture can influence the way our teams are organized. If you design your application to have separate components from the start — even if the division is something simple like a React front-end with a Go API — you are allowing the engineering teams to have more autonomy over their tools and processes. They can better dictate how time is spent, how the workflow should be organized, and define their own deployment cycles.

Paying close attention to software architecture will have an impact on the autonomy of development teams, and therefore on the productivity of those teams.

Share Responsibility with Continuous Deployment

A human-initiated and monitored deployment is a huge disruption, distractor, and demotivator. It puts responsibility on the shoulders of one person only and can really disrupt a person’s workday.

Opting for an automated deployment workflow can take away the personal responsibility for deployment (and the disruptions associated with it) and make deployment and shipping code a shared responsibility of the entire engineering team.

With a ‘repository-driven development’ process — that is, a system where pushes to designated branches in a version control system trigger either merges or deploys — engineers have a more limited focus. Instead of spreading attention across coding, reviewing, merging, triggering deployments, running test suites, and monitoring production, developers can just focus on coding and then reviewing the code of their peers.

The other steps happen automatically, leaving developers with more uninterrupted time to focus. And that’s the goal, right?

Empower Your Incident Management Process

Sometimes, interruption is absolutely necessary. Tools like PagerDuty can help manage incidents and alert the right people about the incident’s progression.

If you have some kind of incident management system in place, be sure that each person who is on call to handle incidents has the authority and autonomy to solve the problems in the most timely manner. Have documentation, processes, training, and tooling to support the person on call.

Most incident or monitoring tools allow you to attach a runbook to each of the incident triggers so that the person on call has an easy resource to follow. Do this! Document problems and their solutions to minimize disruption for your team.

Have any other tips on how to create happier, more productive teams? Leave your thoughts in the comments!

Subscribe via Email

Over 60,000 people from companies like Netflix, Apple, Spotify and O'Reilly are reading our articles.
Subscribe to receive a weekly newsletter with articles around Continuous Integration, Docker, and software development best practices.



We promise that we won't spam you. You can unsubscribe any time.

Join the Discussion

Leave us some comments on what you think about this topic or if you like to add something.

  • The one thing I have found that is at least as important as all of the above in terms of happiness is the following: Don’t hire assholes.

    Companies can often be blinded by the talent of a person to the point where they overlook obvious social clues that this person is in it for themselves, instead of all of us.

    This can quickly erode happiness at a company. After all, even remote, no one looks forward to dealing with “that guy.” People dread it. They avoid it, ruining carefully laid out communication.

    The solution is to not have that kind of person on your team. No matter how technically amazing they are, value culture and personality above all else.

    Orient your interview process away from the tech heavy questions, and more towards questions that can give you insight about how they have interacted with others in the past. You can pretty quickly pick up on the “me first” sort of person in such discussions.

    At the end of the day, taking your time to hire the right culture fit AND technical fit will benefit you and your company much better than just looking at the technical side, and will start you on the right foot to make all of the above suggestions a success.

    • Great advice Sean. I whole-heartedly agree. Thanks for taking the time to write this. Have you ran into this issue before with potential hires? Which types of questions would you suggest to identify the “me first” sort of person?

      Thanks!

      • I have experienced coworkers and bosses overlook obvious cultural issues (or ignore those concerns when voiced by others) because of the excitement of what a candidate could bring to the table from a technology stand point. The issue has always been how do you quantify these gut feelings that something might not work out?

        First, you have a repeatable process for hiring that you do with every candidate. Second, you spend at least one interview talking about their career history.

        Both of those might seem obvious, but you would be surprised about how many people wing it per job and even per candidate.

        More to the second question, the interviews should be less technical and more how they dealt with particular situations. What were the positive experiences at their previous jobs? What were the negatives? How did they work with others on their team? Their boss? How was their performance measured?

        Couple these sorts of questions with more pointed “Tell me about when someone else messed up and you had to help fix it” type questions, and you will start seeing the folks who are “me” vs “we.”

  • Jen Neves

    I’m not quite understanding.

    • Jen Neves

      This is pretty astounding. Monitoring teammate’s downtime on a psych level is abhorrent at best. News flash – good software doesn’t require what you are doing @codeship.

      • Jen Neves

        Here’s a good model for eng teams and happiness – Yoav Shapiro – he was architect at Happiness and is now at Jana Mobile.

  • Pingback: 25-11-2015 - Links - Magnus Udbjørg()

  • Pingback: Professional Development 11/30/15 – 12/06/15 | The Software Mentor()

  • Pingback: Professional Development – 2015 – Week 50()

  • Pingback: Links, well it is almost X-mas... - Magnus Udbjørg()