In interacting with a software team recently, I realized that communication is often not the strongest suit that developers play. Here are some patterns that I observed that I find harmful to effective software delivery:
1) Communicate via status – When developers are using tools to manage tasks, defects, or other work packages, they often fall into the trap of simply updating the status of the work item as a means of communicating that something out of their area needs to happen. The primary problem is that while status may identify what needs to happen, it doesn’t communicate the following: Who is responsible for it, and when it needs to happen. It also does not provide that person any guidance as to what has gone before. If you need something from a team mate, (especially co-located) get up out of your chair and go talk to them. Failing that, send them an e-mail with the pertinent information, so that they can express the appropriate urgency and responsiveness.
2) Communicate via tool – When developers are using tools to manage tasks, defects and other work packages, they sometimes simply add commentary to the on-line document or notes to the work item, as a means of communicating that something out of their work area needs to happen. Any time you need another human to respond with some urgency or priority – direct communication is key. Appropriate communication includes what is needful, and when that need must be met in order to meet the current challenge. In this case, you must identify who you are asking to do the work.
3) Communicate via assignment – When developers are using tools to manage tasks, defects and other work packages, they sometimes simply re-assign an item to another team member as a means of communicating that something out of their work area needs to happen. I have watched as incident management tools (typically used by help desks in ITSM) where groups punt incident tickets between groups by simply re-assigning it. I have seen the same game played within a team. The assignee needs to know why they are being assigned, what is expected, when the expectation must be met. Most of the time, this behavior is simply a work avoidance technique. So to prevent this, policies must follow that prevent punting. One example of this is a policy stating that the initial assignee must report back to the reporter – they have to stay in the loop. Even if the initial assignee is incorrect, they have responsibility to see that the ticket is resolved. It cannot be punted – it must come back to them.
4) Communication without summarizing – when developers communicate via e-mail, after a few “volleys”, it helps to re-summarize the original problem. In fact, what starts out as a simple one line question, can end up as a paragraph or two after several trips around or back and forth. Communication becomes inefficient if each recipient has to read back through the entire e-mail chain to figure out what is going on. This often causes miscommunication, as people start at the end, or in the middle, not reading back to the origin before responding. – My recommendation, when responding with a resolution to the original request, copy the original request forward – or simply restate the thread as a summary after your resolution. It makes for much easier reading.
—
If I were to say what I think about the root cause of these communication patterns, I would say laziness above all. People simply want to quickly pass work and responsibility to others who need to do work. Then after that, I would say organizational policy. A policy that holds everyone who is involved in a work item responsible for its ultimate timely conclusion would create incentive for people to be more intentional about their communication. Leaving them on the hook makes sure that they share in the blame for balls dropped by others that they passed the buck to.
I think that something else is at work. A priority of me over us. I think that this is largely to blame. I care about getting my work done. That is what I get graded on. That is my paycheck, my bonus. This is an organizational culture challenge. How do we create a culture about us. Moreover, how do we perceive our customer. We must perceive our customers needs/desires as important to act with appropriate urgency. If taking care of our customer is seen as a distraction from or an interruption in “the important work”, we probably have got it upside down.
Our communication patterns around our work, reflect our own values, and the values evident in the organizational culture around us. They are a tell tale that Leadership can read and decide if the values and culture are what is needed or desired. Then the hard work begins. Of course if leadership is not paying attention, the culture will become a reflection of our lack of intentionality.
No Comments