Trust Your Software Engineers Like You Trust Your Doctor

This is part of an ongoing startup advice series where I answer (anonymized!) questions from readers, like a written version of Smart Bear Live. To get your question answered, email me at [email protected]

Frustrated Engineer writes:

I’ve been writing code for 10 years, recently promoted to a position where I have to talk to our non-technical customers.

They want to use our software or customise things in ways that are technically impossible, but I don’t know how to communicate this to them. They don’t even know how little they know about software, so how do I basically tell them “You can’t understand this. You have to trust me” without sounding like a prick?

I like a doctor analogy.

The doctor says you have a rare liver disease and you’ll need to treat it with a dangerous cocktail of drugs. How do you evaluate whether the doctor is right?

For almost all of us, the answer is: You can’t.

You can’t ask for details, because you’ll get a torrent of nomenclature that’s greek to you (much of which really is Greek, or Latin), body parts you never knew existed, drug names you can’t spell with interactions you’ve never heard of, and references to studies you can’t read.

Even if she explained these details, you can’t evaluate the context — which of those things is dangerous, or unusual? Which are easy or hard to treat? Which are easy to deal with in isolation but complex when they interact? What other things isn’t she saying because in her expert mental process she takes them for granted?

You might try to evaluate the doctor herself, rather than her diagnosis, but here too your lack of expertise leaves you helpless. You can’t grill the doctor on medical knowledge — even incompetent ones know far more than you and can easily overwhelm you with terminology and information. You can’t ask for references because of course she’ll hand you good ones.

In the end there’s nothing you can do, because this is a field that takes years to master, in both education and real-world experience, the complexities and context of which cannot be satisfactorily transmitted to even an intelligent layman.

You’re going to have to trust your doctor.

That’s what it’s like talking to the architect of a software product containing a million lines of code. It’s not that the customer is “stupid,” nor that given enough time, training, and explanation, couldn’t eventually understand it all fully. But sometimes the customer just has to trust the vendor.

One way around this with doctors is to get a second opinion. You still can’t make the call, but at least you can get another expert on the case. Of course if the experts differ, you’re still stuck. Maybe a third opinion?  And even then they might choose the wrong course.

The problem with software is that other experts don’t know the intricacies of the software product in question.  They don’t know what’s in those millions of lines of code, or the trade-offs made by that product’s creators. The vendor might indeed be incompetent, or shrouding themselves in terminology to avoid helping the customer, and a second opinion isn’t an option. That’s unfortunate.

That’s why this comes down to trusting your software vendor, just like your trust your doctor. If you don’t, no one can help you, because you don’t believe what they say and yet cannot evaluate what they say. If that’s case, sounds like you need a new vendor.

So, as the vendor yourself, I would say (and in fact have said) all of the above. Put yourself out there. Make this a moment where you build trust.

All good business is built on that — trust, which is then not abused.

Business Insider Emails & Alerts

Site highlights each day to your inbox.

Follow Business Insider Australia on Facebook, Twitter, LinkedIn, and Instagram.