The vast majority of companies I worked for play the Chinese whispers game. If you’ve never played it as a child, here is the Wikipedia definition:

Chinese whispers or telephone is an internationally popular children’s game in which players form a line, and the first player comes up with a message and whispers it to the ear of the second person in the line. The second player repeats the message to the third player, and so on. When the last player is reached, they announce the message they heard to the entire group. The first person then compares the original message with the final version. Although the objective is to pass around the message without it becoming garbled along the way, part of the enjoyment is that, regardless, this usually ends up happening.

In a company, it might look like this:

Side note, you can substitute “Developer” with any other “doer” (a person who actually does the job, instead of just talking about it), e.g. this could be someone from marketing, operations, research or a business analyst.

The information is distorted at each stage. Let’s have a closer look how:

• Some parts of Client’s feedback are ignored. When the C-executive relays the feedback to the Director, he forgets to mention that the slowness only occurs on Firefox.

• Opinions are mixed with facts. When the Director talks to the Middle Manager, he makes it sound as if his opinion (“the app looks like Windows 95”) came directly from the Client.

• The solution to the problem is suggested upfront. When the Middle Manager talks to the Team Lead, he mentions competitor.io having nicer UI. This is Middle Manager’s opinion, but the Team Lead might conclude that the task is to make the UI look like competitor.io. This is possibly a suboptimal solution, but might not be challenged by anyone down the line.

Because of the company structure, the same information flow is applied in the opposite direction as well:

Chinese whispers communication style leads to two major problems. The first one is obvious, Chinese whispers is a very inefficient way to communicate, and so the company will end up shipping something which does not meet clients’ expectations.

The second problem is more subtle and is related to the Developer persona from the diagram above. The Developer is far away from any clients and far removed from any real decision making. This has a huge impact on her job satisfaction. She might be given nonsensical tasks because of the distortion of information. She might arrive at an incorrect solution and get blamed, only because she lacks crucial knowledge about the problem. Since there are four decision-makers in the chain of command, the priorities might shift at any time, and it might not even be clear to the Developer who shifted them and why. As a result, she might feel no sense of ownership over whatever she is working on, and lose motivation.

People are not the problem here. Of course, people can be malicious, or play politics and have hidden agendas, and so they misinform others on purpose. But even when none of these is the case, there are high chances that the information would get distorted anyway. This is because communication is hard, even face to face. And communication through a chain of intermediaries is simply impossible.

The structure is the problem. Let’s consider an alternative.

The idea is simple - the team which implements a given product becomes responsible for that product. Clients talk to the team directly, not through a chain of intermediaries. For example, a team’s product manager might be responsible for organising meetings with clients. What if one of the developers wants to join a client meeting to discuss the feature he is working on? No problem, he just joins. After the meeting happens, whoever attended updates the whole team about the outcomes during the next team standup. Likewise, stakeholders interact with the team directly, not through a chain of mediators. If two stakeholders have conflicting views on the project, it becomes apparent to the team because the team talks directly to both of them.

Since all the learnings are shared by the whole team, the learning process is accelerated. The information has a much lower chance of being distorted because there are no Chinese whispers. The probability that clients’ and stakeholders’ expectations will be met is much higher. Getting feedback from clients is faster, and more valuable because such feedback is given directly to the people who implemented a given feature. Team members are happy because they feel a real sense of ownership of whatever they are working on. If some boss wants to change priorities, he talks directly to the team. The team can get clarity on the changes, discuss internally, and push back.

Self-organising teams are mentioned often by agile advocates and are a part of the agile principles (https://agilemanifesto.org/principles.html). And yet, very few companies implement this model. So, I would like to conclude with a call to developers (or other “doers”) - push back! Ask for direct access to clients and stakeholders. Refuse sudden shift of priorities before discussing such shifts with the team. Take ownership of whatever you are tasked to do. Be assertive.