Misunderstandings happen because there's a big drop-off between the sender and the receiver. When you send a message, it goes through a lot of processes and its original meaning gets lost. To make sure there’s no misunderstanding, keep in mind how collaboration and communication actually work.
Let's say a client wants to tell a designer what kind of website they want. A client-first writes the message and right there, during that writing process, the message loses a big chunk of its original meaning. Maybe you can’t communicate context, have a different interpretation of common terms, or maybe you're not so good with words. Even professional writers struggle with concise and clear communication.
The medium (e.g. email or task comment) also takes away some of the messages by limiting what can be said and how. Then, there's the noise around the medium that downgrades the message's quality: reading a long email in a noisy office while there are thousands of other unread emails is different from reading the same message on a piece of paper in your private office.
Then comes the decoding, when a person interprets what you wrote and distorts the original message further. When the designer reads your email, they have to decode the message using their own field of experience. For example, you may ask for a prototype and the designer may understand comp, so he'll spend a lot of time making pixel-perfect PSDs when all you wanted was a fancier wireframe. Good news is, the more you work together, the more your fields of experience overlap and there’s less room for misunderstanding.
At the end, the designer gets a different message than the one client had in their head. So, when you communicate, take into the account:
- how you express something,
- the medium and environment,
- and the other person’s field of experience.
There are four basic communication patterns: circle, chain, Y, and network. The network pattern is the most efficient and the one you can use only if you keep nexus of activity online. In the network pattern, everyone can communicate directly with everyone else, so there's less room for message distortion.
The network pattern saves you from time lags and "monkey on the back" problems.
To have a "monkey on your back" means being responsible for someone else's problem. This happens most often when someone can’t proceed without the manager's approval, so they hand off the problem to the manager, thus giving him the monkey.
For example, a developer might run into you and say:
Hi there! Great to run into you, because you see, we've got a problem with...
You're in a rush, so you say you'll let them know later. You might wonder what's wrong with that.
But let's examine what really happened: before the two of you met, the developer had a monkey on his back, and you were free; once you parted, the monkey was on your back and the developer was free. Basically, you got stuck with the problem, thus neglecting your own.
To make matters worse, people sometimes have no choice but to give away their monkeys to managers due to bureaucratic reasons. The more managers take on their back, the greater the bottleneck they become; this is, until they end up with so many problems that they don't have the time to do their job. While the managers sits on a big pile of tasks, others will complain how they can't make up their mind.
The solution to the monkey problem is to set clear boundaries from the start and never accept the ownership of the monkey. At no time, while helping, will someone’s problem become your problem. It means that if someone asks for a consultation, it's their job to leave with the solution.
It’s like in school: if someone asks you to help them with their math homework, you should help them, but at no point should you touch the pen or do the homework yourself. By taking the pen, you set yourself up for more work down the road and people know they can take advantage of you.
Never have issues on a project: issues are talked about, problems are solved.
