In this article, I want to share the techniques that I’ve learned on my journey as a project manager. They help me build small and large teams, in projects of different complexity, with manageable and predictable results. I’ve seen the effectiveness of these methods from my personal experience, because the problems in building communication arise on projects both with beginners and specialists of quite high level.
The problems
Whatever company I work for, process design is always the cornerstone which the final result depends on. While much has been written about building processes within teams, there are almost no articles on communication and effective communication rules, much to my surprise.
Thus, we derive the main problem in communication — data loss.
When working in a team, data loss between different participants becomes more critical the larger the team is in terms of the number of people and the number of their roles and specializations.
Communication Channels
What to choose as a channel of communication, messenger, mail, or daily meetings? It depends on the type of tasks discussed, but there are only two rules — the speed of communication and communication in only one channel.
Channels of communication should always be fixed in the rules of the project and available to all. Business communication is best kept in the mail, while work and technical communication in messengers.
When working with legally relevant information, this reduces the search to the channel of communication, when working with technical communication, it gives the possibility to re-address the information and clear rules.
When onboarding a new team member, it reduces immersion, because it gives the ability to quickly access information (current communication, message history, message search).
The rules seem simple, but they are often neglected, even on large projects with multi-vendor development.
Bus
Everyone probably imagines an integration bus, where any source and consumer is connected to a common communication channel. Information is sent to and taken from this communication channel.
The method of organizing communication channels according to the bus principle has proven itself through years of practice. When organizing team communication at the start of a project or at any stage of connection to it, I always impose one general rule — we do not discuss technically significant information in private messages.
At all times, the project team must have access to the information being discussed, which may interest any of its members. This allows us to avoid making mistakes when discussing decisions on which our colleagues depend, and to observe the principle of immersion, where the project manager and the leaders are aware of current problems and decisions being made.
In addition, we all understand that some developers can stop taking part in the project for various reasons (illness, vacation, rotation to another project, etc.), so this approach makes it possible to maintain expertise within the project.
Fixing of meaningful information
If the opportunity and resources at the project allow all decisions discussed in the project by the bus method, it is desirable to fix them in the comments on the tasks under which they were discussed. Chats are good, but after half a year it is impossible to remember for what reasons they used this or that method, pattern or approach. The comments on the tasks allow us to aggregate this information.
It’s also a hundred percent must have a page in the documentation on the project that contains all the important technically relevant information on the project.
Access to environments, links to repositories and documentation, keys to maps or to integrate third-party services — put everything in one place. You will see how quickly developers will exhale, not having to look for it every time in different tasks or in hundreds of pages of documentation.
Likewise, with the rules of the project, a list of common questions about the project, or the composition of the team. If it is possible to gather information in one place to cover someone else’s questions, do it. The workload and effort of you and other team members to pass the same information is more expensive than putting together multiple pages.
Paraphrase
Or let’s repeat the task.
Unless the task comprises a team in 2–3 words that are hard to confuse, it’s better to paraphrase how employees understood a particular task. Before this rule was introduced, I repeatedly had trouble with misunderstandings of the task in my projects.
Paraphrase — tell the story in your own words. Ask them to repeat how your employees understood the task, and this will significantly reduce the number of incorrectly executed tasks. It allows your employees to avoid double work, and you to be sure that the task is understood correctly.
Rules of Address
“We have to close the window.” and “[Name], the open window creates a strong draft. Close it now.”
Do you feel the difference?
In the first case, there is simply information about the problem, but no responsible deadline or call to action. In communicating with my team, I try to use a simple formula:
<Communication> + <introduction information> + <call to action/no call to action>.
Avoid questions hanging in the air or information given into the void. Address people explicitly and say exactly what you want as a result and why. And if you add a desired deadline, your interlocutor is automatically involved in the process and is forced to either confirm the deadline or start discussing it, as well as the problem statement. Not 100%, of course, but there is clearly a better chance.
Well, none of this works without the next point: feedback and a receipt
You said something, but didn’t see a reaction? Did they hear you or not? When will the task be ready? These questions break down into ironclad rules that are best introduced as early as possible on projects.
“Receipt” is such a funny, but so important word.
Receipt is primarily about strict accountability. When you take clothes to the dry cleaner, the only way to confirm the fact that you ever gave anything to anyone is with a receipt. It’s all about the receipt, and it’s the form of feedback without which you can’t manage processes properly.
The absence of such feedback creates a “swamp” effect and is fertile ground for the development of “student syndrome”. It’s a special form of procrastination. If a person postpones a task for later, he is bound to use this opportunity eventually, until it becomes a stable habit.
Make it a rule to give feedback on requests within the team, and you’ll be surprised how transparent the deadlines will become, and the processes will become clear.
After all, if you’ve never asked for feedback, they may never start doing it. Even if they read it.
Well-configured feedback in the team allows you to create a framework within which it is very difficult for the “student syndrome” to develop. And you and the other participants, between whom such rules apply, breathe more freely and understand what happens when tasks are set.
Escalation
Escalation is an increase in the priority of an appeal. Escalation is of two kinds:
— Horizontal
— Vertical
Horizontal escalation is changing the channel of communication to one that has a higher response rate:
Emailed a colleague, but no response after a couple of hours, and the response affects an important task? Use chat.
No response in chat after an hour? Make a phone call or go to another department with your feet.
Vertical escalation changes the person in charge:
Email another team’s developer, but he’s incompetent or procrastinating in responding? Write to his lead.
Team lead doesn’t respond? Use the account’s or technical director’s contacts.
And so on up the chain until the issue is escalated to someone who can influence the situation.
Types of escalation can easily be combined with each other. I think it’s obvious.
But the ability to use escalation skillfully sets up all the participants of the process for prompt delivery of information, because quickly, there will be an understanding that you will get an answer anyway. Is it really necessary to wait for a call “from above”?
By the way, in fact, the “top” will be grateful to you, because it will become clear that you want to solve your tasks quickly and efficiently. Why not help?
Conclusion
Thank you for taking the time to read this article. Some techniques don’t have to be used absolutely all the time. For example, if you use paraphrase always, you may tire of you, but when communicating with a new team member or when setting a critical task, it is better to sync up and make sure that you have not wasted effort and that your colleagues see the task and the solution as you do.
