When our teams turned vertical a few months ago, we held a meeting to discuss how to keep the front-end part of the system progressing effectively. There were three front-end developers (including myself) who were moving to three separate, vertical product teams. In my naivete my first suggestion was to increase isolation of teams.

I suggested that we increase isolation of teams, directly giving them more autonomy and independence. This, I thought, would allow teams to move incredibly quickly without getting blocked on inter-team requests. Thankfully my idea was met with less than tepid reception and was never explicitly implemented.

However, for the next few weeks, the newly constructed team I was put in actually did work in a fairly isolated way and we noticed that we were able to move very quickly (with enough front-end devs on the team). But to our dismay, the all-too-familiar problems of poor communication arose again when we had to start creating features that depended heavily on work being done in collaboration with other teams.

So perhaps less communication is a bad idea! No surprises there. With an increase in isolation comes a decrease in technical cohesion and ability to work effectively between teams. An increase in communication however has a number of benefits [1].

For one, shared knowledge of a system allows for a wider understanding of what the system is trying to achieve for the product and the people using it, developers included.

To that end, we can consider a platform that is at service to the following:

• users (UX)
• developers (DX)
• salespeople (business / Sales Enablement)

By including developers in that picture of who the system is serving, DX (Developer Experience) can be considered alongside UX and the business sides of the product [2]. By nature, to improve the DX, communication must be improved so that devs can spend less time communicating unnecessarily and more time doing what they want to do: understanding and building an awesome system.

In order to improve communication, it’s important to understand whether the current channels of communication work for everyone. Some will prefer not to speak up during a meeting for example because they would rather not have the whole room focus on them, but rather share their ideas in their own time after some thinking. Others will prefer direct and detailed discussion on topics they find interesting in front of a whiteboard. Others will happily spend time writing documentation or blogs or commenting on RFCs if they’re given an effective means of doing so within a culture that encourages it.

The following are some simple ways to improve communication within your team:

• A survey to gather information on whether people think the current forms of communication are effective and to allow them to share their own ideas.
• RFCs for big changes or new systems/components/APIs
• Team tech blogs and team product blogs
• A Data Dictionary containing the current state of the structure of product-level objects
• Architectural diagrams to help future developers understand at a glance how the service interacts with others
• A README for every service that includes:
  • broad purpose: why does this service exist from the product’s POV?
  • broad architecture: what is this service’s structure and how does it relate to other services?
  • development details: how does one develop, test and build this service?

This refinement in communication processes should aim to minimise unnecessary communication and maximise understanding when communication is required [3].

To that end, hopefully teams can work effectively across well-established boundaries of the system and everyone’s ideas can be heard.

References

• [1]
• http://johnnyholland.org/2012/06/the-challenges-of-inter-team-communication/
• “Understanding why a decision was made can be just as important as understanding what the decision was”
• “Any development process can be improved by making shared understanding an explicit goal”
• [2]
• https://uxmag.com/articles/effective-developer-experience
• “Effective DX begins with a relationship of trust between app developers and the platform product company. Communication is the foundation for building this trust.”
• [3]
• http://wiki.c2.com/?InterTeamCommunication
• “… if we have to do a project with distributed teams, we break up the teams along boundaries that will minimize communication across them. And we devise our communications to minimize unnecessary communication - because it’s expensive and error-prone [and] maximize understanding when we do communicate across the boundary. "