DEV Community

Alan Barr
Alan Barr

Posted on

How much miscommunication comes from assumptions?

Have you been in the scenario where you and your coworkers are busy implementing a project and in the middle it is exposed that everyone's assumptions around the topic are not the same? How did you deal with that?

Top comments (1)

Collapse
 
zspencer profile image
Zee

Hey Alan,

Yes! All the time! Mismatches in assumptions is the norm in software, which is why effective teams focus on surfacing those assumptions in timely, healthy ways.

The important things to focus on are:

  • What are the gaps? I really like the Facts, Operations, Goals framing as it provides non judgmental signposts to prompt discussion of the gaps. And it makes it clear that assumptions are inter-related.
  • Who are those gaps between? Sometimes the gaps are intra-role (Engineers having different ideas of the project goals), and sometimes they are inter-role (Engineers and Product disagreeing on how to most efficiently achieve the goals).
  • How wide are they? Small gaps can sometimes go unnoticed, but compound in a way that ultimately results in big problems. Techniques such as continuous deployment and behavior driven development and design thinking workshops are great at bringing these assumptions to light by focusing the team on a tangible artifact that represents their underlying assumptions.
  • How big of an impact do they have on the team's function? For instance, if a new team member assumes a "fact" that their non-commit-oriented contributions will be overlooked in performance and compensation review, they may be less willing to spend time and attention supporting their peers; resulting in worse outcomes for the team, product and organization.
  • And of course, how much does it cost to fix? In the above example, it could be a simple conversation with the new team member could mitigate their assumption that they'll be considered a low-performer for pairing. Or, it may take several months of positive reinforcing feedback and a few stages through the review cycle so that the new team member can observe their new teams truth: That they are useful and valued even if their name isn't on the most commits.

In any case, there is never 1 magic wand to bring assumptions back in line, but in my experience part of being an engineering leader is proactively identifying these gaps and making an appropriate response for the particular context.