Introspecting Communication – Steps in building highly effective development teams.

We all want our teams at work to be effective. We want them to provide value to the company, we want them to feel successful, we want our teams to be happy and productive. That is my core assumption at least. I firmly believe that providing a shared vision and searching for a way to include each member in that vision through relationship building is key to producing a team that can respond and act under pressure. When a team feels purposeful about their work and knows you support them they will be highly motivated. As a technical lead your job is to provide guidance, support and motivation to your team members. You guide them in technical decisions, you support them in their empowerment and you provide the motivation and vision that grounds the team inside the company’s overall mission.

One of the ways that you can support your team is to evaluate how the team communicates internally and externally. Internal efficiency will improve how well the team works together and external efficiency will improve the amount of time the team has internally to produce work. If where you work at constantly jokes about how many meetings everyone has to attend, you probably have a communication quality and quantity problem.

Have you ever asked yourself if you’re communicating in the most effective manner possible for your situation? Are there areas you could improve on? Cultivating introspection is important for building a successful team. It is important to ask yourself why you do what you do and how could you make it better often. I highly suggest doing a communication review, just like a design review of your team.

A communication review involves evaluating your team’s communication design in an almost algorithmic analysis method. Chart out who you communicate with and how. Then move through and talk about who is involved with each part. Profile your process to determine how much time you spend tracking information, communicating information, preparing for meetings etc.

Here are some suggested steps for improving your team’s communication to empower your team to do more faster.

• Communicate less (volume)
• Communicate more effectively (quality)
• Communicate asynchronously when possible (efficiency)

Communicating less

This step requires a serious self evaluation of what scheduled interruptions exist in the lives of the developers on your team. How often are there regular events that preclude people getting into the zone and focusing on solving the challenges in front of them? Try to reduce who comes to what meetings. This will free up people to continue working free of distraction. If people have tasks that are unrelated then they probably don’t need to be involved. If you have a meeting scheduled for an hour it will probably take a full hour. Take one meeting and try to cut it in half. This will push the focus of the meeting to the actionable results of why you’re meeting in the first place. Go into a meeting with a list of questions and objectives for the meeting.

Communicating more effectively

Take a few minutes to chart out how and who you communicate with. Do you know why you communicate with them? Try to reduce why you communicate with a given person or entity (group) down to a single sentence.

Once you have why you communicate try to confirm those reasons with those parties. If you are sharing progress with stakeholders, ask them what they really want to know about. You may find that you are over preparing and over communicating. You may find that you are not giving them the information they need for them to complete their tasks appropriately and you may be able to help them do their job more effectively.

Asking people what their concerns are can bring up key things you can optimize in your process. You may find you’re preparing information that is non-essential. Evaluate your data flow and assign it some motivation. This isn’t always easy and people may not even know what they want but do your best. If you’re communicating for communication’s sake you are not providing real value.

Communicate asynchronously when possible

When dieting an effective technique for some people is to track their calories. Put your meetings on a diet. Start a meeting tracker. Take a normal period of time (say, a 2 week sprint) and actually track how much time you spend preparing for and participating in meetings. This should highlight possible areas in your workflow to introduce asynchronous communication. Perhaps you can replace a face to face with a simple email. Sometimes a group meeting can be reduced to a single face to face with one person bringing aggregate information to the discussion.

Take a hard look at your communication strategies on the team, are you using some form of chat? Text messages? Do you have meetings to discuss architecture? Do you start planning with everyone coming in with ideas beforehand on what they want to accomplish?

Try a few ideas out; plan for a sprint asynchronously, throw up a google doc detailing three high level goals for the team for the next sprint and then see what people come up with. At the very least planning itself should go quicker because people will have had a chance to think before you sit and discuss. Have a new design or architecture you want to propose? Write it out, send it around, solicit comments and feedback before you pull people into a room to ‘talk’.

The unsung value of asynchronous communication is that it provides documentation and context when you are ready to have live synchronous communication. A spec document informs the meeting and provides a place to take notes. A series of update emails from individuals also provides a written record of what everyone was doing that others can digest in their own time (also makes doing a review/report really easy to capture everything that actually happened).

At the end of the day our role as coders is to provide value to the customer through engineering solutions. We should communicate with that as our core motivation. I talk with, share, plan, go to meetings all the time because those are in service of the team pushing out code that is the bedrock for our applications that provide value to our customers. Communication is essential but it is easy to be caught in the trap of doing a lot of talking and little walking. Talking has its place but it should be in the service of finding the solutions to the problems that are facing our customers.