How Organic Communication Helps Teams Succeed
Good software starts with the people who create it
In February 2001, a group of seventeen people, from all disciplines in software, drafted the Agile Manifesto as reflection of the current state of best principles in software development.
What was revolutionary about the Agile Manifesto was this notion that how people interact with each other is more important than their process or tools, and that those interactions can have a direct impact on product outcomes.
Individuals & Interactions over Processes & Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation
Responding to Change over Following a Plan
Collaboration, interaction, responding — These are all types of communication, and good communication is essential to create a high functioning, cohesive team. There are three common types of communication that happen in the workplace.
- Durable Communication: Written or visual, like reports, email, or user stories, wireframes or mockups (not to be confused with production assets; they are not intended for communication with the team)
- Explicit Communication Events: Meetings
- Organic Communication: Communication that “just happens” as a result of collaboration. There’s a sub-set of organic communication that I like to call Spontaneous Ephemeral Communication (think water-cooler conversations). Decisions are often made here. Sometimes seemingly small decisions which can have lasting effects on a project.
Durable Communication
This type of communication is written or rendered. Email, Slack, user stories, design artifacts — these all serve the purpose of communication and can be extremely valuable. We work hard to cut down on email. It’s a huge time suck and often you can transfer the same information via other means. We can also cut down on user stories and design artifacts by never spending effort to create them if we can’t validate their utility.
Explicit Communication Events
These are usually meetings. Generally, the purpose of a meeting is to share information to gain alignment, to “get everybody on the same page”
Think of your day today, how many meetings have you had? Now think, how many of these meetings have been useful?
Sometimes you learn something useful, but often it’s too late. You may have already taken the action that would have changed if you had had the right information sooner. More often than not meetings devolve into stakeholders asking why you did things the way you did them.
“How come the logo isn’t bigger?”
“Why isn’t it more like Amazon?”
“Why did you decide to use Postgres instead of MySql?”
They ask these questions because they weren’t there while you were gathering data and making your decisions. They have less context. You end up justifying your decisions and rehashing arguments that you already had in your own head. And that’s terrible.
You should never have to sell your work to your own team.
But the only way to prevent this from happening is by providing an environment that is rich in organic communication.
Organic Communication
This communication happens as a direct result of collaboration. As we work together, our knowledge of the work we are doing is deepened, extended, and distributed. It is communication without the intention of communication. Vast amounts of detailed information move around during these collaborations and they do more for accurately sharing information than any meeting could.
We promote organic communication at Pivotal Labs by having “small teams, working together, in the same place.” This is one of our mantras at Labs, and it’s worth breaking down.
Small Teams
Managing team size allows us to manage communication overhead. Communication overhead is the amount of effort it takes to fully communicate an idea across the whole team and is directly proportional to the number of relationships on the team, not the number of individuals.
Imagine a group of three people. There are three relationships among these people.
Relationships are good, because interesting things come of them. People get to play off of each other and use each other’s brains to come up with more interesting ideas.
If you add one more person though, you’ve doubled the number of relationships. This means that you’ve also doubled the communicative overhead for the group. It becomes twice as hard to communicate an idea to the whole team.
You’ve probably heard of Amazon’s “2 pizza teams.”
Jeff Bezos says that if a team is too large to be fed by two pizzas, it should be broken up. This simple rubric helps mitigate these communication issues.
Here’s the formula for calculating communicative overhead:
n(n-1)/2
This means if there are six people, there are 15 relationships to manage. If there are ten people, there are 45 relationships between them. There goes the pizza!
Again, you need sufficient brain pairs to make great ideas, but not so many people that you hinder understanding.
So, small teams are a big deal. And now you have mathematical proof.
Working Together
Another practice which serves to enable organic communication is called Pair Programming. This is when you have two developers working together on the same code, same monitor, one keyboard. 90 percent of the engineering at Pivotal Labs is done in pairs.
There are lots of benefits to pairing. If you’ve ever worked on a Crossword puzzle with a friend, you’ll know that you get faster, more elegant solutions with fewer errors.
What’s really important to us though is team continuity, and reduced need for handoffs. Pair rotation allows each team member to become familiar with the code-base very broadly. More generally, it allows for organic communication all day, every day. This reduces the need for explicit communication like meetings, because people get their information from the normal process of doing their work. That means that if someone on the team is sick or (in the worst scenario) gets hit by a bus, the project can keep going without them.
At Pivotal Labs, we also pair cross-functionally: designers with product managers, product managers with engineers, engineers with designers, and all of us with our clients.
Pairing with our clients, and co-creating their product means that we no longer need a hand-off event (explicit communication event), and the need for the durable communication of comprehensive documentation is significantly reduced. The client team, when they’re done working with us at our office, has all of the information they need to carry on the project. They understand the code-base intimately and they know the context around every decision that was made. And none of this needed to be explicitly communicated to them, it’s just a byproduct of doing the work together.
In the Same Place
Physical co-location is really what enables the best pairing and collaboration. To the best of our ability, we keep our teams in the same place. We do some remote pairing, but it’s on the same schedule as the rest of the team’s work, and remote pairs are expected to join (remotely) in all of our explicit communication events.
Along with co-location, our teams are 100 percent dedicated to a single project.
When the team is all together, all day, every day, it makes it very easy for organic communication to happen. If an engineer has a question about a user story, or a PM has a question about a design mock-up, we don’t send an email and wait two days for a response. We literally turn to the person next to us and say “Hey! What’s the deal with this?” (This is an example of spontaneous ephemeral communication)
Recap
We have three types of communication that happen on a team: Durable communication, explicit communication events, and organic communication.
All of them have their place, but organic communication is the richest and most productive. Organic communication could replace the other two, but the other two can never truly replace organic.
There are three ways that we promote organic communication and help to cut down on the other two:
- Small teams
- Working together
- In the same place
(and I’ll add: All day every day.)
Finally, much of good communication comes down to courage. You have to create the right environment for good communication, and then people have to step up and do it.
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced and incorporated continuously through development and innovation, because good software is never finished.
