One of the core skills of our client services team is the ability to communicate clearly, efficiently, and humanely to each other and to our clients. It’s this communication that gets us through gnarly project roadblocks and beyond the purely technical solutions. Unfortunately, this can lead to the dreaded wave of “calls”, “syncs”, “touch-bases”, and “meetings” which eat up our calendar hours.

As much as these terms can make our stomachs collectively turn, they are a critical component of the success of our projects. How do we turn this communication from something we avoid into something we look forward to?

Min-maxing participants and empowerment

The first step is to define the participants in a meeting. Each participant should be able to provide a unique perspective to the topic at hand. On many projects, there are multiple developers, designers, testers, and project managers, and in many cases only one person from each group is actually required for the weekly syncs.

It’s easy to default attendance to whoever has “senior”, or “lead”, or “manager” somewhere in their title. But in a balanced and capable team, it is often better to share the load of decision making among the greater team, especially as projects move on and individuals develop areas of expertise. In some cases, it can work well to simply round-robin participation from different subgroups. This helps to prevent one person from being overloaded with calls and meetings while giving the whole team a chance to drive the project direction.

A meeting should end up with a small group of individuals attending. I find it works best with no more than 4 people. Each person should have distinct contributions to make, and together the group should be empowered to make decisions. Sometimes discussion reveals further dependencies to resolutions, but ideally a meeting is a chance to show your team that you trust them and their expertise.

Action items and responsibilities

“What did we decide on the last call?” is one of the most frustrating ways for teams to start a meeting. Rehashing discussions and decisions leaves participants feeling like their time was wasted and that no progress was made. With a bit of guidance (typically from project managers), meetings can be made more effective with some documentation.

I find the best meeting notes are those that are distributed to the whole team and indexed, such as in an app like Basecamp or Google Groups. Each note should contain the participants, one-line summaries of the discussion, and action items at the end. Every action item should have a clear owner and notes of any dependencies, along with any external constraints. For example:

“Investigate why drush is broken.”

is significantly less useful than

“Angus will talk to the multifield maintainer on why drush updatedb broke on the last build. This needs to be fixed before Tuesday so we can do our next production deployment.”

Having action items and clear responsibilities documented solves a whole host of communication problems, while keeping the rest of the team up to date. Reading is so much faster than listening and speaking, so it allows the rest of the team to keep up to date without the same time commitment.

Iteration, Evaluation, and Communication

Standing meetings can be useful to force communication, but beyond daily standups, they should only be used as a last resort. Early in a project they can really help with architectural discovery, or in bootstrapping new teams. As time goes on, standing meetings can often become longer and have more and more people invited to them. It’s important to continually evaluate a meeting, and to willingly burn it to the ground to refocus and rebuild.

Every meeting participant should be empowered to call the existence of a meeting into question. When team members start grumbling about a recurring call, they should be able to discuss their feelings openly and honestly.

Just as we never stop aiming to make ourselves better developers, as teams we must never stop trying to improve and optimize our communication. By following these steps, your teams will be well on the path towards meeting nirvana.

If you enjoyed this Article, you may also enjoy...

Andrew Berry

Thumbnail
Andrew Berry is a architect and developer who works at the intersection of business and technology.