In this DevOps Chat we speak with Jim Gochee, Chief Product Officer, New Relic. In his role at New Relic, Jim has seen years and years of evolution in digital transformations. Jim and I spoke about a number of topics including about how to succeed with DevOps, the rise of SRE and APM. Great discussion all around.
As usual, the streaming audio of our conversation is below, the transcript follows that. Enjoy.
 Audio
Transcript
Jim is New Relic’s Chief Product Officer, overseeing the teams that design, build, and deliver New Relic’s products. He has a passion for building world-class products and loves technology – especially when it’s well architected, scalable, and fast. He takes great pleasure in helping New Relic’s customers analyze their technology and build great digital experiences. Prior to New Relic, Jim was the Chief Architect for the Wily Technology division of CA, where he was the technical lead for Introscope, an industry-leading web application performance monitoring solution. Prior to that, he was Chief Technology Officer for an internet-based trading system for the wholesale food industry. Jim also spent four years at Apple, Inc. and three years at Connectix Corporation working on VirtualPC. He holds an A.B. in Computer Science from Dartmouth College.
Jim Gochee: Hey, Alan, how are you?  It’s good to be here.
Shimel: Thank you, it’s good to have you here.  So, Jim, let’s get some stuff out of the way here, a little housekeeping.  What exactly is your role at new relic?
Gochee: Yeah, Alan, so I oversee all of product development and that includes engineering, product management, design as well as operations. Â So pretty much the whole shooting match.
Shimel: Fantastic. And Jim, I was talking to you off-mic before we started today, we haven’t done a good job frankly of covering New Relic at DevOps.com but when we first launched, which is going on five years ago, New Relic was already a well-established player in the DevOps market and is certainly even more established now.
But why don’t you give our audience maybe just a quick little history to bring us up to where New Relic is today.
Gochee: Yeah, absolutely.  We’ve been around actually for ten years, Alan. So we just had our tenth-year anniversary party just a couple of weeks ago if you can believe that. So, 2008, and when we started, we were focused on Ribyon Rails, monitoring the backend services, grew the product portfolio over time to include other languages.
But mostly sold to small companies, startups, companies that got bigger like Air B&B. But really, it was a couple years ago we started to pivot more into the enterprise and that was a very exciting time for us.
We were already getting pulled into bigger and bigger companies at a project level and then we found ourselves being kind of drawn in organically to more and more groups to the point where these big companies were wanting to have more of a formal relationship with us, from a sales perspective.
So we built out an enterprise sales team and have been really focused there. So maybe, in one way, while you haven’t seen a lot of us in the last couple of years as we’ve been pretty heads down, focusing on the needs of the enterprise market. But what I’ll also say is we’ve been releasing a lot of product as well in the last a couple of years and the biggest thing that we did is we rounded out our offering to include an infrastructure monitoring component.
And that really complicates, not complicates, but it complements our offering at the application layer as well as the end user layer. So at this point, we have a pretty comprehensive portfolio of offerings that cover that full stack.
Shimel: Very cool, very cool indeed. So Jim, I would imagine in your role around product and everything you’re doing at New Relic, you get to talk to more than a few customers, yeah?
Gochee: Well, I do and I just feel so blessed, Alan, because this is an incredible time to be in technology. So I’ve seen a few really interesting times in tech. I think the first was when the Internet really started to get mainstream, back in the mid-’90s, but what’s really interesting now is this thing that you hear a lot about which is digital transformation.
And we all feel it, which is we want a relationship with the companies that we do business with, we want a relationship via our mobile phones or the web browser. And so a lot of companies are trying to figure out how do they have that new customer relationship, right? And how do they come up with new ways of engaging with their customer?
And then, of course, again, companies like Air B&B completely rethinking business models, companies like Uber, and so it’s just a really fascinating time to be in the tooling space that supports and assists a lot of these digital transformations that are going on. So, yeah, we definitely see a lot of interesting things.
Shimel: Excellent. So, Jim, one of the themes that we have run into here recently at DevOps.com is this idea that somehow people thought digital transformation and DevOps transformation was gonna be easy. And they’re a little bit taken aback.
You know, you speak to them, the first kind of foray into it it’s like, you know, this is hard. And I feel like saying no one promised you a rose garden, right?  If it was that easy everyone would be doing it already. Are you seeing any of that?
Gochee: Well, you know, Alan, in fact, we do see a lot of that but I would say is this, I guess I see the full continuum. I see the early adopters and the enterprise to DevOps. I mean, DevOps, you guys have been around for five years and we’ve been doing it for 10 and it’s early to do when you start a company that way.
In other words, when you start a company and you have a DevOps organization already, it’s easy to grow and keep doing that. But when you’re a traditional enterprise and your operations team is very siloed from your development teams, to bring those two together is a pretty big task, right? And you hear a lot about the cultural challenge involved, and that’s very real.
The thing I’d like to ask, the question I ask when I go into one of our customers and I’m not familiar yet with really where they’re at in the journey, I ask them one simple question. Who takes pager call? And if it’s still the operations team that’s taking pager call, then normally they’re still complaining that the developers don’t care, the developers are very isolated, and you see those silos still in place.
And it’s really not until a development team, then with the help of operations, people like SREs embedded on that team, it’s really not until that happens where I would really see the crossing of the chasm into more of a true DevOps model.
Shimel: Absolutely. You know, you mentioned SREs, Jim, and that’s another area where we’re just seeing it, man, it’s blowing up, right, in terms of companies hiring SREs, incorporating SREs on to their ops team. Many people have gone as far to say SRE puts the ops in DevOps. What are your feelings around the SREs and that?
Gochee: Well, what I like about the SRE role is Google wrote a book about what they believe it is. And so while that probably just applies to Google and nothing’s ever as perfect as it seems, they clearly define these are the things that this role does.
And this is why these things are important, and it’s a real philosophy and it’s a real mindset, and they wrote it down and these are all things that other people had been doing in various ways. But I think the SRE role, it got really clarified what exactly it is.
And so I am starting to see this more and more as well, and it’s not like SRE is a new concept; again, Google’s been doing it for a very, very a long time but I just feel like it’s kind of catching on.
I can tell you ourselves we’ve been doing DevOps for a long time but just in the last year, we’ve really formalized around SREs as well and we got a vice president of site reliability engineering, we converted people’s titles over, we got really crisp about exactly what are you doing.
We’re trying to figure out right now whether central versus embedded or a hybrid of the two approaches, so you know, how to organize SREs and how do they really attach into development teams? There’s still plenty of work to do even that we’re looking at, but I think this is helping the industry really figure out a model that they can work with.
Because that’s the biggest thing I see, Alan, is people want to transform to be more agile into DevOps and to use the Cloud, but they don’t really know how to do it, right? They don’t really have a good playbook for it yet.
Shimel: I agree with you 100 percent. It’s interesting you guys are eating your own dog food with that.
So, Jim, in many ways, New Relic, sort of, if you will, pioneered what we call APM, you know, and we recently did—it got too big but it was a DevOps tools primer, just trying to at least draw it so that the taxonomy of categories—and certainly APM, but APM itself has become so intertangled in this whole software development life cycle. Is that still where New Relics thinks they play?
Gochee: Yeah, so it’s a great question. We like to say that we’ve democratized APM; in that, we created a service that anybody could subscribe to, download our agent, install it into an application code, relaunch your application and now you’ve got your data showing up on our screens.
The technology around APM, though, has been around a lot longer but we were the first to bring it to everybody in a very transparent selling model, right, and again try it before you buy it. And we have by far, in a way, the most users in this APM category. These categories are funny things though, yeah, applications here but there’s also end user, there’s synthetics, now there’s infrastructure tier.
It’s all kind of collapsing and probably the markets sort of get renamed after a while. One of the things that we like to say that we think we have is a digital intelligence platform, digital intelligence just means data about everything that’s part of your digital system, all the code running, all the infrastructure that’s running.
And so at the end of the day, if you want to be agile and deploy a lot code and make a lot production change, you need to have data that tells you that things are still working correctly about all the different pieces of your infrastructure, right?
And without that data, you’re flying blind and so, flying blind, it’s okay if you deploy code once every six months, you can fly blind for a little bit while you sort out any issues. But if you’re deploying code every day, you’ve got to have real-time data about what’s happening in order for that to be successful.
Shimel: Sure do, sure do. And Jim, when we talk about the move to the enterprise, I think that’s one of—not that startups or non-enterprise customers don’t use data or that they do fly blind. They don’t. That’s not the case at all. But when you go to the enterprise and you start thinking about enterprise-class functionality, right, is when you start realizing what—really, things have got to be locked down, right?
There’s got to be sort of—I mean, sometimes it can be overprocessed and overcomplicated but you can’t just fly by the seat of your pants as much. And I think products like New Relic, they can’t help but bring some of that regimentation to a company.
Gochee: Absolutely, no, I mean your point’s really well-taken. When you’re a smaller company, you can take more risk, you don’t have to do things the right way, you know. That’s common. When you’re bigger company, you have a lot more experienced people who are used to having better tooling, better processes, better governance, right?
Because there’s a lot at stake. I mean, these are some of the largest companies in the world who are betting their future on their digital projects, and those projects have to function and they have to work. So, I don’t know, can I tell you one story, Alan?
Shimel: Sure.
Gochee: It’s a few years old now but do you remember when healthcare.gov first launched?
Shimel: Yes, I do.
Gochee: It first launched and the thing didn’t really work. It was hung and broken and the president was like apologizing to the nation, right? This is an example of we looked at each other and we’re like this is the highest-profile example of a web project gone awry.
Shimel: [Laughs]
Gochee: Yeah, right, I mean the president has to apologize for poor web performance and –
Shimel: At least we had a president who apologized then, but go ahead.
Gochee: That’s another story altogether.
Shimel: That’s a whole other story.
Gochee: The president brought in a team from Silicon Valley to help fix that site. I forget Mikey’s last name from Google. Anyways, they brought New Relic in and then we gave them the data to help sort that out, and then from now on, we have been the tool of record for how that system has been performing. And they’re just 1 of 15,000 customers that we have.
Shimel: Interesting.  But that’s a classic example of it, too. That was done probably, frankly, without the necessary requirements in laying it all out there. Jim, let me ask you a question. From your catbird seat, what do you see at the future of the market here?
Gochee: Yeah, so just in terms of digital transformation and digital customer experience, that’s absolutely gonna be powering the whole economy and tech sector in particular for the next five to ten years. Cloud, the move to Cloud, the opportunities you can get by some of the Cloud services.
In particular, Amazon is really blazing the trail in just the sheer number of services they offer the market, changing how people can build and deploy software, it’s incredible. So we see a continued explosion in software and digital experiences, and then that drives companies like us, we offer tooling in this area that really helps companies move more quickly, have a better customer experience. And so I mean, I think the whole category of tech and DevOps and Agile and tooling, observability is a trend, SREs, all of this is gonna continue to have a lot of strength and a lot growing over the next five or ten years. I just absolutely believe that.
Shimel: Excellent, Jim, as I mentioned to you, when we first got started here, 15 minutes goes really quick. I think we’re probably closer to 20 at this point but it’s okay. Maybe we can have you back on here at New Relic and a DevOps chat because we would like to stay on board with everything that’s going on there. But in the meantime, thanks for being a guest on this episode of DevOps chat, Jim.
Gochee: Alan, it’s been enjoyable, thank you so much for having me. I’m happy to come back on as wellÂ
Shimel: Absolutely, we’ll make you a regular. Hey, that was Jim Gochee, Jim runs products and a bunch of other things over at New Relic and this was another episode of DevOps Chat. This is Alan Shimel for DevOps.com. I hope to see you soon on another chat soon, everyone. Take care.
— Alan Shimel
