Developing Client Communication Skills as an Engineer

My bootcamp program taught me the importance of communication skills, but mainly in the context of writing a cover letter highlighting the attributes that make me a good teammate, so companies would want to hire me. Our coding projects consisted of building fun things like a TicTacToe web app or a program that checked if a string was a haiku. We didn’t talk much about programming for clients, or the subject of this article – how to talk to clients.

Luckily, my internship with Planet Argon provided some insight into client interactions and prepped me with some things to keep in mind for the inevitable meetings I’ll one day have with clients.

If you’re working as a developer in an agency setting, chances are you’ll be building many different apps, for many different clients, with many different backgrounds when it comes to tech know-how. Some may know exactly what feature they want, exactly where in the app they want it, and exactly who they want to be able to access it. A far more likely scenario, however, is a client who knows they want a feature...and that’s it.

Allow me to walk you through a scenario. A likely one. You might encounter something similar someday, or perhaps you already have before. I witnessed this scenario first hand while pairing with Scott Dudley, a wonderful developer at Planet Argon.

We were working with a client from the insurance world. Within their app, there’s a list of all the open claims, and each claim has a checkbox to mark if it’s approved or not. The client was requesting a new feature in which users on the admin side can see the time when a claim is marked as approved.

On the surface it seems like a fairly straightforward update:

• Add a column to record the timestamp when a claim is changed from unapproved to approved...
• Or maybe change the column type to DateTime, so a null value would be unapproved and the presence of DateTime gives you both the approved status and the timestamp of when it occurred.
  
• Throw a conditional into the claims’ list view to check if a user is an admin, if they are, display the timestamp, and Bob’s your uncle.

But once you start, questions start to arise...

• Both brokers and adjusters have admin rights, do both roles need to see this information?
  
• Are claims only marked approved from unapproved once? Or are they toggled between the two values often?
  
• Does the timestamp need to be recorded every time this value changes, or just the first time?
• Does the user who marked the claim as approved need to be recorded along with the timestamp?
  
• Should this information be displayed within the list? On the claim’s detail page? Somewhere else?
  

I could go on, but you get the point. Obviously, there comes a time when questions need to stop and programming needs to start, but it’s important to be thorough. This helps you to avoid having to go back and revise a bunch of changes you just made because a client’s needs were much more complex than they appeared on the surface.

This works the other way as well – it’s certainly possible to over-engineer a feature for a client when a couple of clarifying questions could possibly lead to a much simpler, less time-consuming solution.

So Scott sent over some clarifying questions to the client, and upon receiving a response was much more prepared to tackle the challenge. This was much more efficient than simply guessing what the client might want or going with the seemingly simplest solution.

This experience revealed a whole side of being a developer to which I haven’t given much consideration. Things that seem obvious to us as developers may not be so obvious to our clients. What we as developers think is the best solution may not be what the client wants or may not be in their budget. It’s up to the developer to clarify the client’s needs, discuss the solutions, and allow the client to make an informed decision on how to move forward.

If you’re looking to work in an agency environment, you will be communicating with clients, and knowing how to communicate with them is an important skill to develop.

Requirements gathering may not be the sexiest subject and if you’re a budding developer, probably isn’t at the top of your Skills to Hone List. It is, however, a fundamental aspect of any development project and a process that all developers should keep in mind when beginning a new project or adding a new feature. Now when I approach any programming problem I like to think through not only how I would solve it, but also how I would explain it to someone in a non-technical way- great practice for my numerous future client meetings.

I’m super grateful to Planet Argon for providing the experience of sitting in on a couple developer/client meetings and the opportunity to work alongside developers while they communicate with clients to figure out their needs – just a couple pieces to a well-rounded internship that has led to tremendous growth in my developer skillset.