Developers and Communication

To be fair, developers are mostly introverted. Talking out loud in groups doesn’t come easy. We’re drawn to work that requires hyperfocus and isolation. Sometimes we seem unapproachable or cranky. That’s because interruptions cost us heavily, slowing us down more than most. We feel everyone should know better, but endless chat alerts (like Slack’s “@channel” feature) tell otherwise. We don’t just prefer alone time; we need stretches of alone time in order to be productive. Programming also takes a real toll on verbal abilities. It takes time to get into the groove and time to get out of it too. It’s difficult to answer questions in English after a stretch of thinking in PHP, so if we sound confused, give us a few minutes. You deserve a thoughtful answer, and we’d like to give one.

True as all of that may be, none of it lets us off the hook. The good news is that non-technical people are generally pretty helpful. If you want to be a better communicator, all you have to do is ask for advice, so that’s what I did. I asked friends and workmates for their thoughts on the subject, and I was surprised at how eager they were to contribute.

Developer friends, here are a few helpful points to up your communication skills:

1. Speak up

If you are invited to a meeting, you belong there to provide input. If something sounds like a development risk, speak up. Raise flags when flags need raising, not months later when it’s too late to change course. Ask for clarification so you understand requirements clearly. Your project manager will pick up on your concern and direct the conversation accordingly.

2. Don’t freak out

Hey, freak outs happens. We’re waist-deep in a project, burdened by interruptions, under tight timelines, or working day and night on a hard-to-solve bug ticket when someone (a client maybe) suggests a new, gigantic feature. Faced with the threat of even more work, our inner freak-out monster materializes out of thin air. Our mental chambers echo, “That’s stupid, totally unnecessary, and the requirements have already been signed off on, so why are we even talking about this? This should wait ’til after launch!”

Relax. Nobody’s trying to burden you. Your client and teammates are just trying to gauge feasibility. Remember that just because the design is done, it doesn’t mean the project is over. A developer’s default response should be, “We need to research that to estimate the impact on the timeline and budget.”

If the request sounds out of scope from a development point of view, encourage an extended engagement. “That sounds like a pretty large task, but a great option for version two of the website. We can look into how it would impact the current build in order to leave the possibility open.” Your sales team will thank you.

3. When addressing a client, say we not I

Say “I” enough and your client might start thinking, “Shoot, I just need to hire one of you then.” Your greatest asset isn’t your code or your brain. Your greatest asset is the confidence you give others that their project can get done on time, within budget. Clients come to your team because they have a problem they can’t solve internally. Their confidence is in your team as a whole, not just the code you chug out. Strengthen that confidence by keeping that team context in everything you say.

4. Don’t think out loud in front of a client

I can’t even count the times I’ve been in an internal meeting or on a client call and been asked, “So, how would we do that?” I promise you, that is not the question you need to answer. You might be tempted to offer a plan of attack in the spirit of transparency. Saying this to a developer sounds perfectly fine: “Well, [chosen CMS] has a great plugin for that. It does mean a little extra work with the registration flow. Come to think of it, there might be a conflict with another plugin. Maybe we need to write a custom plugin. Hmm…” But saying this to a client? What you’ve actually done is alarm the client, discredit yourself, and diminish everyone’s confidence level.

Pretend the client is asking: “How feasible is this? Will it affect the launch date? Are there any extra costs involved?” A better answer would then be: “We can’t really say without putting some thought into it, but there are some good options open to us. My gut tells me it might take a week or two. You might also need to pay for access to the Google Maps API. We’ll look into it and can post a followup to Basecamp by Friday.” <3 a PM’s dream!

5. Befriend your designers

We all know designers and developers are different animals. Sometimes, designers conjure up ideas that seem excessive to developers. Stall that inner freak-out monster by offering a simple time estimate. “I figure that would take me about six hours.” Sometimes you’ll hear a friendly, “Oh, it’s not that important. Nevermind.” (True story.)

If you’re worried these five points are too much to juggle at once, find hope in the old saying, “If you want what other people have, all you have to do is do what they do.” Better communication happens with practice, not overnight. Start with a few canned responses that you repurpose and repeat—just like you do when you’re copying and pasting other people’s code to serve your own sites. When you speak up and talk with your team and clients more, you’ll improve more quickly.

I’m sure there’s more good advice out there. Ask your own non-devs how you can better communicate, and share your learnings here. We can learn from each other to be the best communicators we can be!

Back to Top