Few programming teams that I have met really understand how important communication is to their everyday lives. Let me yell this from the highest places I can find - Communication is the most important factor a software team can possess, above technical abilities, above delivery, above project work, above code itself. Without communication, a programming team can die.
Take two hypothetical programming teams, one is extremely effective and highly knowledgeable and technical. This team can deliver programs on time and on budget at every opportunity, have a repertoire of current programming languages and skills, and can understand and deliver highly complex applications. However, this team has no communication skills.
The second team has only ever used a single 4GL language, have no technical knowledge outside of their areas and couldn’t hit a delivery target if it was painted on the side of a building in big bold bright neon colours. This team however works hard at communication.
Now let’s put this in terms understood in today’s financial restraints – Which team would be open to being outsourced?
The answer would be the first team. Without communication, this team are “perceived” by management and other departments as a cost to the company and full of Prima Donna programmers who don’t offer any service to the company to justify their (perception) huge salaries.
The second group however are perceived by management as a hard working and loyal group of technically brilliant people that the company simply cannot do without.
Development teams must be able to explain what they are doing, why they are doing it, the value they give to the company, and why that value should be maintained. But we are talking about a bunch of programmers here. By pure definition these people communicate with one’s and zero’s not with other living organisms.
I’ll draw on my own experience to give you a real life example of the changes that communication can give to a programming team.
Many years ago, I was appointed as development Manager to a team of programmers. During the interview process, this team had been described to me as unable to achieve any targets. Production was down and the team was not viewed as a valued asset to the company. It was generally accepted that the team would be outsourced within the next 6 months and I would then move into IT Manager’s role (due to be vacated).
The first few days on the job, I observed what was happening. Every 30 minutes or so, a different department manager would come into the development area and talk directly to one of the developers and demand they drop what they were doing and work on their project as it was needed yesterday. The programmer would dutifully drop their current workload and take up the task demanded of him by that manager.
No wonder the programmers had a bad name - they could never finish anything because they were constantly being shifted to working on something else. Every manager thought the programmers had to be forced to work on their material otherwise they’d never get their project out.
The programmers also complained about their workload telling me they needed to at least double the team to keep up with their work.
I looked at the code and the projects these developers worked on and spoke to them about their work. It quickly became apparent that the skill level was extremely high but the moral was at an all time low. I concluded that their only fault was their communication so I set about correcting this and became the mouthpiece of the Development Team.
There were several things I did immediately which had a huge impact. The first was to put into place a job request form. This was originally a simple paper based form allowing users to enter the details of their project on a paper that had a unique job number. This job number was kept by the internal customer to refer to their request.
For the first time, programmers were then able to prioritise their work. They were also able to see what work was ahead of them. By having all their work available on the desk in front of them, they could tell the internal customer that their job would be due to be completed at a particular date.
I also spoke individually to those customers who filled out the form, explaining the work request form giving them confidence that their project was now in the “system” and that the work was now prioritised and a date for delivery was now available. This meant that customers were much less likely to come in and speak directly to the programmer unless their project was late.
Meaning the programmer could concentrate on completing that one task without interruption - new requests could be referred to the job request and any member of the team could take over this discussion. Jobs were actually getting completed.
Now we had the process in place, I concentrated on communication. It was then my job to support the team by educating everyone on this new process and how to use it to their advantage. I wrote up a development process document and created one-on-one meetings with each of the departmental managers throughout the company. There I showed them through the process and effectively “Sold” the process to them. I also added a “Software Development” column to the company fortnightly newsletter and added the Software Development department to the list of those giving a talk to new employees during their induction. This had the added side effect of being seen by other managers who came along to the induction process for their talk.
I then started talking directly to the CEO (Chief Executive Officer). I told him what was happening to the Software Development Department and what applications we built and look after in his organisation.
Within six months, this department went from being a bunch of dead-beats who were due to be outsourced, to being the only IT department that was confirmed too valuable to be outsourced. The CEO started placing Software Development on his rounds when showing visiting VIPs through the company and the main software packages we wrote and supported were being highlighted as great achievements for the company. Eventually the CEO, in his monthly report, stated that all of the company should look towards the Software Development Department as an example of what a well run department should look like.
So for the matter of a few processes and some effective COMMUNICATION, this team went from a dead weight and an unwanted “cost” to the company, to taking pride of place within the corporate environment.
So yes, even programmers need communication. Few programmers have that ability to communicate effectively. That is their nature in that the skills of a really good developer are in understanding code and code flow, and to understanding the user’s requirements and delivering to them, not in the areas of marketing and communication. It is up to those supporting the team - the Development Manager, the Team Leader, or the Project Manager - to take up this task of communication.
