The key to having impact as an engineer? Empathy

As product engineers, we like to build things, we like to solve problems, and we also want to have impact, right?

But in order to have maximum impact, you need to build things that solve the right problems. How do we do that? By cultivating a deep sense of empathy for our customers.

At our event Building Intercom in Dublin, I discussed how this empathetic approach can play out even on a small scale, using the example of a seemingly simple feature I was working on.

Introducing Snooze

It all began with a small feature in our Inbox, which looks like this:

Customers write in and this opens a conversation with a customer support agent. Over time, the number of Intercom customers increased exponentially, and with this came an increase in the number of incoming conversations. So there was a lot going on in the Inbox, and our customer support agents were constantly under pressure.

To get conversations out of the way, they just closed them when a customer didn’t respond. But this behavior was screwing things like reports on who was resolving the most customer issues.

At that time, a conversation could be in two states – it could either be open or it could be closed. And not having a third state was really blocking us on other major features that we were working on at the time. So we started designing a new state that would allow our customers to put conversations on hold, and we called that state Snooze.

Managing legacy systems

We all know that when you are dealing with a legacy system, there’s a bit of work involved under the hood to add a new feature, especially when it affects one of the core parts of our product, in this case conversations. We needed to:

1. Update and extend our conversations database table and do this without disrupting existing behavior for our customers or making the life of our infrastructure engineers miserable.
2. Keep the UI consistent. We all know how great it feels to have the same behavior on mobile as on web.
3. Make sure that everything is backwards compatible, because we cannot just change our API for every new feature we’re adding.

So we navigated these challenges, and we quickly shipped Snooze so we could unblock our other work. I was proud and happy about the elegance of the solution. I couldn’t wait to see it in action. But of course, it turned out that people didn’t use Snooze the way we thought they would.

The black hole of Snooze

It turned out that the customer support agents that managed the inbox were constantly snoozing their conversations, and this resulted in a large backlog of snoozed conversations. And given the way we had built this feature, conversations never reopened if nobody replied.

From an engineer’s point of view, my work was done, right? I mean, I shipped what I was asked to build. It worked as it was supposed to. But in effect, all we had done was copy the previous state of closed. Our analysts termed this the “black hole of Snooze”.

In effect, we had actually created a new problem, and let me tell you, it’s really shit knowing that the thing you’re building doesn’t actually solve a problem. In this case, it felt even worse because it created a new problem. And for someone like me who likes to build things to have a positive impact, that felt like a real kick in the guts.

“We needed to go from just building things to actually solving the right problem”

I had to go into my cave and do some reflection time. And I realized one thing. I realized we had built this feature in isolation and with the wrong motivation. We were so busy and focused on wanting to unplug other Intercom features that we just completely forgot what problem we were looking at and why we were building it. We lacked context around the interaction between the people in the inbox and their customers when we added this new state. So we needed to go from just building things to actually solving the right problem in order to have the impact we needed.

Empathy engineering

Okay, that makes sense, but how do I as an engineer make sure that this time around I’m not just blindly building things again? Actually, Tom Kelley from the Californian design company IDEO has something to say about that: “Empathy means challenging your preconceived ideas and setting aside your sense of what you think is true in order to learn what is actually true.” That’s exactly what we were missing. Having empathy for the users of our product, in this case people managing the Inbox, is what we were missing.

How, then, do I go about challenging my preconceived notions? As a first step, I sat down with our Customer Success team and literally looked over their shoulder as I checked how they use Snooze to find out what works and what doesn’t work when they have a large backlog of snoozed conversations. Then, I gathered every bit of feedback there was from customers to really understand their pain point. And lastly, we as engineers got together with designers, analysts, researchers and PMs, and we did a post-mortem of our first solution and discussed solutions and ideas for the next iteration.

We decided that we always had to force a snoozed conversation to reopen, and we added a scheduled job that would check when a conversation needs to be reopened. This conversation would then be put on an SQS queue and workers would take this conversation from the queue and would change its state.

And it’s so obvious, right? A lot of you will say, “Yes, Serena. Like, of course!” We were so focused on unblocking future work that we didn’t take some time to really consider how Snooze should function. And of course, this time around, it worked.

You need empathy to have maximum impact

So let me get back to the question at the beginning of the talk. How do we have maximum impact as engineers? We need to build things with real people in mind in order to solve the right problem. And the key to this is empathy.

Why you’re solving a problem is more important than how. Neither versions of Snooze we were building were flawed from a technical level, but that’s actually not the point. In the end, we spent weeks building a technically great solution that was wrong for our users, instead of building a solution that was right for our users.

“When you build product, you always create new contexts and new ways for people to relate each other”

We could have saved a lot of time by just trying to understand better the interaction between people that manage the Inbox and their customers. When you build product, you always create new contexts and new ways for people to relate to each other, and we as product engineers need to be mindful of this. So my closing message is, don’t hit snooze on the empathy button.