Two Reasons Customer Service is Key to Enterprise DevOps

“Your customer doesn’t care how much you know until they know how much you care.” -Damon Richards

Customer service is, as I outlined in my introduction to this DevOps series, one of three tenets I encourage organizations to consider when implementing a DevOps culture.

Today’s world is full of technology solutions. There are a myriad of options available to all of us to meet just about any need. For those of us delivering technology solutions, doing good business means not just delivering a great product, but also delivering great customer service. The better the customer service, the less likely your customers will seek solutions from your competitors.

In the most traditional sense, customers are the people who buy your products and services, like the shoppers on Amazon.com, or the enterprises using AWS.

Inside of enterprise IT, your customer is often someone you work with. An internal stakeholder could be anyone in the organization relying on various technologies to get their jobs done. Sometimes they are in another department (marketing, sales, etc.) and sometimes they are other technologists.

Who consumes the products and services of an internal DevOps organization? Of course the answer will depend, but often they will be the application developers and other technology teams in the company, since faster product development is often a key motivator for implementing centralized DevOps in the first place. A centralized team that collaborates and listens across departments will be able to better anticipate needs and deliver better customer service than one that is solely concerned about the challenges they face in isolation.

There are at least two reasons to keep customer service at the forefront of your organization:

1. Customer-service-centricity improves the IT brand

Twenty years ago, enterprise technology needs were served exclusively by IT. Technology was thought of as complicated. It was something that required a great deal of expertise to do well. Unlike a DevOps culture where teams run what they build, organizations were biased toward centralizing IT into the hands of the few that understood how to procure and deploy it. This left IT’s customers — the rest of the organization — little choice on where to go to get their IT needs met.

Today, however, there are so many more products and solutions that solve your customers’ problems. Technology continues to become more consumerized. More people are using computers, smartphones, websites, apps, than ever before, and they have more choices at home and at work. This trend is changing the way technology leaders need to think about customer service — particularly within their own organizations.

My experience has taught me that when someone finds an easier way to execute a task, they’ll likely take it. If they aren’t getting the service they need from IT, they’ll try to find that service elsewhere. The newsroom might download editing software because IT can’t or won’t deliver its own version fast enough. HR may look for a scheduling tool outside the internal calendaring environment. Marketing may go to a third party to have the brand’s website redone. The industry knows this as “Shadow IT,” which can make it much more difficult to effectively manage and secure a large IT environment. The reality, however, is that Shadow IT exists because internal stakeholders are simply not satisfied or don’t know how to get what they want from IT.

A centralized DevOps organization that remains customer-service-centric has a much better chance of avoiding these scenarios. When you’re thinking about your customer from the very beginning, you will be able to empathize with their needs and concerns from the start, and determining how solutions to those needs fit into the overall company. Instead of saying “you can’t use that to do your job,” ask “what are you trying to accomplish and how can I help you be more effective?” Every time an app team implements a workaround for something the DevOps team can’t deliver, there’s an opportunity for the organization to learn how and why that happened, and decide if they should do things differently moving forward. Is there something they can do to alleviate the need for a workaround in the future? The answer may very well be “no”, and in many cases it will be ok to accept a workaround, but I encourage organizations to be deliberate about it. This is one of the ways IT can become an enabler rather than a point of friction. It is the kind of collaboration that incentivizes customers to work with you and not around you.

2. Customer-service-centricity is good for your career

In a DevOps model, where application teams run what they build, ownership and customer service go hand in hand. I’ve been fortunate enough to have ownership as a key performance indicator at every company I’ve worked for. It was one of Bloomberg’s core values, we made it one for IT at Dow Jones, and it’s one of Amazon’s leadership principles.

Ownership simply means that any individual responsible for a product or service should treat that product or service as his or her own business. Products and services can take any number of forms: a website, a mobile application, the company’s e-mail service, desktop support, a security tool, a CMS, or anything that you deliver to your customer.

Ownership creates better customer service because it places responsibility and reputation directly on the shoulders of the person overseeing the product. This person, in turn, will be motivated to listen to others, be aware of the customer’s alternatives, and constantly keep insights into how the product is performing. Someone in charge of the product can’t simply “pass the buck” when a problem occurs. They are accountable to see issues through to their resolution, and get help when they need it.

Individual careers will benefit here: Anyone willing to own a product and cultivate a healthy customer relationship will gain a reputation around the company for being reliable, trustworthy, and dependable.

These are just two reasons that customer service is so important inside of a large and complicated organizations, and especially important when considering DevOps. I’d love to hear about others that you’ve come across.

Keep building,
–Stephen
@stephenorban
orbans@amazon.com