A colleague asked me the other day what’s my favourite way of extracting information from subject-matter experts (SMEs). This is a big topic in technical writing, as most of our time at work is spent chasing engineers and project managers to get bits of information.

My answer was “Be like Lieutenant Columbo”.

Why Lieutenant Columbo

Every documentation task is a reverse whodunnit: Much like it happens in almost every episode of Columbo, we know who did what from the start thanks to the numerous traces left in issue trackers, commit messages, and wireframes. Knowing who’s responsible for committing a feature (pun intended) is less important than confirming and explaining. We want SMEs to begrudgingly smile and nod at our version of the facts.

You get there by adapting some of the behavioural patterns that made Lt. Columbo so likeable to audiences worldwide. Some call it Lt. Columbo Technique. The following is my version of the Lt. Columbo technique applied to technical communication.

1. Create a safe space

The sincere admiration Columbo feels toward suspects manifests itself under the form of praise and positive comments, which make people feel more willing to share key information. Instead of tension and confrontation, he creates an amiable environment where people can feel at ease. It isn’t fake because Columbo is a nice fellow.

In a technical documentation context, you want to be that kind of person and provide a safe space for engineers. You don’t come pressuring subject-matter experts with your goals, needs, or deadlines; rather, you start a relationship based on positive voice and tone. Talk about the weather, ask them about their wellbeing, or about their last trip. Understand the human behind the tech.

More things can help with this. Showing up frequently and making yourself visible–for example, by chatting in an off-topic Slack channel, or by reacting with emojis to SMEs pull requests or stand-up messages–turn you into a familiar presence. Remember when Columbo drops in for no reason other than just saying “Hello”? That’s it.

Once you’ve established a good rapport with the SMEs, presenting your own documentation needs won’t face the same amount of friction as if you were cold calling them through a comment in Jira or GitHub.

2. Own your ignorance

Both technical writers and Lt. Columbo share the aim of extracting information from very smart people that have a deep domain knowledge. Like Columbo, technical writers have good chances of eliciting friendly, if at times condescending, responses from subject-matter experts. Contrary to intuition, your ignorance makes the job of asking questions a simpler task.

Columbo, of course, never improvises, so you shouldn’t either. After you’ve collected enough information, approach the subject-matter expert with open or indirect questions that show your genuine interest about their work, the challenges they’re facing, or the design decisions behind the things they’ve released to clients. Embody the curious, harmless layman.

For example, if you’re documenting an API endpoint for which you need to document several parameters, you’d start by showing the lead developer a response that you obtained using Postman (some sloppy evidence), followed by some (possibly) wrong observation regarding the request parameters. They’ll feel compelled to provide clarification. Lose the fear of presenting stuff that’s wrong. Engineers prefer seeing you tinkering with a test API environment using Postman or curl than waiting for them to provide everything.

3. Show Minimum Viable Docs

Lt. Columbo manages to extract information by presenting inconsistencies and weird hypothesis to intelligent people, who in turn feel compelled to help him in his deductive process. The engineering mind is deeply averse to contradictions and logical fallacies: Showing statements that are at odds is guaranteed to ignite a reaction in technical subject-matter experts.

Here’s where the concept of Minimum Viable Documentation (MVD) comes into play. Present SMEs with rough excerpts of what the docs for the feature could look like, underlining the inconsistencies of what seems to be a broken toy. If they care or feel proud about their creations, they won’t be able to resist the urge of pointing out the truth–lest an imperfection is published.

Not-viable-enough documentation is often a result of underlying product issues, which are excellent material for conversations with SMEs. Sometimes, even if they can’t be solved, they can lead to palliative docs care, that is, docs that help users cope with reality. It’s a win-win situation in that you’re helping users use the product, and SMEs avoid backslashes.

Oh, just one more thing…

One of the best things about watching an episode of Columbo is waiting for the Lieutenant to recite a variant of his signature catchphrase: Oh, just one more thing…, which is invariably followed by a question or a seemingly innocent remark that ends up catching suspects off-guard. It’s delightful.

As a technical writer, you want to have that same kind of canine, cheerful persistence. Conversations around products and docs are never really over, unless the thing you’re documenting is deprecated; even then, users might need to know what’s next, or what happened in their systems.

Go back to SMEs with key questions and don’t give up.

Eric Mason: You’re a fascinating man, Lieutenant.

Columbo: To a psychologist, sir?

EM: You pass yourself off as a puppy in a raincoat happily running around the yard digging holes all up in the garden, only you’re laying a minefield and wagging your tail.