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.
