Skip to main content

Choose theme:

blog of developer & bookworm benjamin read

Explaining technical things to nontechnical thinkers

A significant part of our jobs as developers is explaining technical things to people who don't have the same technical knowledge. How do we help someone to make a decision that involves technical understanding?

A large part of any developers role is not coding, but explaining what needs to be written, or explaining what was written by somebody else, or to help make decisions on procurement or other things.

How do we do this effectively? If we start explaining technical things to those who don't have the background we do, we'll lose them within the first few words. So we need to find a way around the problem.

Use comparisons

One method I've used a lot lately is comparisons.

In a selection process for a search tool, we had a broad range of tools that we spent a lot of time researching. Some tools were extremely simple, off-the-shelf plugins. Others were fully-featured Saas apps. And some were whole environments that you could upload to a server and build an experience around.

In order to convey the breadth of what we had, I used cars as a comparison to these tools.

Our SaaS tool was a Porsche, because it was not just what we needed in a neat package, but it was also really nice to travel in.

We found a very basic cloud tool that was suitable, but had almost none of the features that the SaaS tool had, so I compared it to a handcar that involved a lot of manual work, but would still get us there.

There was a new contender on the market, which was still in active development. I compared this to a concept car that I knew would eventually do everything we needed to, but for now it was a nice dream.

And then there were some enterprise offerings that were immensely configurable but would require many months of development time to configure, and a sizeable investment to maintain, that I compared to a car factory, because it would provide what we need, but we'd need to build the factory first ... and we only needed one car.

Comparisons hit home when they contain only the information that's needed. Even specifying what type of car was perhaps an unnecessary detail I could've dropped here.

And comparisons work even better when they are something the person can relate to. I knew we all understood the concept of cars and what it takes to manufacture one, so this was a good basis for comparison.

I'm still learning how to explain technical concepts to others in my team, but slowly, and with consideration for others' points of view, we'll get there together.