How to Talk to an Engineer

Some things can get lost in translation between technical and non-technical employees

An illustration of two coworkers waving with speech bubbles over their heads. Each speech bubble has a different code.
Illustration: Momo

Jessica Powell, the former Google vice president who wrote The Big Disruption and told you how to quit your job, is here to answer your common but tricky work questions. Check back every other week for more management advice with a tech inflection.

I am a non-technical person at a tech company and feel like the engineers speak a different language from me. The other day, when I tried to convince them of a new direction for a product, they acted like I was from another planet. How can I talk like an engineer?

AAck! Whatever you do, don’t try to talk like an engineer if you’re not one. The consequences for being a poseur are far worse than just admitting that you don’t know the difference between Java and Javascript.

But there are definitely ways to communicate more effectively with engineers.

Before we get going, I should remind you that engineers hate generalizations.

Just like that one.

But since you’re asking for general advice, and since I love setting myself up to get trolled by engineers, let me continue to generalize for a moment.

In my experience, many technical people want to have discussions primarily based on facts and data. When debating a work issue, they don’t want you to lead with your opinions, or try to restate the problem with a fancy-looking chart that shows you aced PowerPoint in business school. What appears to demonstrate diligence to some of your sales or marketing colleagues may suggest obfuscation and unnecessary padding to many engineers. (Note: You also see this in academia, where people often make their slides look as ugly as possible. Plainness, it turns out, is its own form of marketing.)

Engineers want to understand the problem, have a chance to digest the evidence, and come to their own conclusions. This is what they have to do every day: Interrogating problems is a core part of most engineering jobs. And in fact, much of the time, an engineer’s code isn’t working.

So don’t shy away from problems, or reserve something negative for the very end. Engineers like to hear problems! They like negativity (within reason), since negativity, unlike PowerPoint, may suggest more honesty about the difficulty of the problem.

Clearly state the problem, state the evidence (not opinion!), and let the debate flow from there.

This is not to say that non-technical people are a bunch of touchy-feely types who want all the thinking done for them by someone else and will accept any opinion that’s given to them. But when communicating with a non-technical crowd, there tends to be a greater tolerance — and sometimes preference — for storytelling and packaging as a way to get at the heart of an issue.

Both approaches have value. And it’s worth keeping in mind that the exaggerated version we often see portrayed in the media — the stereotypical hyper-rational engineer with bad communication skills — is just as problematic in a work environment as the stereotypical snake-oil salesman with stellar charm. Luckily, most people on either side of the sales/engineering divide are hardly so extreme.

Let’s make this concrete.

Say you work on the editorial side at Medium and are trying to convince the engineers that the recommendation algorithm should more strongly favor advice columnists. The wrong approach is to shower them with anecdotes about how much you loved “Dear Abby” as a kid, and how you were recently at a party where everyone was talking about how they would love to read more advice columns. Who’s to say that those anecdotes are representative of your full user base, or that there isn’t a bias in how those anecdotes were culled? (I mean, really, what kind of people do you hang out with that they talk about advice columns at parties?)

Instead, consider what kind of data would help you make this argument. Are advice columns the most popular thing on Medium? Have advice columns proliferated in number across the country over the past two years? Are there parallels you can find in other editorial areas? Competing products that have public metrics?

Of course, not all problems lend themselves to this approach. For example, how would you advise your engineering counterparts to not launch their robot sex doll in Country X, because people in Country X believe sex can only exist between humans? No one’s launched a robot sex doll in Country X; you don’t have any data showing it will be a failure in this country. You’re going to have to rely on other kinds of evidence — news articles, for example, reflecting popular sentiment about robot sex.

These are much harder arguments to navigate, but the best path forward is still to clearly state the problem, state the evidence (not opinion!) as to why this will be a problem, and let the debate flow from there. Don’t be intimidated, go forth and communicate!

01000100 01101111 00100000 01101110 01101111 01110100 00100000 01100010 01100101 00100000 01110011 01100011 01100001 01110010 01100101 01100100 00100000 01100010 01111001 00100000 01100101 01101110 01100111 01101001 01101110 01100101 01100101 01110010 01110011 00101110

(Translation: Do not be scared by engineers.)

Technophile, technophobe. Music software start-up founder. Former Google VP. Author, The Big Disruption. Fan of shochu, chocolate, and the absurd.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store