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.
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!
| Reference: | How to Create Happy Teams from our JCG partner Laura Frank at the Codeship Blog blog. |
