If you’re a self-employed developer, managing client communication is your job, and your skill at it will impact your project’s success just as dramatically as the quality of your code.

One great way to make yourself valuable is to be “a technical person who can talk to people.” Deep technical knowledge is an absolute requirement for most development projects, but the team will also need the ability to explain key technical information to others: to the person writing the checks, to the person who needs to be steered away from expedient but fragile solutions, to the person who doesn’t understand why the whole thing is taking so long. (These may all be the same person.)

These folks don’t need to be turned into software engineers themselves; they just need to understand the outline of a project well enough to make the decisions they need to make. If you’re a self-employed developer or part of a small development team, managing client communication is your job, and your skill at it will impact your project’s success just as dramatically as the quality of your code.

Analogies help

One tool I’d like to suggest for this kind of communication is a well-crafted analogy. Analogies are tailor-made to communicate the essence of an idea in a way that is clean, memorable, and nontechnical—and, broadly, the less concrete and technical someone’s mind is, the more it may be symbolic and associative. So a scattered marketing manager or an eager but fuzzy client may be particularly well-suited for this kind of communication.

Here are a couple of examples that have come up in our own work with clients, and yielded tangible results:

Example 1: Web consultant as taxi driver

Example 2: Online store as supermarket

How to do it

Think about the key principle you’re explaining, and find similar examples of the principle in everyday life.

First of all, don’t force it. You only need to start looking for analogies when there’s a big principle that you can’t get across. Most questions can be resolved by a (more or less detailed) description of the technical details at play. There’s need to explain “I need your FTP credentials” using a folksy analogy.

Second, unless you like to improvise, plan the analogy and how you’ll get it across. Think about the key principle you’re explaining, and find similar examples of the principle in everyday life.

Example: Selling a client on a CMS

Let’s imagine you’re trying to defend your recommendation that a project use a content management system instead of being hardcoded. What’s the principle that would justify the (potentially) increased cost and complexity? In this case, the principle is that people should be able to take ownership of and change the things that were built for them, instead of being wholly dependent on the builders.

So what’s a similar situation in life, where someone builds something in a way that either allows or does not allow you to change the content? Maybe you can imagine the silly idea of a TV where only the engineers know how to change the channel. This is quite a bit like a website with totally static content.

Once you’ve got the basic analogy established, you can explore its implications:

• Value proposition of a CMS: “The Cartoon Network may be your favorite channel for a long time, but eventually maybe you’d like to change the channel without calling up an engineer. In other words, you want to be able to manage your TV yourself, so that it’ll display whatever content you want.”
• Slight increase in complexity: “It was probably more difficult for TV builders to create remotes and variable receivers, rather than just hard-wiring the frequency the TV would receive—but it definitely paid off in the user experience.”
• Distinction between managing content (nontechnical) and bugfixing and redesign (technical): “Notice that you still can’t fix the TV if it breaks; you need professionals for that. In fact, a TV with a remote is probably slightly more complex to fix than one that’s just wired to one channel. You also can’t, for example, swap the screen out for a larger one without professional help. But once your TV’s working properly, you can change the content—the channel—with just a bit of training in using the remote.”

See? Analogies are fun. And the mental image of a TV stuck on one channel will probably do a lot more to convince your client of the wisdom of a CMS than a less colorful description might.

Talking to people in their language

The basic principle here is that you need to be able to meet people where they’re at. It can be easy as a technical person to simply shrug at the vast gap in knowledge that keeps others from understanding what you’re on about. But if you’re more than an engineer—if you’re a salesperson, project manager, or consultant, and especially if you’re self-employed and are all of those things—then you need to communicate clearly. Analogies are a great tool for some situations. Give them a try!

Image Credits: CargoCult