Communication and Organisational Structures

Generally speaking, programmers are not the best communicators. They are great at communicating with computers but maybe not so great at communicating with other human beings. This is not because they lack the genes, but simply because skills progress as they are being practiced. And programmers typically practice the skill communication less.

A group of developers working together in the same context for some time, start to develop ways to communicate effectively with each other. This can be a conscious process that they follow such as Daily Standup. Or it can be an unconscious protocol that they learn, such as knowing that Person A will always help non-grudgingly if asked, unless she has her headphones on.

However, when these processes and protocols are not developed yet, things start to slow down. E-mail becomes preference over face to face talk, assumptions become preference over facts, avoid of conflict becomes preference over being direct and honest.

As if things are not complicated enough, almost always involved teams have different perspectives of visions and goals. Their performance are reviewed in isolation. They have a local view of success and efficiency. So rarely two teams can prioritize a list of features in exactly the same order, even if they work for the same organisation’s success.

This is why, things that can be handled pretty smoothly within the boundaries of a team, can take a long time when multiple teams get involved. Things go back and forth, sometimes multiple times. A work item can wait on the board sometimes for weeks, until these teams finally have a common understanding of the problem space, and agree on a viable solution. Sometimes this never happens.

It’s no surprise that, often the lead time of an end-to-end feature is more dependent on how many teams being involved, rather than how big the technical challenge is.

Observing this pattern is pretty straightforward. One can simply measure the time passed for each item in progress, and categorize this time in 3 groups:

  1. Value added work: Time spent when a developer working on an item
  2. Re-work: Time spent when a developer is re-working on something which was claimed to be done (a bug, a late design change, miscommunication of needs etc..)
  3. Idle: Time spent when no one is working on that item, but it is waiting for someone to do something on it.

Whenever I made this observation on items which are handled inside a team, I saw that A is often the biggest piece of the pie. When I observed the same for items that require multiple teams’ work, B+C almost always dwarfed A.

Effective communication, or lack of it, makes the biggest impact on how fast an organisation delivers. With this in mind, achieving effective communication should be the primary concern when dividing a large group of developers into smaller, more effective teams.

As usual, when making this decision, one size fits all approaches such as “Cross-functional teams are the best.”, or “People work more efficiently with others performing the same function” should be avoided. Instead, it is better to look for future to see which kind of challenges the organisation will face, and how teams can be formed to overcome most of these challenges within team boundaries.

For example, if an organisation wants to deliver features fast, cross-functional end-to-end teams work better. Because these teams can deliver end-to-end features within their boundaries. If the future challenges are accumulated around consistency and stability of a layer, then a horizontal / functional team might serve better. As functional teams can agree and work on a complete layer within their boundaries.

To summarize, some general guidelines to optimize for communication can be:

  1. Group people so that they can handle majority of the incoming work within the team boundary. This will reduce communication errors and waiting times between teams.
  2. Reduce dependencies between teams, so each team can work simultaneously without disrupting each other’s work. This will reduce emergent context switches and focus shifts.
  3. Avoid reshuffling teams often. This will reduce the time wasted on Forming -> Storming -> Norming -> Performing cycles.

Originally published at seyit-abbasoglu.blogspot.com.