When you do the kind of consulting work that cuts across different kinds of businesses or vertical software markets, you don't always pay close attention to what sort of business your clients are involved in — but you should.
Years ago, I struck a mother lode of a niche after Synergy/DE became available for Windows. Many software vendors who used that language began porting their applications to Windows, and even though Synergy/DE achieved a very high level of cross-platform portability, these vendors needed a lot of help making their applications more "Windowsish" (as demanded by their users, for better or worse). I added 10 clients to my list that year.
One day as I was chatting with a long-term client who is also a good personal friend, he asked me how business was going. I replied that it was gangbusters — I was taking on new clients every month. "Oh... who?" he asked. I rattled off several names (which you should never do, by the way), and one of them caught his attention. They were a direct competitor. I had no idea.
"What kind of work did you do for them?" he asked.
"Basically the same sort of stuff I did for... uh... you," I stammered.
It took quite a bit of explaining to convince my client that because this work was not application-specific, nor was it anything unusual or particularly inventive, that it didn't represent a breach of confidentiality. I had shared no details of one client's application with the other. I had done similar work for many different kinds of applications. It was really no different than the fact that they were both clients of the same language vendor. He was satisfied with my explanation, and we remain good friends to this day.
But I do believe that event placed a limit on our consulting relationship thereafter. I never got involved with the details of their application, only general design principles and frameworks. Knowing that their competitor was on my client list (even though I never did any further work for that other client) may have prevented them from involving me more deeply in their specific projects. I regret that because they're a great company and they've gone on to be highly successful. I would have liked to have had a greater hand in that success.
I learned an important lesson: Even when you don't need to know your client's business in order to help them, learn as much as you can anyway. Besides making your contribution more valuable, it also prevents inadvertently stepping into conflicts of interest. Before you accept an engagement, make sure you know that your new client isn't a competitor of an existing one (unless you're ready to cut your existing client loose), or that your contributions are generic enough that it's really okay for you to work for both. If in doubt, ask your existing client. And by all means, disclose your existing relationship to your new client.
I was reminded of this lesson when I recently accepted a new engagement involving the development and promotion of a new programming language. One of my long-term clients is a programming language vendor, and they've shared many secrets with me under NDA, right down to the last line of their source code. So before I accepted, I disclosed my relationship with that client and asked enough questions of my prospect to insure that they weren't competing for the same kinds of applications. It turns out that there's almost no overlap; if anything, these two languages might want to interoperate one day. So I felt free to accept — but should I find out differently as I get into it, I would bow out right away.
Have you ever had to deal with a client who was upset because they considered one of your other clients to be a competitor? If so, how did you handle it?Get weekly consulting tips in your inbox TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!
Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant blog, he also contributes to [Geeks Are Sexy] Technology News and his two personal blogs, Chip's Quips and Chip's Tips for Developers.