Being a Developer: Communication Woes

 As a developer there are a number of skills in your repertoire, and many of them have obvious value at first glance. The ability to think logically, problem solve, comprehend abstract ideas and theories, pay close attention to detail and think "outside the box" are all part of your arsenal. One of the skills that you may have under-valued will likely surprise you a little, but we are here to tell you that communication is one of the most important skills a developer can have.

If you are sitting there thinking, "anyone can communicate" or "how hard could talking be" then the rest of this post will be a real eye opener for you. As a developer, you will find yourself having to communicate with many different types of people about many different things. When talking to other developers, you will need to be especially detailed. You may need to explain your code, your train of thought, which programming theories are at work, and you may need to use what the laymen would call techno babble. On the other hand when talking to a client you will want to be abbreviated and get straight down to "how does this affect my bottom line."

There are a million intricacies to communication at any level, but below are some tips on communicating with different people as a consultant in a firm:

Communicating with project managers:

Talking to PM's can be a bit difficult but the trouble is primarily focused around a single question, "Can this be done?". As developers, we know that anything can be done given enough time. Oversimplifying your response could be your downfall. In order to prevent your demise, we have compiled the following suggestions:

1. State your assumptions - By stating your assumptions from the outset, you provide insight into your thoughts, and provide yourself a way to change your approach if there are unseen complications.
2. Provide a range with your estimates - When you state the hours that it will take you, provide a range. The low end is without complications, the high end is the number that you know 100% without a doubt it will be done, even if the world ends. As you're estimating time, be sure to include the time it will take to actually look into the issue -- that will often take as much time (if not more) than the fix itself!
3. Be Clear about your availability - You know that you bill X hours in a day, and you know what other things you have in your queue. By stating explicitly that the timeline will be stretched, this gives the PM something to bring back to the client. It also reminds them that by spending hours on this, it is taking hours away from what you were already doing. 
4. Define scope - By stating the scope of the project, the project manager will know if the item should be post-poned, if it should be billed separately, or if pushing back is appropriate.
5. Time vs. Value - Sometimes the scope isn't clear on an item. In this situation, it is important to weigh the time vs. the value. If it is low-hanging fruit, that can make a big difference to the client. Your PM can go back to the client and let them know that while the item wasn't necessarily part of the scope, you took care of it for them. This just helps to build the relationship and let your client know you are looking out for them.
6. Take your time - Always ask for time to look into something more thoroughly before committing to it. Throwing a number out off the cuff is dangerous, because your mind may not be in it, or you may be forgetting some major piece that is blocking your estimate from being realistic. This is just a way to shield yourself from bad estimates or ego estimates.
7. Communicate changes early and often - Always let your project manager know as far in advance as possible if you think you will miss a deadline, or if you can tell that you will exceed an estimate. More often than not a PM can go to a client and say "due to X, Y and Z circumstances this is going to take us 3 more hours than we initially anticipated." If you can get approval on the overage ahead of time that's better than telling them after the fact, and the same goes for missing a deadline entirely. It's amazing how delaying one week is infinitely different when you finish a month before the deadline vs. a few days before!
8. Make your demands (Communicate your preferences) - Communicate with your Project Manager about the tools you prefer using for bug tracking (Google Spreadsheet, Trac, Mantis, etc). Don't just complain about how someone doesn't know how to report a bug -- tell them explicitly what you need for each bug, and why.

All of these points come together to say, it is our job as developers to state our assumptions, investigate fully, and be mindful of scope when answering this very dangerous question. A good answer always comes in three parts: time, scope and assumptions. For example, "Assuming X is true, I can get this done in X-Y hours." If X turns out not to be true, it adds X hours to my estimate. This means that we will need to stretch the timeline of the deliverable by X days. This item is 'in/outside/undefined in the scope of the project. I believe we should 'do it/push back'. Let me look into it a little more thoroughly before we commit to it."

Communicating with the Client:

Perhaps the trickiest part of being a developer is communicating with the client. Clients aren't someone you will have a strong relationship with, and you have to be very diplomatic when talking to them. Most of the time the PM will be your intermediary, but in the situation that you are going it alone, here are some guidelines:

1. Defer to PM on scope/timeline - Clients often asks that same "Can this be done?" question. A good response to this is always qualified with "I will make a note that you asked about this and speak with the PM about it. The PM can get back to you with specifics." It is important that you never make a commitment to a client on timeline, hours, estimates, or functionalities as a developer. Equally acceptable is "Speaking purely from a technical perspective it can be done, yes. This is how it would work ... However I can't speak to whether or not it is in scope for this project, you'll have to ask the project manager."
2. Be careful with tech jargon - When talking to the client, it is important to answer their questions directly, so long as it doesn't conflict with #1. It is important to speak plainly and not confuse the client. If you aren't sure that you can answer the question in a plain way, simply say "let me get back to you on that." Flag the issue with your PM, and move on.
3. Don't "fix" - If your client says "X is broken.", don't say "we will fix it". Its probably best to avoid the word "fix" entirely. An acceptable response is "I'll look into it". This may seem trivial, but while you as a developer know that you may not be to blame for a bug, the client may not. When you use the word "fix", this could in some level imply that you "broke" something, or that you or someone on your team is directly to blame for the issue. If you aren't careful accepting blame for issues, it might come back to haunt you in the end.

If you skimmed over all of the rest of the article, please just read this: Communicating on any level is vitally important. We developers, often introverted in demeanor, need to fight everything inside of us to get rid of the "island" mentality where we work in a little bubble and only emerge when we're done and need to hand the project to someone else.  Instead, we need to stay in the middle of the communication stream -- talking to our teammates to ensure we don't spin our wheels for too long on a given problem; talking to our project managers to ensure they are updated on the status of the project and can be continually updating everyone's expectations; and talking to our clients (as needed) to ensure that their expectations are in line with internal expectations (regarding scope, timeline, budget, etc).

So what do you think is your most important skill as a developer?  Perhaps you need to think twice before you brag on your ninja CSS skills, or your Mensa problem solving skills... How well are you communicating?
 

Brought to you by Travis Black and Madeleine Perry of EchoDitto in collaboration with Chip Hayner of centresource