Situated between your internal and distributed teams, whether they sit across town or across an ocean, is a narrow tunnel that is your voice, the voice of your team, documents, email, instant messages, and video conferencing. Through this tunnel, your task is to lead your teams to work productively, make smart technical decisions, recognize which tasks are more significant than others, work with forethought, take the right opportunities to refactor and improve maintainability, and, of course, meet a deadline.
If you take the time to visit your provider and attend your remote team’s meetings at their location, you will be surprised. Within 5 minutes you will marvel at how minimal the information is coming across that tunnel, and how your remote developers must make do with less than you ever imagined.
The tunnel effect is real, and it exists in nearly all distributed team scenarios. There are many important tools and methods we can discuss to mitigate the tunnel effect. You likely implement some of them: structured team meetings, scheduled overlap time between teams, manager to manager communications, periodic visits. But right now I want to focus on what I believe is the most effective means of dealing with this tunnel, and thereby significantly improve the productivity of your distributed teams.
In an article published by The Telegraph, Daniel Pink reports on research by Adam Grant at the University of Pennsylvania’s Wharton School which concluded that reminding employees about the “why” of what they’re doing doubled their performance. His experiment focused on an American university’s call center where students call alumni to raise scholarship funds. Those students who took the time to consider the significance of their work and its effect on others’ lives raised more than twice as much money, as other students who either had no insight into the impact of their work, or understood the impact in terms of the personal benefits of working at the job. Grant and his colleagues found the same results in another call center study, as well as a study of life guards.
Pink writes: “It’s often difficult to do something well if we don’t know the reasons we’re doing it to begin with. People at work are thirsting for context, yearning to know that their efforts contribute to a larger whole. And a powerful way to provide that context is to spend a little less time monitoring who, what, where, when and how – and little more time considering why.”
How much effort do you make in relaying the “why” to your teams? Do you take the time to provide context for the project before it begins? Do you remind your teams periodically how the project, and specifically their efforts, will impact the company’s business and its customers? If the project will result in a special milestone for the company, do you emphasize that?
There needs to be an explicit effort made by the manager to clearly articulate the “why” of the project before the project begins, and, as Pink suggests, the “why” needs to be kept alive once a week at staff meetings. According to Grant’s study, the effects are dramatic, even if the “why” is introduced in modest ways.
You’re the captain of the ship. It’s about to embark on a voyage. Your crew needs to know what the voyage is about. Getting on-board means understanding the “why” and deciding it’s something worthwhile doing. This is about good leadership.
You know the “why” has taken effect when members of your team show initiative, thoughtful analysis or inquiry, forethought in their activities, and clear reasoning. They’ve understood the context of the project and how their efforts can contribute to the larger whole. Remember to validate these efforts by drawing the connection between their actions and the purpose of the project. Do it publicly in the staff meeting, and, if it’s significant, privately also.
As a development manager, I sat in two or three scrums each week. I made a conscientious effort to detect when team members were forgetting the “why”, which manifested as veering off course. In such cases, I stepped in to clarify the vision. More importantly, I validated when their efforts clearly sprang from understanding the “why”.
We are pulled into various meetings and duties that seem to take precedence over being with our teams. But we must remind ourselves that leadership is our principal task, and it happens more directly when we are present with our teams.
In my experience, conveying the “why”
- helps team members recognize which tasks take precedence
- answers the question, “How much time is this task worth?” because they understand the big picture
- raises the right testing concerns
- solicits smart followup questions to your specs that would not otherwise occur to your team
- promotes independent thinking and initiative, tempered with an understanding that it will take team-work to reach the goal
Pink’s article doesn’t need to make a distinction between internal and distributed teams. But if you’re thinking you need to start with your internal team before you can address the remote, you’re right. If the “why” isn’t happening nearby, how can you expect it to happen remotely.
I believe the “why” is always about people. Whatever the technological advances or business advantages, it needs to translate to its effect on people. In engineering, it’s easy to lose focus, believing the “why” to be about technology rather than people. We know developers love to work with new and innovative technologies. It’s always a treat. But don’t let the excitement of new technology seduce you or your team from the goal. New technology will do its own work in generating energy for your project. Keep the focus on the larger whole, the impact on people.
The “why” is a key element of leadership. Raising it with your team is the most powerful way of widening that narrow tunnel of communication. While the nuts and bolts, the tools and methods, are important, the “why” transcends them because it works directly with the understanding and motivation of your team.
I welcome your comments and experiences.