How to establish a solid communication flow within your team as a lead.
Establishing A Bi-directional Flow
To support your team members to the best of your ability and make the best decisions you can, it’s important to know what they are doing, how they are doing it, and how it is going on.
I believe building a strong communication flow is one of the important focus as a lead. It becomes even more important in a distributed environment, because it’s easy for someone to face an issue, and tell no one about it for days (more common for younger devs who want to solve everything on their own), that’s a situation you don’t want to happen.
You will know you have established a strong communication flow in your team once you have all the information you need (you don’t want to be spammed either) coming to you on time. That’s why I like to emphasize it is a “bi-directional” flow, meaning that it won’t be only you asking questions to your team, they will tell you what’s important for you to know as things happen.
How To Build A Strong Flow
That is one habit that takes time and effort to establish. If you’re lucky, you might have strong communicators in your team. If not, there’s work to do.
As always, communication is key, you need to tell your team what information you expect from them, how you wanna receive the information, how often, etc…
When you start to build the communication flow in your team, you should take advantage of the feedback section in your 1:1 to reinforce when you received good information, if you should have learned about something earlier, if they should have told you on their own if there’s something you found out by yourself.
To help with keeping track of the work going on and deciding if I should have heard about something recently (eg - based on the initial ETA for task completion given by the team member, the task might be done soon but haven’t heard about it lately), I refer to product management tools (e.g. Favro, Asana) where all the work should be listed.
Red Flags
The first time I introduce this concept to them, I tell them about “red flags”. If they notice a red flag, ideally they should let me know about it if they’re starting to spend a long time resolving it.
What is a red flag? It comes down to what matters to you as a leader, a way to build them is to notice situations where you felt annoyed about knowing something too late, extract lessons from those, and turn them into recipes for red flags.
Here are some of the red flags I communicate to my team:
- Noticing a problem with the chosen implementation for a feature
- Noticing a delay compared to the initial ETA for task completion
- Getting stuck on figuring out an implementation