I do enjoy building things with code. When I started 28 years ago, that’s what I thought was the essence of what a “computer person’s” (e.g. software developer) job was to sit dark in a room and grind out computer code. Of course we know that it just isn’t true.

For me technical acumen is a decent mark of a good developer. But if you can marry technical ability with communication skills, you’re a huge asset to any company.

The Problem

No matter what kind of development you do, you have to interact with what I’ll call stakeholders. Stakeholders can be direct users, managers, companies or anyone who will benefit from your software. This interaction is where the magic happens in software projects. If you can’t communicate with the stakeholders, the project is doomed to failure.

We think of our job as simply gathering requirements (in a variety of forms), building code and putting it in front of stakeholders for feedback. But as developers we think that the second part of that process is the most important. That is where we spend our time when we’re learning new skills. But the soft skills are at least as important in most jobs.

Active Listening

While not all developers have quite the love to public speaking I do, most developers are very good inter-personally. It is this inter-personal communication that is crucial to being a good developer. One of the first skills I suggest that everyone learn (especially developers) is the skill of active listening.

This skill is simply the ability to listen and comprehend what you’re hearing from other people. In gathering requirements and incorporating feedback, this ends up being super important. The reality is that when you’re talking to people, those people are trying to tell you information the best that they can. It is this transfer of knowledge that is rife for misunderstandings. Since the transfer of this knowledge can’t be a loss-less transfer, your job as a developer is to improve the quality by actively listening to what is being said.

The skill works like this (as far as I remember):

1. Ask a question.
2. Listen to the answer.
3. Repeat the answer to the person to confirm that what they said is what you heard.

Of course this third part of the process is the crucial bit. If you take this simply process and incorporate it into your development life, the quality of the software you build will be higher because you will be more likely to be building what people really need. I can attest that incorporating this skill in your personal life can improve your relationships too.

Validating Requirements

Even if you engage in active listening, confusions can still arise. As developers we often get too wrapped up in the idea that this is really ‘change management’ to limit the amount of changes that we need to do. This is unfortunate. The reality is that we’re building systems to solve concrete problems (or at least entertain). If we don’t build what is needed, we’re wasting our time and usually someone else’s money.

The frustrating problem is that as developers, we don’t speak the same language as many of our stakeholders. Many stakeholders are trying to explain the non-technical solution that they’ve been using for years and sometimes we think all we need to do is digitize the analog solution. I’ve found that the analog solution rarely makes a good digital solution. The real trick is to get both the stakeholders and the developers to look at the big picture of the problem.

Face-to-Face

In communicating with stakeholders or team members, I found that many points of conflict occur electronically. This isn’t news certainly, but since tone and humor are often lost in email or instant messenger, I find it crucial to do as much as the communication face-to-face as possible. This doesn’t mean in person, but seeing a person’s face and hearing their voice can make a huge difference in the amount of understanding you’re going to have. If you have a choice, walk down the hall or open up Skype. It is worth your time.

Iterate

Hopefully this last point won’t be lost on any developers out there. When you’re building software, you should be getting in front of stakeholders really often. When I build a solution, I prefer to use continuous integration so that a live version of the software is available at all times. This is easiest in the website project, but should exist in any case. There are lots of great reasons to use continuous integration, but in this particular case I’m talking about letting stakeholders touch and use the software as you’re building it. Doing releases every sprint is fine, but the more feedback you get the better the final solution will be. It has the side effect of also getting the stakeholders to have ‘buy-in’ to the solution. They become a key piece as you have to expect that they are looking at the progress of the solution as much as they expect you’re building the solution. If you are working with developers that want to hide their progress, they are most likely going to have trouble during the problem. Period. Unequivocally.

What do you think?