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?\n\nAsk that question to engineers in your organization and odds are that they\u2019ll shrug and say, \u201cI\u2019m here to write code, not to talk to customers.\u201d So when DoorDash asks employees to deliver food, there is a backlash: \u201cYou hired me to write code, not deliver food.\u201d\n\nBut it\u2019s important for engineers to ask themselves, \u201cWhy do I write code?\u201d 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?\n\nDelivering food is meant to help DoorDash employees experience how their customers use and benefit from their app. At Intuit, employees experience this via \u2018Follow me homes\u2019 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.\n\nStartups 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.\n\nDo you remember the game of telephone? Whisper something into the ear of someone next to you, who passes it on \u2014 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\u2019s original complaint.\n\nConway\u2019s law dictates that organizations will mirror their communication structure. An unfortunate side effect of Conway\u2019s law is the separation between engineers and customers. That\u2019s why I caution leaders to:\n\nBeware of proxies\n\nGreat organizations offer line of sight to customers in every department.\n\nAt 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 \u2018Product Engineer\u2019\u2014someone who cares as much about the customer experience as they do about the quality of code they\u2019re writing. In my experience, Product Engineers are the best kind of engineers because they\u2019re always looking to better understand the customer\u2019s context around the work they\u2019re doing\u2014and hence solve the problem better.\n\nProxying, 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.\n\nHere are some best practices to enable close connections to customers in your organization.\n\n1. Establish an on-call program\n\nAt any given time, one or more engineers from Inflection\u2019s engineering team are on call. They do not pick up stories from their backlog \u2014 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.\n\nAction: Establish an on-call program if you do not already have one.\n\n2. Role model customer empathy\n\nTeams 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\u2019s important to take actions that you want the rest of the team to mirror. How do you model customer empathy? You and your organization\u2019s leaders need to talk to customers, too. At Inflection, we invite customers to attend our executive meetings and share their feedback directly with us. \n\nAction: Have executives role model customer empathy. The rest of the organization will follow suit.\n\n3. Make the back office glamorous\n\nMost often, your product organization\u2019s attention is focused on developing customer-facing software, and so that\u2019s 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.\n\nAction: Move your best engineers to the back-office engineering team. Enable them to build experiences that allow Customer Support to delight customers.\n\n4. Give room for engineers to innovate\n\nMost 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 \u2018ShipIt!\u2019.\n\nThe following rules apply to ShipIt!\n\nThe results from ShipIt! are amazing. Teams deliver innovative solutions in a compressed time frame, often addressing long-standing customer problems.\n\n5. Establish a customer benefits framework\n\nWhat KPIs do you see on your Executive dashboard? They likely include metrics around customer acquisition, revenue, and employee retention, but there\u2019s one key performance indicator you might be missing. Customer Benefits. Are you measuring the value of what you do from a customer\u2019s lens?\n\nThis 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 \u2018faster shipping\u2019 customer benefit. I heard an anecdote from an ex-Amazon employee that an executive proposed a way of grouping customer purchases to reduce Amazon\u2019s shipping costs. The idea was shot down because it went against the company\u2019s \u2018faster shipping\u2019 customer benefit. Having customer benefits metrics on your dashboard enables all employees\u2014including engineers\u2014to keep customer outcomes front and center of all they do.\n\nAction: Implementing a Customer Benefits framework helps ensure that leaders are thinking about the customers in all they do.\n\n6. Know your customer\n\nTeams within an organization often confuse customers and partners. If you ask your platform engineering team who their customer is\u2014who the end-user of their product is\u2014invariably the answer will be \u2018the product engineering team.\u2019 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\u2014they are each other\u2019s partners; they\u2019re working together to deliver the customer benefit.\n\nAction: Help your teams understand who the customer is, and who they\u2019re partnering with to deliver excellent customer benefits. Do not confuse the two.\n\nReducing the gap between customers and engineering teams will result in more valuable engineers\u2014and 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.