What really caused that bug? with Doug Suvalle of Glassbox Digital

Transcript

Ledge: Doug, thanks for joining us.

Doug: Thank you, David. It’s a pleasure to be here. Thank you.

Ledge: Great to have you. Could you give a two or three minute background of yourself and you work, and the interesting things that you guys are doing?

Doug: Sure. I work at Glassbox Digital, and I was one of their first sales people – enterprise sales people.

Glassbox specifically captures and records every single session, digital session, of someone going to a website, someone going to a mobile app, or even internal web based applications and down to instant replay.

So, it’s like you’re looking behind the person as they’re going through the experience. Everybody knows, today, that customer experience really sits at the heart of the what the business stakeholders care about, but what they don’t understand is how difficult it is to get insight from the data that’s being ingested on a regular basis. Which is really why I’m interested in speaking to your audience who comes from that technical background.

A DevOps background. Someone who’s in there, seen the errors as they happen but having difficulty in the way of translating what the impact those errors are having on the business, and thus justifying the importance of their role.

Ledge: That’s a really good point. I’d love to delve into that. You could stare all day long at a console with complicated errors that are happening from your production environment, trying to chase those things down. But really understanding which of those have an impact on the end customer, that’s some really good insights.

Talk about what you guys are enabling in that space, and how you’re thinking about that business stakeholder. Also, the customer empathy that comes up through engineering as a result of that greater visibility.

Doug: For sure. I think your audience is very familiar with tools like Dynatrace and AppDynamics and Splunk and Sumo. These are APM tools, Application Performance Monitoring tools, that DevOps people are seeing errors as they’re happening.

There’s an importance, from a business perspective, to tie in the client side view. What the client is going through. The behavior that they’re doing to the errors that are happening, because they don’t know if these errors are being caused necessarily by infrastructure, or they’re being caused by the fact that the customer just doesn’t understand what they’re supposed to be doing on the site.

See, the thing is, brand and customer and experience are really the driver these days. It’s not price anymore because supply chain has really commoditized most of the materials out there. So, really being able to understand the customer’s experience in real time.

Having the reports and analytics that help understand why something happened is much more important to have it real time than what these other tools and the processes that some of your audience has to go through to translate that into business value.

Glassbox is taking literally a video of everything that’s going on, along with supplying the analytics and data that’s coming from these other toolsets. Does that make sense?

Ledge: Yes. When you talk about the visualization and the video, is that a literal experience? That you can actually watch the clicks and such? How does that work?

Doug: Absolutely. Grab the popcorn. If you have a remote control in front of you and Glassbox will show you a video of every single session. Every single time someone came through.

Now, these companies have billions of sessions so we only want to look at the ones that are the most important. Well, your DevOps teams are finding where those errors are, and we can correlate those automatically within our application and basically go like this, “I found an error.” “Okay. Let’s view the session. Look back at the video and see where was the problem.”

It’s not just the video, it’s actually a data trail that shows and pinpoints and bubbles up insight. We not just a session-recording platform, we’re actually an automatic insight platform.

But again, we’re just handling it from certain angles where we know these other tools are picking up way more information and they want to see this investigation. We’re giving them visual representation.

Ledge: Right. So, this could be really helpful to avoid the scenario where you say, “I know there was a bug on the site. I know something crashed. But I don’t know the steps that someone took to create that situation.”

You can actually go and find that without trying to get the user to talk to you about that?

Doug: Yeah. We can even go real world examples. How about the designer who designed this great web page for the iOS application, say for a cruise ship, and wanted to give a promotion to upgrade people to first class and then they were wondering why they got zero dollars revenue.

Well, no errors were taking place. They didn’t really understand. But when they looked in visual replay, what they found was they had only deployed the application on Android and, because of that, the preview of iOS kept the submit or promo button away from the viewership. So they didn’t even know the promo existed.

So, these are problems that are from the client side that also my impact revenue and business side, that aren’t even touching really the infrastructure side.

Other more infrastructure related, DevOps related situations are, a big bank had a payment issue where every time somebody went on the mobile app and tried to submit a payment, they were having a huge problem where those payments wouldn’t be submitted and there was a call to call center.

