Communicating with Non-Engineers – Lyft Engineering

Communicating with Non-Engineers

As a Release Manager, I see many of the conversations that happen between engineering and other departments. I can relate to both sides. When I first joined Lyft, I thought that request and response were verbs you used when you had written the word “said” too many times. Coming from a non-CS background, I‘ve experienced how intimidating it can be to be working with a developer and comprehending only every fifth word they are saying. Since becoming part of the engineering team a year and half ago, I also know how hard it can be to communicate what you’re working on.

Let’s start with some examples of a variation of what every engineer has written as some point:

My PR hasn’t merged in GitHub, the changes won’t be reflected in master.

Questions a non-engineer has:

Why are we talking to PR about this already?

I think you spelled “get” wrong.

Or what about:

This is being caused by a 500 response from a Stripe HTTP call.

This can lead to many questions:

500 is a big number. Should I be concerned?

Stripe? Payments related. Probably

Http, like a website?

And, a confused takeaway:

Something is being caused by a big number on a website that could be related to payments.

So how can you make it so the other person isn’t desperately googling sentences from your email?

I have three tips to keep in mind that will help you navigate conversations within your company. If your job has no cross-team elements, these tips should come in handy when talking to family, first dates or that one person left in your life that still has their AOL email address.

Slow Your Roll.

Regardless of your job, this is an important thing to keep in mind. There is a fine balance between dumbing things down and needing to stay accurate and precise, but just choosing different words can help. Trimming down the acronyms, slang, and technical words you’re using is the easiest way to start doing this. At the end of the day, it’s about translating your thoughts into a common language that will make sense.

Benoit Hediard put out one of my favorite graphics that clearly explains an engineering topic. It uses visuals to express relationships, and if you look at the graphic again, you’ll notice there isn’t any slang or complex vocabulary used to get the point across. (As a side note, I’m personally excited for when we achieve pizza architecture.)

Everyone you encounter in your company is an expert at something; they are just as able to spit out some obscure sounding terminology as you are. Imagine if you were in their shoes and they had to explain a nuanced part of their job.

Think About Access.

The second tip is to consider the access level that other teams have. Asking a member of the support team to look something up in MongoDB might not get you very far. Also keep in mind that different user support teams have different access to data. For example, risk and fraud teams will have more information at their fingertips than standard support. A great way to learn this is to shadow someone on a different team in your company; you’ll get a chance to see how they use tools and ways to improve on them.

If the project you are working on together has multiple components be the bridge to help connect other people. For example, should the designer and the copywriter be talking to each other and not through someone? This is another type of access: social access. Is there an introduction you can offer to make? Is there someone more knowledgeable about the project that they could be talking to?


I asked a friend on our driver operations team which engineers were good communicators and why. She said: “It’s less that they’re good at explaining technical things to me, although they’re good at that, they’re good at listening to me be not technical, and translating that in an approachable way.” I reached out to one of the engineers she highlighted during our conversation to find out what he does. He told me that he always likes to first ask if the other person is familiar with the technology. This is a great tip because you’ll know the level that you need to talk at, and also clues you into what vocabulary you can use during the conversation. This, of course, loops us back to the first tip.

A trick I found useful in a past life as a teacher was having the other person repeat back what they have learned from you. This will help you to make sure they understand what was being communicated and also helps you to understand what you can explain better next time.

Let’s revisit one of the examples we started with:

My PR hasn’t merged in GitHub, the changes won’t be reflected in master.

And tweak it just a little to be:

The changes that will fix the crash aren’t live yet. Post here if you’re still seeing it in half an hour.

So, remember: slow your roll, think about access, and listen to what the other person is saying.

Have some other tips for inter-team communication? Let me know on Twitter or at

N E X TBuilding single activity apps using Scoop

Source link