A Guide to Better Conversations with Developers

As an intern at Viget this summer, one of my required tasks was working with a team of other interns from other disciplines to complete a digital product. The experience was fantastic and I am very proud of the end result (check it out here). Surprisingly, however, the largest learning curve wasn’t developing in a new language or using unfamiliar libraries and frameworks or even programming within a new set of standards. It was team communication.

Working with a group of other interns, fresh to the concept of working on a single project and with completely varying educational backgrounds, exacerbated typical professional communication difficulties. Although most of these difficulties were overcome throughout the project, one type of communication breakdown I observed on this project I have seen mirrored in other interactions throughout my time in school, in other internships, and in ongoing professional projects at Viget and other workplaces.

A benefit to good team communication is having multiple sharp minds behind solving problems and making decisions. The communication breakdown I witnessed on the internship project team created an unnecessary single-point-of-failure in otherwise good team decision making. I want to share my observations and lessons learned.

The scenario I observed was when a non-developer (a UX designer, project manager, or creative designer) wanted a new feature added to a project and asked a developer if it could be done. There is a generally a good amount of dialog that results, but the developers response will ultimately boil down to a yes, no, or kind of and a timeline for how long it would take to perform that request.

The problem arises when the developer’s ultimate answer is no, he or she cannot do it. The non-developer blinks, says ok, and scraps the idea.

This is the communication breakdown.

Days or weeks of work put into coming up with a feature or a design can be trashed in a second based on a single developer’s opinion. The developer’s power is unchecked, and creates an imbalance when the team needs to make project decisions.

All developers are human. Developers can feel lazy, they can misunderstand what others are trying to say, and they can miss small changes that can turn a difficult feature into a trivial one.

Both developers and non-developers can change their approach to these conversations to avoid this type of communication breakdown and improve the quality of their decisions.

The Situation

To determine a better communication strategy, it is important to consider the situation. What are each person’s goals in the conversation and what does each person bring to the conversation? In the instance described above, the non-developer is seeking information and feedback from the developer.

The non-developer is, in essence, a solicitor whose end goal is to confirm that a feature is practical and, if it is not, determine what can be changed to make it practical. The non-developer is limited in their technical knowledge, will know some general programming concepts, but will not understand many of the domain-specific terminology that the developer uses on a daily basis.  

The developer is the domain expert. The developer’s end goal is to ensure that the non-developer leaves the conversation with an understanding of whether the feature under discussion is practical, and if not, why not, so that they are capable of properly amending it. Where the non-developer has a limited understanding of programming and related terminology, the developer is flush with it. The developer communicates with domain specific terminology every day and is more familiar referencing these terms than distilling them down into simpler definitions.

Advice for the Developer

If you don’t understand (or if the question is not specific enough) ask for clarification. Making sure you understand the question is the first step in developing a good answer. Trying to answer a question that is too broad, although it may be the question the non-developer asked and will give you a chance to show off your programming knowledge, is a sure way to bore or confuse your listener. This is even more the case when answering the wrong question.

Provide a rough answer to the non-developer’s question before offering an explanation. Giving a yes, no, or kind-of will help scope your explanation. Instead of spending time trying to translate your explanation into a simple yes or no, the non-developer can focus on understanding it.

Define an appropriate context for your explanation. Creating context around the rest of your explanation will help ground the non-developer and keep you focused on answering the specific question that has been asked.

Go into appropriate depth. The depth of your explanation is a balance between being too informative and not informative enough. Going too shallow will leave your listener feeling confused. But, going too deep into the details can overwhelm them and do the same. A good explanation will leave the non-developer with an effective understanding of the relevant topic.

Use understandable language. It’s easy to default to the domain specific language that developers are used to communicating in everyday, but non-developers won’t understand these terms. Make a point of using simple, non-programming terms. If you do have to use a programming term, make sure you explain it well.

Relate programming concepts to everyday experiences. Understanding the logical world of programming can be difficult for newbies to the arena. To get confusing concepts across, draw connections to non-technical experiences or concepts. For example, object-oriented programming is best explained with reference to real world objects. The great scientist Richard Feynman had a theory that the true test of understanding a concept is being able to explain it in simple terms. If Feynman could explain complicated quantum mechanics theory in a single lecture to college freshmen, you can explain a software engineering concept.

Be aware of your listener. In a world with perfect communication, your listener would be constantly engaged and understand everything you say. Unfortunately, that’s not reality. And they may be too nervous to ask questions. Pay attention to their body language. If the non-developer seems disengaged or confused, try to use less technical language and ask them if they understand.

Be patient. Don’t be shocked if non-developers don’t understand some simple programming concepts; the topics are likely unfamiliar to them. Instead, be patient, focus on explaining well and confirming the non-developer understands.

Advice for the Non-Developer

Be explicit, describe your question or problem in detail. A developer’s answer and explanation are only as relevant as the question that is asked of them. In describing a feature, be careful to note when an action would be taking place, how this action would trigger a reaction, and what the result would be. Are there any conditions on the feature? For example, can only some users take this action or can everyone? Use the same descriptive detail when describing a problem as well.

Search for more than a simple yes or no. Important decisions may be reliant on a developer’s answer to a question, but a yes or no answer with no conversation doesn’t do these decisions justice. Strive to understand the reason why the answer is a yes or no, let yourself have the chance to problem-solve. This will also help you improve your own general knowledge. The next time a decision about a feature is about to be made, you will be more aware of how the feature may affect the development buildout or timeline.

Listen. You are asking the developer a question, therefore it is your job to listen. Listening well is difficult, especially when an explanation or answer to your question relies on diving into some of the more technical details of a project. Respect the time and effort the developer is putting into the conversation by putting as much time and effort into listening closely.  

Ask questions. If the developer isn’t going into enough detail, ask them to go deeper. Similarly, if a developer is going TOO deep into an explanation, use a question to re-scope their explanation and bring the conversation back to a relevant level. A developer, like anyone else, will need real-time feedback during a conversation to ensure they are hitting the right level of detail for their audience.

If you don’t understand something, say so. In a series of ongoing conversations, a developer will try to build on elements from previous conversations. Misrepresenting your understanding will cause confusion down the road.  Ask for clarification from the developer, and take responsibility for your professional development as you learn new concepts.

Conclusion

A lot of good communication habits and skills are often overlooked in conversations between developers and non-developers. There are a lot of modern biases that play into how non-developers view and communicate with developers and, likewise, there are biases and opinions the other way. These biases may have come about for valid reasons, but they shouldn’t be a blocker for good communication.

These recommendations sound like straightforward and simple communication principles. In essence, they are. Communication between a non-developer and a developer at the end of the day is communication between a person and another person. The communication concepts that apply in this situation are universal and important in many other situations as well. But that doesn’t diminish their importance.

Improving communication is not easy and it will take time to become proficient at and accustomed to following these recommendations. In the end, the payoff in better team decision making and better team relations will be well worth the effort.