Complexities of Communication on a Development Team

Building together.
Living together.
Improving together.

The human side of software development.

Applying development practices against every-day life, and applying life lessons to development

This is developer++

The success or failure of any development project is influenced by many things, including, but not limited to:

  1. Clarity of specifications
  2. Available business resources to answer questions
  3. Amount of  time to complete proper implementation
  4. Available tools
  5. Technical knowledge
  6. Available hardware
  7. Priority
  8. Communication

None of these is as important as communication.

It’s no secret how paramount communication is to a successful project, but have you ever stopped to consider how complex communication becomes within even a small team?

Let’s build a fictional team working on an internal project to illustrate:

  1. 2 Developers – Amy and Bart
  2. Business Analyst – Carly
  3. Development manager / director – Donna
  4. Product owner – Eric
  5. 2 Customers in Eric’s department- Frieda and Glen
  6. Company Executive

Below is a diagram that indicates the level of communication required between our fictional team based on the thickness of the line connecting them.  The colour of the lines is just for clarity.

It gets ugly quickly doesn’t it?

It Gets Worse

This is admittedly a simple example.
Adding more team members and roles will make this get much more complex.

  1. Designers
  2. QA
  3. Project managers
  4. Another leadership level
  5. Release managers
  6. Help desk
  7. User Documentation
  8. Technical Documentation
  9. etc

Many times there are people responsible for multiple roles, however, that really has no impact on the amount or type of communication required for a successful project.

In fact, it’s a very sharp 2 edged sword.  If your QA resource is also responsible for user documentation, it’s 1 less person you need to communicate with which is great if you get along.

Now if you don’t get along…. …. … relationships are hard.

Be Proactive

Get talking to your team and validate your understanding sooner than later.  If that can be handled in a quick QA feedback loop, that might be good enough.  Even better is walking over to QA and making sure you have the same expectations and understanding.

Next time you wonder if one of your team members is aware of a change to a technical standard, business rule, or change in specs, remember this simple diagram and don’t assume they know unless you were with them when you received the information.

In the case where they have heard about it, chances are very high that they experienced a different reality regarding the new info in one or more ways:

  1. Heard it from someone different than you with a slightly different twist
  2. Heard about it from multiple people with slightly differing details
  3. They have reached out to other resources to fill in the blanks
  4. Perceived it as a different level of importance compared to you
  5. Heard the same thing but understood it completely differently

Take advantage of the different interpretations

This last item on the list above is the silent killer.  Everybody has their own experiences, strengths, weaknesses, biases, and blind spots.

This results in each person living in a slightly different reality than everyone else around them which in turn can process the same information into a different result from someone standing right next to them.

Start Gossiping

Tapping into these different interpretations and using them to arrive at the best understanding or decision is beneficial and should be considered in any discussion.

This is how gossip works, everybody sees / hears / insinuates different things from a juicy office politics topic, and you learn more by seeking out new opinions and sharing your own.  The rumour mill can get ugly, but at least its usually feeding off of many interpretations of the same data.

(Don’t really start gossiping though, it easily becomes a bad habit and is far more often destructive than not)

Using the fictional team above, I’m sure everybody would come up with something different to illustrate their communication patterns, and also have a different opinion on the volume of communication between the parties.

That doesn’t make my version wrong, and it sure doesn’t make it right.  It’s an interpretation.

What would yours look like?

Thanks for visiting!

If you enjoyed this article, please subscribe to my newsletter below and I'll make sure you are notified of any future articles

As a thank you for signing up, you will receive my free ebook - Iterative Development for the Human Condition. This book takes a look at how the same principles used in software development can be used to effect positive changes at a personal level.

[nm-mc-form fid="1"]

Leave a Reply

Your email address will not be published. Required fields are marked *