What User Empathy Means at Google Today

It’s said we can all stand to make improvements when it comes to empathy. In software engineering, empathy is required to create something that the end user can easily figure out; it’s unacceptable to build something you think is great but expect customers to figure it out on their own, just because you think they should.  Search engine giant, cloud services leader and Kubernetes creator, Google, realizes this.

In this latest episode of The New Stack Makers podcast, Alex Williams, The New Stack founder and publisher, and Darryl Taft, TNS news editor, sit down with Google’s Kim Bannerman, program manager for Empathetic Engineering, and Kelsey Hightower, principal developer advocate, Google Cloud Platform (GCP), to discuss Google’s Customer Empathy Program and end-user satisfaction.

What User Empathy Means at Google Today 

Google’s Customer Empathy Program program will be part of the process for all engineering onboarding for “Nooglers” (someone who has just joined Google) next year. “If someone starts at Google, they’re going to get through an empathetic engineering session, as well as learn what it is and what it’s not and the patterns and the non-patterns — and that’s huge for us,” Bannerman said. “That’s something that we really wanted to do across the board, because you can’t really have great engineering and great products for your customers unless you can have the folks that are building those products understand them, truly, and it’s all about walking in their shoes.”

Empathy is not just about emotional intelligence, Bannerman said. “A lot of people talk about emotional intelligence, but they don’t really know what it is and even the types of empathy that come into play. You can have cognitive empathy, which is to take into perspective on an intellectual level, and compassionate empathy, which is feeling with someone and taking supportive action if needed,” Bannerman said. “But until you physically feel what someone else is feeling, you’re not going to have the full cycle of empathy unless you go through all three pieces of empathy.”

DevOps itself could very well be a product of empathy, Hightower noted. Just prior to Docker, there was a push to automate infrastructure, “in many ways with the wrong abstractions, or no abstractions,” Hightower said. “You had people trying to automate everything, and the container community was saying that you’re automating the wrong thing. Instead of talking about Ruby, Python, Java and all the programming languages as independent problems to solve, Docker takes a holistic approach and says, ‘let’s just abstract away the concept of an application into a package, a universal package,’ ” Hightower said. “I think ops drove a lot of the configuration management world, but I think developers drove the containerization and distributed systems movement. When those two worlds came together, it wasn’t very clear how you use them together.”

Kubernetes can be seen as a way to bridge this gap because it “layers” on top of both of those concepts, Hightower went on. “Kubernetes brings this configuration language to this container landscape. So even though most people talk about Kubernetes as a container orchestration tool, it brings that declarative approach to infrastructure to the world of containers,” Hightower said. “I think that’s when we start to see these two communities start to merge, but then that leaves a lot of room for empathy, to make sure that both communities understand where each is coming from so we get all of the value.”