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.
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
We couldn’t get a client to understand the distinction between “web developer” and “web consultant.” This was coming up because they were planning on executing a project in a way that made very little sense technically or strategically, and were only phrasing questions in “how much would you charge to execute this” terms.
Hiring us is like hiring a taxi driver. If you want to give us street-by-street instructions for getting somewhere, we can do it—but since you’re taking our knowledge and experience out of the equation, whether we follow a sane route depends solely on your knowledge of the city, and you’ll need to micromanage us. On the other hand, if you simply tell us, “I want to get to the airport,” we can suggest the best way to get where you’re going, and the project is likely to be smoother, more collaborative, and less expensive overall.
The clients instantly understood the distinction we were trying to make, and agreed to the short roadmapping consulting project we were proposing rather than per-hour development on their terms.
Example 2: Online store as supermarket
We worked for an older client with very limited knowledge of online business. Someone had built him an online store, but the checkout process was extremely convoluted, designed to be completed over the phone only after a form signup and multiple e-mail interactions. Because he was experiencing no sales, the client wanted our help getting more traffic to the site.
The current site is like a supermarket with no checkout counters. However many shoppers you’re able to bring in, the store won’t make money, because there’s no easy way for shoppers to pay you. Like any supermarket, the site needs a simple, quick, efficient form of checkout.
The client was reoriented toward improving the on-site experience, and engaged us for a pricing table and a simple e-commerce solution to replace the form signup.
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