Last week I had the opportunity to attend a couple of exciting events: Velocity Santa Clara and DevOps Days Silicon Valley. Although we’re already a couple months into event season, it was the first DevOps conference I’ve been to this year.

velocity-logo
logo

As a Customer Success Manager, industry events are a unique experience. I’m not compensated on the number of leads I generate. And while I’m technically savvy enough to carry in-depth conversations about our product, I’m far from an engineer. I don’t know the parameters our API passes off the top of my head, nor do I know how to write a Hubot script to reboot a server.

So if I’m not generating leads or fielding technical questions, what AM I doing at the booth? I’m asking attendees questions about their on-call software experiences and, more importantly, listening to their responses. Not only is this type of interaction a rarity in our age of digital distraction, but it’s a pillar of our customer success model.

Managing customer relationships is not a new business concept. Where our customer success philosophy differs from others is that we focus on the development of that relationship throughout our customer’s lifecycle. Our goal is to become a trusted advisor to each customer, partnering with them and contributing toward their success.

Screen Shot 2016-07-06 at 3.13.49 PM

How exactly is that achieved?

It’s not easy. The road to becoming a customer’s trusted advisor requires more than an elevator pitch. It involves listening to each customer and advocating for their needs, relaying their feedback to product development teams and being the voice of our users within VictorOps.

To do so, you have to be curious. You have to ask questions. You have to listen.

When I’m talking to people on the road I’m interested in how your on-call team is structured. I’m interested in how the on-call process works in your organization today and what specific areas you feel could be improved. I’m interested in not only how you are alerted, but how you resolve incidents. And of course, I’m interested in how much on-call sucks.

Are you leveraging minimal viable runbooks? How do you collaborate with your team while triaging an incident? Do you have formal retrospectives and how do you apply those lessons toward improving the process going forward?

Because an elevator pitch–no matter how great–gets old after repeating it 1,000 times, and DevOps professionals hear enough of them anyway. But meeting new folks in our industry and fielding all manner of questions about VictorOps was a great experience.

Screen Shot 2016-07-06 at 3.18.51 PM

A few things I discovered from my time on the road…

• Improving the on-call process can be as easy as changing the day that weekly on-call hand offs occur. On-call is less scary for new on-call professionals when it happens mid-week as opposed to on a Friday at 5pm. Going on-call right as the weekend begins amplifies the feeling of being isolated while on-call.

• Requiring documentation for how to fix new code when it breaks, before deployment and in a standardized format, builds trust and gives peace of mind to whomever is on-call. That way the on-call team has a starting point when an issue occurs for code they didn’t write, but have to support and monitor.

• It’s important to create a culture where it’s okay to reach out a teammate when you need help. Even if it’s in the middle of the night. If you fear asking for help, then it’s going to be that much harder to solve a problem you haven’t seen before.

• Having great documentation isn’t enough. It’s what you do with that great documentation that matters. Writing scripts and logic to automate runbooks decreases MTTR and mitigates risk for all on-call professionals, from noobs to seasoned veterans.

• Eliminate pages for unactionable alerts. If you can’t take action on an alert, why be paged for it? This creates alert fatigue and makes the on-call job that much harder.

Attending events this summer? Swing by the VictorOps booth and let’s chat about your on-call experience.