6 ways to bridge the customer-engineer gap

When was the last time you spoke to a customer? Or better yet, when was the last time someone from your engineering team spoke to a customer?

Ask that question to engineers in your organization and odds are that they’ll shrug and say, “I’m here to write code, not to talk to customers.” So when DoorDash asks employees to deliver food, there is a backlash: “You hired me to write code, not deliver food.”

But it’s important for engineers to ask themselves, “Why do I write code?” The answer is critical to the success of your organization, because at the other end of code is a customer who experiences the result of your coding. Are they happy with it? Did it solve their problem well?

Delivering food is meant to help DoorDash employees experience how their customers use and benefit from their app. At Intuit, employees experience this via ‘Follow me homes’ to watch how customers use their products. As an engineer, or for any employee, it is humbling and educational when you realize the gap between how you think customers use your products, to the sometimes-messy reality of how they actually use it.

Startups have, by necessity, a close connection to customers. If they are not able to acquire customers, they have to close shop. Irrespective of training, entrepreneurs have to build customer empathy and that requires them to work closely with customers. But as businesses become successful, their DNA changes. Customer Support departments deal with customer issues. A Sales organization is created to bring in new customers. Product Managers are delegated the task of building out product roadmaps and stand in for customer needs. And somewhere far, far away, the lonely engineer toils in her cubicle churning out code with little idea of how it will be used.

Do you remember the game of telephone? Whisper something into the ear of someone next to you, who passes it on — and after a few whispers, what the last person states was completely different from what the original statement was. We play telephone at work, too. A customer complains about something. The customer support agent creates an enhancement request. The product manager incorporates it into the roadmap. Each one of these steps introduces drift. What the engineer at the receiving end builds is unlikely to address the customer’s original complaint.

Conway’s law dictates that organizations will mirror their communication structure. An unfortunate side effect of Conway’s law is the separation between engineers and customers. That’s why I caution leaders to:

Beware of proxies

Great organizations offer line of sight to customers in every department.

At Inflection, we strive to ensure that every department has the opportunity and tools to understand the quantitative (metrics, dashboards, sentiment analysis) and the qualitative (participation in customer calls and sales calls). Doing so converts an engineer into a ‘Product Engineer’—someone who cares as much about the customer experience as they do about the quality of code they’re writing. In my experience, Product Engineers are the best kind of engineers because they’re always looking to better understand the customer’s context around the work they’re doing—and hence solve the problem better.

Proxying, or delegating, customer empathy to Product Managers and Customer Support results in a lack of empathy and a subservient attitude toward Product Management. Instead, I encourage engineers to think of other functions within the organization as true partners. Knowing the customer problem and representing them in decisions enables a true partnership.

Here are some best practices to enable close connections to customers in your organization.

1. Establish an on-call program

At any given time, one or more engineers from Inflection’s engineering team are on call. They do not pick up stories from their backlog — their job is to look for errors in the system and address them, and to listen to customers. Engineers will listen in on live or recorded calls in Sales or Customer Support. They attend to customer complaints and improve the product. Listening to customers voice their thoughts, ask questions, or share their frustrations gives the engineering team a visceral sense of who we serve, how they use our product, and why they like or dislike it. This activity helps to increase ownership. At Inflection, everyone in engineering (including the CTO) has on-call responsibilities.

Action: Establish an on-call program if you do not already have one.

2. Role model customer empathy

Teams mimic the values exhibited by their leaders. Every action you take is subconsciously echoed in the rest of the organization. If you want engineers to develop customer empathy, it’s important to take actions that you want the rest of the team to mirror. How do you model customer empathy? You and your organization’s leaders need to talk to customers, too. At Inflection, we invite customers to attend our executive meetings and share their feedback directly with us. 

Action: Have executives role model customer empathy. The rest of the organization will follow suit.

3. Make the back office glamorous

Most often, your product organization’s attention is focused on developing customer-facing software, and so that’s where the resources go. Consequently, the best engineers work on customer-facing systems. The employees in the Customer Support organization rarely get the same love. The back office is allowed to languish, with obsolete, poorly maintained, and fragmented technology. Without access to the best back-office resources, customer service declines.

Action: Move your best engineers to the back-office engineering team. Enable them to build experiences that allow Customer Support to delight customers.

4. Give room for engineers to innovate

Most organizations follow some kind of an agile process. Backlog items are often created by Product managers. Once you have more product engineers in the organization, give them a way to fix all they have learned about customer problems directly. At Inflection, we enable this by organizing a quarterly hackathon we call ‘ShipIt!’.

The following rules apply to ShipIt!

• Engineers determine what they will work on; management—including Product Managers—have no say in what engineers work on.
• The ‘FedEx model’ applies—teams deliver, into production, what they worked on.
• Engineers present to the organization—including execs—what they accomplished; they only get five minutes per team.
• Zero distractions; no meetings unless there is a priority incident.
• The company takes care of delivering food and we encourage employees to have fun.

The results from ShipIt! are amazing. Teams deliver innovative solutions in a compressed time frame, often addressing long-standing customer problems.

5. Establish a customer benefits framework

What KPIs do you see on your Executive dashboard? They likely include metrics around customer acquisition, revenue, and employee retention, but there’s one key performance indicator you might be missing. Customer Benefits. Are you measuring the value of what you do from a customer’s lens?

This powerful concept is often underutilized in the technology industry. A great example of Customer Benefits is from Amazon. Amazon always solves for three enduring customer benefits: Faster shipping, lower cost, and greater selection. Every decision the company makes is centered around improving these three customer benefits. Have you noticed that Amazon does not group your purchases very often, and instead sends multiple packages? That is because of the ‘faster shipping’ customer benefit. I heard an anecdote from an ex-Amazon employee that an executive proposed a way of grouping customer purchases to reduce Amazon’s shipping costs. The idea was shot down because it went against the company’s ‘faster shipping’ customer benefit. Having customer benefits metrics on your dashboard enables all employees—including engineers—to keep customer outcomes front and center of all they do.

Action: Implementing a Customer Benefits framework helps ensure that leaders are thinking about the customers in all they do.

6. Know your customer

Teams within an organization often confuse customers and partners. If you ask your platform engineering team who their customer is—who the end-user of their product is—invariably the answer will be ‘the product engineering team.’ That sort of thinking results in misaligned teams. Organizations work together to serve the same customer; other internal teams should not be working to meet the needs of another team—they are each other’s partners; they’re working together to deliver the customer benefit.

Action: Help your teams understand who the customer is, and who they’re partnering with to deliver excellent customer benefits. Do not confuse the two.

Reducing the gap between customers and engineering teams will result in more valuable engineers—and a better product. Customers will see the company moving fast on their feedback. Your NPS scores will rise. And that game of telephone will be replaced by a highly engaged team that places the customer in the center of all they do. This results not only in better customer outcomes, but also helps with highly engaged and productive employees.