Archive by Author

On the importance of keeping the team on the same wavelength

1 Feb

For any team to work effectively, each member needs to mentally tune in to the same channel. Then each member can understand the others with minimum interaction. When such a level of integration is achieved, the team functions as a single organism. Everyone thinks along the same lines but in various directions, which covers a lot of ground. They come together to share same conclusions, ask same questions, and disregard same rabbit holes. Precious time is not wasted re-explaining what is already common knowledge. Nuances have already been debated, needs and limitations discussed, workarounds and Band-Aids known. A team covers more areas than the sum of all individuals working separately because team members remind each other about forgotten issues and concerns, considering them while discussing possible solutions. This flywheel effect is what makes a team faster and more effective than a group of individuals on their own. Most of us have experienced the pleasure of working in such an environment. The question this blog considers is not how to get there, but why exactly is it so important to be constantly aware of the current level of integration?


Consider this example. Two programmers discuss an algorithm generating the numbers 2, 4, 8, 16, etc.  They both understand what is going on. For both to answer to “what’s the next number will be?” is simple: it’s 32. There is no need to explain how they got 32. When a third person joins, they tell him to implement the algorithm, which should return the number 64 when a user calls the function a sixth time. To say that the developer is confused would be an understatement. If he’s lucky, he quickly recognizes that out of a dozen possible solutions, it could be the power function. Or maybe he just hard-codes the function to return zeros every time, with a 64 on the sixth attempt. Both solutions would satisfy the requirement of “returning a 64 on the sixth call.” If the developer gets it right the first time, no problem—but what if he doesn’t?  If the job gets done the wrong way, the team will spend a whole lot of time coding, testing, clarifying requirements, re-coding, and testing again.

Tasks that we do in everyday life are not usually that simple, but often requirements are conveyed as just one line of text in an email. And most of the time, it is expected that the developer will “just get it.”

Analysis of example

What can we learn from the above example? Two developers who originally discussed the pattern are on the same wavelength. When they get 32, they both KNOW the other person knows why it is 32.

When a third person joins without previous involvement in the discussion, and they ask him to implement the function that should return the number 64 on the sixth call, he may not be sure why. However, to save face the third developer might act as if it is clear, nodding and saying “I got it.” But there is no certainty that the third developer really did get it, at least not to the same degree as the first two. But given the usual time pressures, doubt is replaced with hope: maybe he really got it. How could he not? But the doubt remains nevertheless.

If our level of doubt is high, we should ask the person to repeat what he understood. It is easier to feel the level of doubt when we talk face to face. We can see facial expressions, hear voices, and pay attention to our sixth sense telling us if something is wrong. And we can keep on asking until we know he’s got it. This is harder to sense over the phone, and harder still over email, a ticket, or instant messaging.

How channel affects productivity

The “channel” you’re tuned into affects team productivity the same way I/O operations affect application productivity. If the context for the task is scattered around various media sources such as hard drives, CDs, and RAM, it takes time to find, load, filter, and sort the data. But when that data is all located already in RAM, the same process takes a fraction of the time. Teams also need to “load” context into their brains to get onto the same channel. When a new team member is not on the same channel, it takes time to tune him in. Every conversation has to allow time to explain context, reasons, constraints, and assumptions. This slows down the team and affects productivity.

It is in the interest of the whole team to recognize the signs that another team member is not tuned into the same channel, whether that is because the person or the project is new, team members were recently pulled from another team, the workload is splintered, or the project has been sitting on the shelf for a while and was recently resurrected.

Regardless, an unsynchronized team’s performance can be expected to suffer until the team gets to the adequate level of channel synchronization.

What factors affect the channel?

Let’s return to our original two team members. They both know the algorithm. They both know how it should work. What if they exchanged their messages over Skype? The first one asks, “How about 32? “, and the second replies, “I got it.” At that point, they could be half a world apart from each other, and it would not matter. Once people tune into the same channel, distance does not affect it.

The level of communication affects the channel. If we meet face-to-face once a month for 15 minutes, we won’t achieve the same level of synchronization that we would if we were half a world apart but talked to each other over Skype and shared screens all day long.

Listening skills also affect the ability to tune into the same channels. Both actors need to recognize if a gap in communication is occurring and proactively try to tune into the same channel. The speaker needs to recognize that he is not being heard, and the listener needs to realize that he is not comprehending what he is hearing.

Different points of view also affect channel. Democrats and Republicans speak the same language, but a clear gap in understanding exists between them. Even if they agree on some issues, they don’t agree on implementation or priorities. A team must agree on priorities, and the way implementation is going to happen, before effective channel sharing can occur. At the very least, a team must agree to disagree in certain areas and return to those areas later, or have an arbiter pick the solution. While part of the team may not agree with the solution, it will still be understood by all so that they can effectively move forward.

How to detect problems

We should trust our gut when we feel doubt about whether all team members have a common understanding. Our sixth sense will pick up voice intonation and body language conveying doubt even if we can’t consciously put our finger on it.

It is different when we use email or messaging. If we feel the conversation is not going in the right direction, it’s usually because not all team members are on the same channel.

Many issues can be uncovered before they become problematic if we just receive confirmation and reassurance about how well the point got across, and whether everyone on the team got on the same channel.

It should not be assumed that someone receiving spelled-out and assigned requirements is just going to code exactly as the creator of the ticket envisioned. Often a whole chain of people is involved: the end user reports a problem, tech support creates the ticket, management prioritizes it, the business analyst analyzes it, the developer codes, the tester tests, and the user does the UAT. Many things can fall through the cracks in this process. It’s safe to assume that the developer will NOT be on the same channel as his colleagues before he starts coding, and that the tester will not be on the same channel before he starts testing.

How to resynchronize

It is beyond this blog post to cover various techniques of getting people onto the same channel. Generally speaking, when a synchronization gap is identified, the level of communication should be escalated—from chat or email to voice, from voice to face-to-face or screen sharing. The depth of documentation should be adjusted if it is not adequate, and meetings with a wider audience should be considered.

Overall conclusion

It is a joy to work on a team where everyone understands and shares the same vision. Performance is amazing, and the results often meet and even exceed expectations. This translates into exceptional product quality and overall client satisfaction. To get to this level, it is important to recognize when we are not there so we can do something about it.