When you called the call center after trying to do something digitally, that’s a much higher cost to the bank. But what they eventually found out through replay is that a chat window, when brought up in support, would get stuck over the ‘submit payment’ window but yet no one really had the wherewithal to describe that completely to the contact center agent and go through all the different channels to eventually get up to the point where they could change it.

So, we showed them on visual replay. Within a week and eight/nine months of manual payments at a giant bank, hundreds of millions of dollars in a week, that problem got solved.

Ledge: I talk a lot with technical leaders about the convergence of the product mindset in leadership and the engineering mindset in leadership.

Do you find that the customers of the toolset that you guys have, are they thinking in that way as well? I’m thinking from the end engineer who is actually developing that software. Do you have to deal with the organizational flow of how the replay and the information flows all the way down to the person that can actually fix it? Are customers ready for that level of information autonomy?

Doug: Great question, in fact. One of the key problems that you just highlighted in almost every large company is the data silos. Every organization is very large, very bloated and they bought other companies. They have people that are not talking to each other that are doing some of the same things.

What happens is, is they have their own budgets and they have their own tools. Each one of them has their own way of trying to find information, and it’s very not what we call self-service.

What Glassbox tries to provide is an interface that is more self-service. A business user can go into our tool, find replays. A technical engineer can go into our tool and find the data that served up that experience. A big data scientist could take the data within our tool that’s captured automatically, and in real time fill their Hadoop environment, fill their big data platform with digital data that’s happening on a real time basis.

When that type of real time experience starts taking hold, that’s the value of digital transformation. That’s what we have to push from the very highest level because that’s the conversation that everybody’s having, they just don’t know how to do it.

Ledge: Right. You have an audience here of about 10,000 engineers or 20,000 engineers, depending on how we count it. I’m curious, from the business development seat, what would you tell the engineers?

You don’t usually get an audience with them and I’m curious, how can engineers and technical people make life easier for the folks who are out there drumming up the revenue that keeps us all paid?

Doug: I think, first and foremost, they need to understand what’s happened over the last five years. Which is, IT used to own a lot of the budget that pays for a lot of these tools. They had a lot of decision making capability.

Now, I’m a technical person, I like that. However, the money has moved out to the business stakeholders because they get that the data is so siloed. Each business stakeholder has to have a problem, justify the problem, show that it’s pain and show the impact of cost and performance. Basically, in short, the technical audience must work closer with the business audience and find tools that allow the business to self-serve.

You’re not going to actually lose jobs. What you’re going to do is become more reliant and more trusted advisors of how to interpret the data that’s being collected.

What you want to make sure is that you have all of your systems in place that that data collection effort is producing the highest quality of data so that you know what decisions are to be made and why, based on 100% of the data. Not based on say tag data or data. You want to understand it based on the entire traffic flow.

So that would be my message.

Ledge: Doug, last question. I like to ask all the technical leaders that I have on the show, what are your heuristics for hiring the very best engineers? What makes a senior engineer?

I’m interested in the perspective from your seat because again, just like the last question, you need to deal with these folks on a daily basis in a totally different perspective.

If you’re advising CTOs on how to perhaps hire and build engineering teams that are product and revenue thoughtful, what would you tell them? What’s missing there?

Doug: I would definitely say this. First of all, the engineers are usually the smartest people in the room, and that’s okay, we like that. But they need to understand that not everybody is necessarily operating on the same wavelength, and certainly business operates much slower than a technical mind can go.

What I would tell the audience is simply this.

The best candidates are the ones that are good cultural fit for the organizations that they’re joining. Meaning, they get along with people. They’re not hiding personalities. They’re okay being a little quirky. In fact, most people within an organization, from sales down to engineering down to training and whoever, they have quirks.

The idea is, get along with people because today there’s no room for people to have egos. Everybody’s working towards a common goal. If you’re getting in the way because of behavior, you’re really hurting your chances at becoming a real asset to a company.

Ledge: Great insights. Really appreciate that. Normally we get them all from the engineering seat, so it’s really good to hear the cultural angle, which is a big answer to that question, really is noticed and extends to other areas of the business, particularly in the revenue function.

Doug, thanks for joining us today. Really good to have you.

Doug: Thank you very much. Appreciate it.