In the face of global completion, businesses are embracing teamwork and collaboration with the goal of achieving greater collective performance than what can be obtained by focusing on individual performance alone. This begs the question:
What does great team communication and collaboration look like?
As a software development manager in an organization that has embraced self-directed, empowered teams, I have found that many people do not understand how team communication and collaboration differ from individual performance. In fact, people have blind spots that can impact team productivity. I’ll walk through some real-world examples to illustrate my points.
Watch the hand-offs
One area to keep your eye on as a manager is when work is being transitioned from one individual to another. As a software manager, I prefer to have the developer who will be performing the work be the person who estimates the work. I also resist taking people off of tasks that they have started because I believe that too much productivity is lost due to the ramp-up time required for people to get their heads into the task. But on occasion, work does need to move from one person to another.
I was at a team meeting where one developer indicated that he needed to hand off a priority issue to someone else, mostly because the other developer had some specific knowledge and skills that were required to resolve the problem. The developer who handed the work off immediately indicated that he was “looking for other work to do,” but did not take on any task that was on the board. (And should have, as this is supposed to be the norm with our process.)
The developer that he handed the problem off to spoke next, and she said: “I’m taking this problem on, I’ll need about a day to get up to speed on the issue, but once I do I should be able to resolve it fairly quickly.”
I’m supposed to be quiet at these meetings, but upon hearing that – with no response from the original developer who just said that he was looking for work – I couldn’t help but speak. “It sounds like,” I said, “that if Charlie sits with Brenda for a couple of hours, we should be able to cut down on the time Brenda will spend getting up to speed, helping to move this priority issue along.”
They agreed! It was simply a case of Charlie (real names have been changed) not considering that he could help Brenda along; he had reasoned that he had done all that he could and needed to give the problem to someone else, and basically washed his hands of it without even considering that he could – and should – help move things along through a little collaboration on his part.
A little coaching was required to point out that keeping the team moving is important, and that a hand-off is fine for simple tasks, but a transition is necessary for complex tasks.
Most of us are not working on quiz shows
Ever felt like someone is forcing you to ask question after question? There are some people who have had long experience with a command-and-control environment where they actually expect that it is someone else’s job to quiz the information out of them.
I had this experience with a project team was working over a weekend to meet a critical customer delivery. We were correcting a problem with a custom tool that extracted data from a database and processed that data – our problem was that we were retrieving some data that we should have been excluding. The development team worked through Friday making changes so that we could hit the ground running on Saturday with our testing.
About mid-morning on Saturday, I hadn’t heard how test results were coming along. Since almost everyone was working remotely, I sent a short e-mail message to the lead tester, asking: “How is the testing looking?”
The response came back: “Fine, it’s running a little slow, though.” Knowing that we had changed our selection criteria, I expected to take a small hit in performance. Of course, the limited information contained in the response led me to ask the person to qualify what he meant by “a little slow,” as well as where he was observing the problem.
To give you some additional background, the evening before this same individual tested our older version of the software on the same database and was able to process the information in twenty minutes. What was he seeing now?
He reported back to me that his test with our “fixed” software had already executed for two hours, and he estimated that it would be another two hours to completion! Obviously something was very wrong…
From a communication perspective, it would have been extraordinarily helpful if this person had taken the initiative to raise the performance flag after we passed the forty-minute mark without being asked (let alone what we were actually experiencing); if our software was taking twice as long to process without being complete, everyone would have known we had a major problem. If I hadn’t asked, I’m sure that I would have heard anything until mid-day – after the processing was complete – that we had a problem.
Barring that, this person knew that there was a problem when he gave me his initial response, and he could have provided essential details in his response. If I didn’t ask for specifics about what he was observing, the net result would have been the same as my not asking my first question. We would have found out half-way through the day that things were very wrong, after his test was complete.
In this particular case, the individual was used to teams that worked under very tight control, and he needed to understand that in the self-directed world that he was now a part of, you need to think about what information is important for others to know, and to communicate that information fully. For him, it was a matter of pointing this out and setting expectations going forward.
One related point: The act of responding in greater detail may trigger a proactive response on your part. As you supply information, you start thinking more deeply about the situation and even ask yourself key questions that will help keep things moving forward.
What was causing our performance problem? We had a server configuration issue. The decrease in performance was actually due to “processing” time being consumed by very detailed logging reserved for debugging scenarios.
I’m sure that if the tester had put more effort into responding in greater detail, it might have occurred to him to check the next logical option – the configuration file settings. Once we asked him to check for and make a simple configuration change, everything to be processed normally, within the expected time frames.
The team needs to win
There are times people optimize their individual performance without consideration for the team. Are your annual performance plans a cause of this?
If “collaboration” and “teamwork” are line items in contrast to specific, more detailed, individual goals and objectives, the individual will naturally optimize their work towards what carries importance on their performance evaluation. Other times it is simply a matter of work style and personal preferences that are getting in the way.
One example where a personal preference almost caused lost productivity involved a couple of my developers that were collaborating on a rather time-consuming, difficult problem. I was a part of a meeting one morning where we discussed how to attack the problem. Given the nature of the issue, we had a good idea of what code was involved, and we worked out what tests needed to be conducted in order to isolate the nature of the problem.
It was agreed that one of the developers would conduct tests and report the results so that the other, more experienced developer could then fix the code. Even though we had a good idea of where to fix the problem, the results of the testing would help us understand the exactly what needed to be changed. And while this was issue was a high-priority task, the experienced developer had other things that he needed to do, so it was agreed that he could work on his other tasks until the test results were in.
Around 2:00 pm that same day, the developer conducting the tests had his results. He was pleased that the tests confirmed what we had suspected, and told me “I’m going to write this up from my notes and get it to Bill.”
I recognized that this developer was very meticulous, and his own personal style was one of carefully documenting each step along the way – which was very useful if he needed to refer back to something because he always had a good record of what he worked on. However, there was someone else waiting on this information, and his personal style was going to prevent that person from learning about the tests for at least an additional hour or two – suboptimal from a team perspective.
I quickly interjected my thoughts; “Since Bill is waiting on these results, let’s get with him now so that you can give him a rundown on what you found. That way, he can start making changes before close of business today, and you can follow up with your written results once you have those complete. We can use those results to double-check the changes to ensure that we don’t miss anything.” The developer agreed that this was reasonable, and the issue was resolved within that same day.
Good team communication is all about what considering what it takes to keep the team moving. If teams are having problems performing, examine the areas where communication and collaboration are occurring to evaluate whether individuals are focused on the team or themselves, and if they are sharing complete information. It's all about flow.
And don’t fault people, but coach them about the differences of team communication and collaboration, and set the expectation that individual performance may take a back seat to team performance.