Can we talk?
Many people outside of the programming community (muggles?) have the idea that we sit in the dark, stare at bright screens, and only communicate via irc, twitter, hipchat, skype, or email. Most of the time they don’t even know what those terms mean, but they heard their niece talking about using them, so they throw the terms around to sound important.
How We Communicate
Sadly, in many of cases, this is a true description. It’s not sad that we use these tools. As developers, most of us have found the best way to communicate with our peers. What is sad is that we forget sometimes that the rest of the world doesn’t use these tools, and may not feel comfortable with them.
Case in point. I was trying to get some help from someone I work with recently. This person is not a programmer, even though they work at a high-tech startup. I saw that they were on-line on HipChat so I popped in and said “ping”. I got no response back. No “pong” no “ack” not even a “nak” for they are busy. Nothing.
Later on in the day, I went old-school and sent this person an email asking them my question. The response I got back was “Next time just send me an email, I’ll get to it faster.” FASTER? Faster than an instant messaging system? What they meant was that they will respond faster because they are more comfortable with the medium of email than that of hipchat.
See I wanted to communicate in the way that I thought was “fast”. I just had a simple question. My co-worker though, not being comfortable with IM clients, simply ignored my question. I had to find a way to communicate with them that made them feel comfortable.
The same goes with our clients. We have to find out how they want to communicate and then make sure we talk to them that way.
How We Say What We Say
Another thing we have to worry about when communicating with non-programmers, specifically those that we are working with, is how we say what we say. As developers, we have our own Domain Specific Language. (DSL) Most everyone reading this communicates in English, but within English, we have a specific way of talking to each other. We use industry terms, acronyms, memes, inside jokes, all of these and more. Your client isn’t going to get that.
More though than just making sure you steer clear of “Inside Baseball” lingo, you have to listen carefully to your client and how they speak. See, funny thing, we developers didn’t actually invent Domain Specific Languages, your clients have one too. Their industry has their own slang, acronyms, memes, and inside jokes. You, as the developer, need to understand how they speak and then translate “developer speak” into their DSL. I call this translating “Geek to English”.
It is your job as the developer to communicate not only your ideas, but your statuses to your clients in a way that they can understand.
How Often We Communicate
Finally, you as the developer have to make sure you communicate to your client in a timely manner. Timely manner can mean a lot of different things. I’ve had clients who would just throw specs over the wall and didn’t want to hear back from me till it was done. Other clients like to hear from me at the end of every day with a paragraph or two on what I accomplished that day. You don’t get to decide the cadence for communicating with your client, they do. it is your job to respect it. If your client doesn’t specify how often you should communicate with them, err on the side of over-communicating. I have yet to have a client tell me they knew too much about what I was doing.
On the other hand, don’t swamp them with nit-pick details.
I worked with a developer one time who was in a feud with our boss. This particular developer got so fed up with being berated for not getting the boss’s tasks done that the developer started keeping a log…in 5 minute increments. At the end of the day, the developer would turn in the log as proof of work. The boss didn’t understand that the requests being made were not reasonable. The boss also didn’t understand how to manage developers, but that’s a story for a different blog post.
The point is that the developer – in a fit of rage – chose to inundate our boss with minutia. Don’t go that far but make sure that your client understands what you are doing, how long you have been working on it, and approximately how long you expect it to take to finish the task.
- Talk to your clients in a way they are comfortable
- Talk to your clients in their language, not yours
- Talk to your clients as often as they are comfortable
The developer mentioned above – who was a very good developer, but a little hot headed – was soon transferred to another department at his request. The boss was fired about six months later for explaining to a female business analyst in another department that he could train a german shepard to do her job. – True story bro.
Until next time,
I <3 |<
Photo Credit:Jeremy Kendall
Photo is (c) Jeremy Kendall. All Rights Reserved
Photo is used by permission of Megan Kendall, the subject, and wife of the photographer. Cuz, well, we know who is in charge.