Effective communication for software developers
Technical folk are not exactly renowned for being able to get their thoughts across in a succinct and clear manner. This article summarises a few thoughts I've had as a result of experiences with the, let's say, "varying" communication quality of development team members!
I've split up my thoughts into four main themes - clarity, perspective, accuracy and usefulness.
My objectives are as follows:
- For developers/technical people: learn about common software communications pitfalls and some tips and tricks to overcome these, as well as some thoughts about how the way you communicate can accelerate your career and increase your value to organisations
- For non-technical stakeholders who have to deal with developers: by seeing how communication looks from the developer's "side of the fence" you should get a feel for some problems you are likely to have with technical communication, and find some ways to help guide developers into giving you the information you really need, without having to learn their language
Clarity - this is about ensuring that we truly communicate what is inside our heads to other people, without too many misunderstandings!
- Use the "power of examples". For instance, when talking about "key user journeys" on a website, add some use cases ("registration user journey", "checkout user journey") so that it is clear what kind of thing you mean. If a conversation is going nowhere, throw in an example to try and put things in perspective. For instance, when trying to understand complex client requirements you could add "so you are saying you'd like an ABC which does XYZ?": Regardless of whether the answer is yes or no, both sides can now talk about the situation relative to a hypothetical interpretation of some feature
- It can also be valuable to state examples of things which are *not* in scope, or examples of the opposite of what you mean, as a counterpoint to the previous point
- Add some redundancy to your message; especially in written communication, where there is no opportunity for the recipient to quickly clarify the message. By redundancy, I mean making the same point twice in different ways. The redundant part of the message can be used as a "checksum" to confirm one's understanding is correct, and to reduce the risk of misinterpretation. Although it may seem boring, it can make your message much more valuable! This philosophy is not dissimilar to the double-entry bookkeeping system which accountants use. Using an example (see previous points) is one way you might consider adding redundancy
- Don't be afraid to ask for clarification of a question, and/or for more contextual information; if you make assumptions about what you are being asked then your reply might ultimately not be very useful! Or perhaps if you knew a bit more about *why* the question is being asked, you might be able to better help. In short, don't always feel you have to answer the question "as asked" - don't feel like you are on a quiz show! Try not to be too manipulative either, but be aware of some of some tricks which you can use (or which can be used on you) - politicians are well know for frequently ignoring questions (in up to 35 different ways!)
- Some of the techniques used in Active Listening might help during spoken conversations - in short, make sure that you feed back what you think someone is saying to you in bite-sized chunks as the conversation progresses (the feedback is another form of redundancy/examples) to ensure that you are all on the same page
Perspective - this is about understanding the context of the discussion and background/skillset of each of the its participants - and making sure you're not effectively talking only to yourself ...
- Hear questions of the speaker "through the ears of the speaker". What do they know? What won't you expect them to know? What kind of things are they likely to care about most? A project manager is not likely to care too much about some intricacies of things like unit testing or CPU usage, and this is perfectly reasonable - try and translate your technical issues/thoughts into the kind of information which the project manager needs to know (such as how long something will take, what resource is required, any blockers, what the business benefits are, etc.) Ask questions to determine the knowledge/perspective of the person you are listening to - this also reassures them that you really *are* listening to them and want to help - again, Active Listening style techniques can help here
- Similarly, imagine hearing your replies to the speaker "through the ears of the speaker". Like chess, if you imagine what their likely response is (and are correct!), then you can mentally prepare yourself for the rest of the conversation - stay one step ahead! I've often heard developers communicating with non-technical people using inappropriate technical vocabulary. The ability to explain something complicated and technical using non-technical language geared towards a specific audience will make you a very valuable professional! From the other side of the fence, don't let technical folk bamboozle you with tech-speak, or make you feel incompetent for not knowing what they are on about. We can't all be experts at everything, so it's important to let everyone do what it is they do best
- Never be afraid to state "the obvious" - it's always the unsaid assumptions which come back to bite you later on. From my experience, "the obvious" is usually anything *but* obvious to at least one stakeholder in your conversation!
Accuracy - this is largely about being honest about what you know, what you don't know, and what you can find out with a bit more effort or time
- Don't be afraid to ask for more time to answer a difficult question; don't succumb to the expectation that you know *everything* (these expectations are not realistic!) It's very rare that anyone will mind waiting for a bit of time in order to get a more valuable answer. Anyone can give a quick answer, but being able to give a *good* answer will make you more valuable in time. However, it can also useful to give some more general answers in the short term, and offer to return later with a more specific answer. Someone who, when asked an on-the-spot question, appears to know everything *or* appears to know nothing, is likely to not get very far in their career - so strike a balance!
- When asked about something that you have done, don't be afraid say that you don't remember, if you don't honestly remember. I find it hard to remember things I worked on a few days a ago. This is part of the reason I started blogging! This is similar the the previous point - if I'm not very sure about something relating to some previous work I've done, I usually give my best guess along with an offer to look up some more solid information
- Sometimes, the best answer is still "I don't know" - if it's a very specific question with a simple outcome (e.g. a yes/no question), and you genuinely don't know, it can sometimes be more beneficial to state that you have no idea (rather than making "educated guesses"!)
Usefulness - this is about how to ensure communication actually moves situations forward, rather than precipitating a "stalemate"
- Ultimately, try to aim towards providing answers rather than more questions. If you're being asked to provide technical expertise and recommendation, it can be frustrating to others if it seems that you are not committing to an outcome or suggestion (even if you feel that it is reasonable to be non-committal, due to information you need being missing or incomplete). Sometimes it can help to move things forward if you can come up with an answer/solution which is subject to a list of caveats (which usually represent you making some assumptions about the incomplete information)
- If there are several possible answers to a question, you can help avoid a stalemate by suggesting the best solution based on your knowledge of the situation: I think this is a perfectly professional approach *as long as* you list the knowledge and assumptions you have, and the pros and cons of the recommended approach (possibly you might also want to add a list of dismissed alternative approaches, with reasons for their inadequacy.) This way, if anyone has information which might change the decision of what the "best" solution is (which they can see you weren't aware of), they are free to submit this additional alternative perspective
- "Information hiding" - as with object-oriented programming, you might want to consider which technical aspects of something you want to share, and which you do not want to share, when communicating. I'm not advocating that you withhold useful information from a stakeholder, I'm more suggesting that you reduce the "noise" level of your communication by focussing your message towards the agenda of the recipient (this also ties in with the "perspective" theme further up). With multiple recipients (e.g. in an email), you may wish to clearly indicate which parts of the message are intended for which audience (e.g. technical, non-technical, everyone) so as not to waste people's time or create confusion. If you try and use this technique for more political purposes, it usually backfires, as it ends up being obvious what you are doing! Used in the right way, "information hiding" can help make sure that team members focus on what doing what they do best, rather than getting involved in work outside of their skillsets
Hopefully this article is written in a way which is true to the principles I've outlined above! Let me know what you think :)