Managers and team members alike can often be observed drawing the convenient conclusion that some recent mishap was simply a communication problem.

This conclusion is convenient because, in practice, it’s an excuse to do nothing! After all, aren’t humans (being humans) prone to mis-communication?

Now, if you accept that an inability to communicate is a fundamental characteristic of humans, you really have to expect (and tolerate) all sorts of problems in any environment where humans interact in pursuit of some common objective!

Of course, this assumption (thus stated) is problematic.  After all, humans, relative to any other creature we care consider, are remarkably good communicators. What’s more, it’s easy to identify any number of complex environments where people communicate effectively to consistently perform activities of extraordinary precision (consider, for example, an operating theatre or an airport traffic-control centre).

I put it to you that most communication problems aren’t problems at all: they’re merely symptoms of a deeper problem. Furthermore, our willingness to classify business issues as communications problems:

1. Is insulting to our team members: who almost certainly possess sufficient communication capabilities
2. Prevents us from investigating (and resolving) the root cause of the issue in question

In my experience, almost all the issues that are conveniently classified as communication problems are actually process design problems. And, in most cases, the problem is that a hand-off is necessitating the transfer of complex information from one person to another.

In such cases, it’s important to recognize that complex information (almost by definition) cannot be transferred from one team member to another without information loss. Therefore, it is incumbent upon management to redesign the process so as to ensure that either:

1. These hand-offs are eliminated
2. The requirement to transfer complex information is eliminated

Example A: eliminate hand-offs

As you probably know, we encounter this problem in major-account sales (engineer-to-order) environments. Salespeople take a brief, conceptualize and sell a solution and then attempt to hand-off the specifications for this solution to production. Predictably, production lacks the necessary contextual knowledge to deliver the solution without regular recourse to the salesperson (who, presumably, should be back in the field selling).

The solution is to eliminate the hand-off by introducing a third party: a project leader. The project leader partners initially with the salesperson — his responsibility is to take the brief and design the solution (selling it is the salesperson’s job). The project leader then chaperones the job through production — providing the delivery team with ready access to the critical contextual knowledge.

Example B: eliminate the requirement to transfer complex information

I’ve often observed our consultants attempting (unsuccessfully) to communicate complex briefs to our technology team. What tends to happen is that the complexity obscures the information that is really critical to the developers (the desired outcome). What’s more, the (method-based) brief often overlooks a superior approach to solving the problem.

The solution here is to eliminate any reference to method from the briefs and simply specify the set of conditions that need to be met for the solution to be acceptable (e.g. produce this report with this dataset, with a sub-one-second refresh time).

Tags: application