Archive for the ‘Communication’ Category

Effective Developer/Management Communication

by Katherine Cook 4 Comments


I have been thinking a lot lately about communication between developers and management. This seems to have always been a major problem at my current workplace, way before I got here. Heck, it was an issue at my last job too. It seems to be a vicious pattern that permeates the industry. Why is that? Effective communication between these two groups is essential to any progress for the company/organization. It isn’t just one side or the other, either. I have seen both developers and management being the instigators of the communication problems. Both sides need to put forth the necessary effort to ensure that open and effective communication occurs during all stages of a project.

Some Experiences

At a previous job, there was some communication between the developers and the management- but I would not consider it effective. The management, in general, would pretend to listen to the developers, and then never address the issues presented to them. If there was any effort toward achieving these changes, it was usually in writing only. This eventually would just lead to terrible morale for every developer that would join on at the company, that would pervade their attitudes until they left. At a certain point, the developers would lose all motivation to innovate or improve- dismissing it as a pointless gesture with the current system in place. This situation completely kills the ability for the company to really grow and improve. Not only is the management unwilling to make the changes that would allow for improvement, but the developers themselves would never even bother to make the suggestions that would encourage it.

Another developer I worked with had so many problems communicating with management that very few of his objectives ever were seen through to completion. The only way he ever seemed to make any progress with his plans was to work on them, almost in secret, and then implement the changes without any warning. Sometimes such actions would lead to necessary programs being completely inaccessible for days, weeks, or even months. This would, of course, always throw the management for a loop. Then, he would be shocked when they were upset at the drastic changes that he saw as major progress. These changes may have been helpful, even necessary; but, without prior warning, management never saw them as welcomed changes/improvements- which left him feeling unappreciated. In this way, neither side was ever satisfied with the progress of the project.

The Root of the Problem

Without the proper communication from either side, the growth of both projects was greatly hindered. Knowing this, why do both sides not spend more effort toward bridging this gap? Seemingly, there is an “us vs. them” mentality that further creates these communication gaps.

Why would managers appear indifferent to their developers? A manager’s job, in general, is to create some sort of business stability. New ideas mean recreating procedures- which, at least initially, creates instability. Initially, it’s easier to stick with the ways that currently work, however inefficiently. Also, they may have other issues that may appear more important and more deserving of their attention at the time, than changing a currently working system that may or may not end up being improved by a suggestion. Also, there may be some underlying problem with the new idea being implemented that the developer may not have considered or had the knowledge to realize. Managers usually deal more with the “bigger picture” than the developers, and may not think that the developer has the knowledge to be able to properly see the direction of the project. (At least, these are my guesses at their reasons- assuming they aren’t just trying to be unreasonable :-P , never having been a manager myself.)

Why do we, as developers, create these communication problems? Sometimes, from my experience, this seems to stem from frustration with the management and not being able to effectively communicate exactly what we are trying to accomplish. Our explanations tend to be awash with technical terms and implementation details that the management either doesn’t understand or doesn’t care to. And why should they? That’s what we are paid to do for them.

Ways to Improve

Managers, you have a responsibility to your developers. Listen to their ideas. If they are good at and knowledgeable of their job- which, since you hired them, I would hope that they are- then they probably have some useful ideas for your company or project. In general, they have your company’s best interest at heart. They want your company to succeed and grow. So, since you have the same ultimate objectives, try to work with them and facilitate the changes they suggest. Obviously, not all of them will be feasible, but work to implement the ones that are and explain the reason for the ones that are not. Seeing that their suggestions are appreciated, considered, and acted upon will keep your developers satisfied with their involvement in the company. In fact, they will probably try harder to create a superior quality of work and make your company better as a result.

Developers, we have a responsibility to our managers and coworkers. We should explain our ideas in only the terms necessary for their understanding of the issue. Attempting to simplify our ideas with fewer implementation details will enable our management to concentrate on the actual issue on which we need their input and approval. Also, we should try to communicate with the management as often as possible on the progress we are making on any given project. Suddenly changing a system without any warning is definitely a no-no. We should try to make any transitions as smooth as possible, not radical shifts that leave our coworkers and managers without the tools that they need to do their jobs. Pushing our agendas should not come at the expense of our coworkers being unable to complete their jobs effectively. This will eventually result in distrust in your ideas and limits on your ability to even go through proper channels– no matter that your intentions were for the good of the project.