New Relic’s Mark Weitzel on creating open developer communities

With more and more businesses going digital, developers are gaining an increasingly important seat at the table.

https://art19.com/shows/inside-intercom/episodes/f7784899-ab06-4789-9a0c-3731963bb7d2

So what’s the key to having happy developers? A joyful, transparent development experience.

As we keep building out our own platform so teams can customize Intercom for their own needs, we’ve loved getting to know the great group of developers and partners building apps for our customers and for themselves.

I head up platform partnerships here at Intercom so every day I’m thinking about ways we can support those developers and make it as easy as possible for them to build useful and valuable apps quickly. That’s why I invited Mark Weitzel, GM of New Relic One, to join me on the show.

A lot of companies, including us at Intercom, use New Relic to monitor their backend systems. And I’ve long admired the extensibility of their platform and the strong developer community that Mark and his team have built up. In our conversation, we talked about what it takes to start a developer program from the ground up and the strategies that have helped New Relic create a true community experience for their partners, developers, and customers. Mark’s got some great advice for anyone working on partnerships and DevRel strategies.

Short on time? Here are five quick takeaways:

  1. By 2022, half of the global economy is going to be digital – and more and more companies will become software companies. Developers are key to making this transformation happen.
  2. When launching a developer program for your product, you absolutely must have clear objectives and executive buy-in. A developer program is a long-term investment that you’re betting your business on. It’s a representation of your brand.
  3. New Relic believes that every developer is created equal. That’s why they’re striving to be a more open company that’s contributing to open source, consuming open source and engaging in open standards.
  4. To create a developer community around your platform, first invest in providing great tools and processes that enable developers to extend your platform. Advocacy and evangelism are also important.
  5. To survive in this world, companies have to change the way they think. You’ve got to play offense with software, and you have to think about the things your developers create as strategic assets that give you a competitive advantage.

If you enjoy our conversation, check out more episodes of our podcast. You can subscribe on iTunes, stream on Spotify or grab the RSS feed in your player of choice. What follows is a lightly edited transcript of the episode.


Jeff: Welcome to the show, Mark. You have been working a long time in platform, so we are really excited to hear all your experience here today. I’d love to hear a little bit about how your career grew over time, and how you ended up at New Relic.

Mark: My journey to New Relic really started here in North Carolina when I started working for IBM a number of years ago. I had the opportunity to start and lead an open-source project at the Eclipse Foundation, interestingly enough, around systems management. It was there that I really discovered this passion and this joy of working transparently and openly with developers.

That led to working also at IBM, where I was leading the OpenSocial Foundation. We were looking at really interesting web-based technologies that were emerging in the consumer space that would apply to the enterprise. I met a lot of the team at Jive, and found out that they were doing some really interesting work around unlocking the power of collaboration, and your enterprise social graph. They were building an ecosystem of applications and needed to build an ecosystem of developers. They were doing this around OpenSocial and around the open standards space to pull in that set of developers that was used to building things in the consumer space, and I got excited about that. I joined Jive after a brief stint at Sugar doing sort of the same thing, building platforms and ecosystem.

Some of my old colleagues at Jive that were at New Relic said: “Hey, we’re accelerating our platform journey. We want to open up our platform. We’re looking for somebody who understands developers, has built a platform that’s extensible, has worked in open source and, by the way, has also built a partner ecosystem. So we’re looking for that, if you’re interested.” And of course I was. It’s been a great journey.

A changing digital economy

Jeff: That’s fantastic. We’ve used and looked up to New Relic for a long time at Intercom, so I think it’s great to get to pick your brain over this stuff. New Relic has always offered ways for developers to plug its solutions into their own apps. Principally, at least in the beginning, it was very much for monitoring applications and understanding what’s happening in your production environment. How has that changed over time, and how have you guys accelerated that opening of the platform?

Mark: For more than 10 years now, the portfolio has really grown as the industry’s changed. We now have mobile and synthetics and things like that in our portfolio suite. But if we step back and look at the larger trend in the industry, it’s absolutely amazing – the pace of change in our industry at this point.

IDC recently said that by 2022, half of the global economy is going to be digital. That’s incredible to think we’ve reached the point where half the economic activity in the world is going to flow through technology. This is transforming, fundamentally, every business in the world. We talk about every company being a software company. Well, that’s true. It’s incredible.

“Half the economic activity in the world is going to flow through technology. This is transforming, fundamentally, every business in the world.”

These changes are hard. Let’s think about the lift it takes for teams to migrate a traditional application – which there are hundreds, thousands of them out there still – into a microservices architecture in the cloud. It’s really hard, and teams today don’t really have to just focus on a few things in production that you need to pay attention to. It’s thousands, and for some of our larger customers, millions of things you have to pay attention to. So these environments have exploded, and with all of that complexity that we’ve introduced, those pieces have to work flawlessly together, and you’ve got to watch them. You have to know and understand it.

As Lew Cirne, our CEO, was introducing New Relic One, the industry’s first entity-centric observability platform, he talked about this tweet:

This is the complexity that’s facing our customers, and this is the problem that we’re trying to solve: helping our customers make sense of these complex environments. Opening up our platform, being more open for developers, is a key first step of that.

Jeff: It’s easy for us in tech to forget that so much of business is not technology first, or digitally native. A lot of these businesses are 100 years old or 50 years old, and they’re really having to transition these old processes and old pieces of software into cloud products that are very, very large-scale in comparison to what even some of the largest startups have built.

You mentioned there, kind of in passing, New Relic One, which promises to make New Relic completely programmable. Can you give us a little bit of insight into what it means to be completely programmable?

Mark: Sure. If we think about this, and we think about the complexity that’s happening now, these environments have changed. You have to pay attention to lots and lots of things. You’ve got your lambda functions, your containers, your hose. And you need to watch and pay attention to them in production.

As an entity-centric observability platform, New Relic One helps you make sense of the fragmented things inside of your organization. It pulls those all together, and it helps you better understand these increasingly complex, pan-enterprise, interdependent systems. It’s the tool that we believe will lay the foundation for the next decade of growth at New Relic and help our customers deliver the outstanding customer experiences that directly impact their business value.

“This is the problem that we’re trying to solve: helping our customers make sense of these complex environments”

Jeff: So it takes that step of monitoring quite a bit further: you’re not just there to monitor your systems. Because software has become every part of your business, you’re really monitoring every part of your business and how every part of your business interacts with each other.

Mark: That’s right. Looking at New Relic from a programmable standpoint, one of the things we’re doing is making it easier to collect data from multiple sources, integrate those things into your workflows, and with our programmable UI that’s going to be coming later this year, one of the things you’ll be able to do is visualize that in new and compelling ways that are tailored to your business. It’s speaking your language, if you will.

What to consider when launching a developer program

Jeff: That’s fantastic. Obviously, developers are a big part of New Relic, and over the last year, you’ve led the launch of New Relic’s developer program. For companies that are looking to start their own developer enablement program or just developer platforms, what types of things should they be considering? How would you recommend they go about thinking about that initial startup phase?

Mark: First and foremost, you have to have executive buy-in and executive support. You have to realize that a developer program isn’t a website, and a developer program isn’t a forum where people can ask questions. It’s a long term investment that you’re betting your business on. So you have to have that executive support and executive commitment, and we’re very fortunate at New Relic that we’ve got that.

“A developer program isn’t a website, and a developer program isn’t a forum where people can ask questions. It’s a long term investment that you’re betting your business on”

The other part of it is that you really need to understand your objectives, and here’s a great example: at Jive, we didn’t really have a developer ecosystem, so a big part of what we were trying to do is attract developers. In this case, it was from consumer space using OpenSocial, attracting them into the platform and taking that expertise and applying it to building applications on an enterprise social collaboration platform. At New Relic, developers are our customers, so we’re looking at how we can better provide the tools that they need, because developer acquisition in this particular case isn’t our primary goal. We want new developers, obviously. We want people to come to the platform. But developers are our customers, and we need to serve them.

Another aspect that we think of is the notion of platform readiness. You really need to be honest with yourself with where you are. You and I first met at DevRelCon in London and API the Docs in London. I went back to Cristiano Betta’s session where he did the API teardown. Everybody writes their developer portal down on a piece of paper and puts it in a hat, and he draws one out.

Jeff: It’s terrifying.

Mark: It is terrifying, right? There you see, in real time, somebody going through your first 20-minute experience. You’re seeing them interact in front of everybody what it’s like to participate in your developer program. Like you said, it’s terrifying, because you’re going to have hundreds, or if you’re lucky, thousands of Cristianos a day. So you’ve got to be ready to put your name in a hat. Your platform has to be ready, and you need to be honest with yourself with where you are in that process, in that journey.

Another aspect I like to think of is the impact to developers if you are a platform company. Developers don’t necessarily get paid to build things on your platform. They get paid to do their job, build their software and deliver it. The total cost of ownership isn’t just that they can build something really neat and cool on my platform really quickly. It’s how it gets maintained and how it evolves and grows. Your platform can’t break. Going back to that readiness statement: as you evolve, those things need to be stable and durable, and that cost of ownership has to be very low. It’s even more true if you’re dealing with independent software vendors who want to make money off your ecosystem.

“When developers come to your site, they work with your developer portal and your platform, and they’re really interacting with your brand”

Jeff: Right. You’re building a long-term relationship when you’re getting into building platforms and working with developers, and you have to look at it as such from the very beginning.

Mark: Absolutely. As part of that, it helps to establish some guiding principles. What are the important things? Because when developers come to your site, they work with your developer portal and your platform, and they’re really interacting with your brand. This is a very public representation of who you are. There are going to be lots of ways you engage: conferences, speaking at domain-specific events like DevOpDays, open-source code that you contribute as a set of examples, workshops that you do. You’re instilling and representing your brand in a way that’s unique to a very distinct audience and developers.

Creating developer-focused guiding principles

Mark: At New Relic, we try to establish a set of guiding principles, because so many people – so many teams – interact with our customers. The first one we laid out was this notion of all developers being equal. All developers are created equal. That’s the idea that you create a platform, and whether you’re a New Relic employee or a customer or a developer at a partner, you’re using the same tools. You’re using the same APIs. There’s this notion of equality across the platform.

Jeff: So you guys advocate really for having your internal teams dogfooding, using those APIs to build everything they build for your own internal product.

Mark: Yeah, absolutely. That’s our goal. This is a guiding principle, and let’s be honest with each other: sometimes these are tough to adhere to. Making software isn’t always pretty. But if you establish that principle, it starts to establish a discipline of separating out the platform, which gives you the ability to adhere to API contracts, which gives you the ability to evolve and move faster. The more you are self-consuming, dogfooding, drinking your own champagne or whichever euphemism we want to use, the stronger your platform ends up becoming.

“Whether you’re a New Relic employee or a customer or a developer at a partner, you’re using the same tools.”

Another guiding principle for us is that we’re striving to be a more open company that’s contributing to open source, consuming open source and engaging in open standards. We joined CNCF about a year or so ago. We did that so we had a way to engage the community at a different level, bring some of our thought leadership and learn from other companies that are there. So we’re working to be more open, and we favor working openly where we can. That doesn’t mean we’re going to open source everything, obviously. But it does mean we’re going to try to engage more openly.

The last one – and this is one that’s really, for me, the most important one – is that working with New Relic must be joyful. You have to have that sense of accomplishment. Think about the first 20 minutes when you think, “Oh, I want to go try something,” and all of a sudden it works. You’re like: “Wow, I did that! That was awesome. What’s next?” You get that excitement, and you feel like you’re being productive and driving value to the business in a new and unique way. That’s a joyful experience. That’s the energy and excitement I want New Relic’s developer program to instill in every person that touches our API.

Jeff: Yeah, we recently had Ceci Stallsmith from Slack on the podcast, and she mentioned something similar in the sense that you’re trying to make the process simple and easy and effortless for the users of the platform. But you also are there to instill some of your brand and your personality into the relationship. It sounds like that’s exactly what some of these principles are driving towards.

Mark: That’s exactly what those principles are driving towards.

Jeff: Great. You guys obviously have a strong set of principles here to start with. But how hard was it to get to those? Was there a ton of internal debate? Was it an exec-level thing? Was it at ground level with the team deciding that amongst themselves? How did that play out internally?

Mark: It’s really interesting. There was really no debate about that last one. We’re here because we all have this love affair with software. We’re all passionate developers, so making that a joyful, exciting experience was a no brainer. It’s almost like stating the obvious. Like we talked about, building software’s hard. Deciding, for example, if we should open up an API that we use proprietarily – those are hard decisions.

Jeff: They’re hard calls.

Mark: Yeah, building software isn’t always the prettiest thing. So there was a lot of debate about that. What does it mean to have everybody created equal? And what does it mean to consume our own platform? We had a lot of discussions about that at multiple levels of the organization.

Jeff: And in the end, you guys came to a common understanding of what “created equal” means, and what openness looks like and that sort of thing?

Mark: We did. And this is part of our journey as a maturing developer platform, as engaging our community more. These are guiding principles, and we strive for those principles. We’re not always perfect, but this is what we’re striving for.

Running an active developer program

Jeff: Just to get down to the nuts and bolts of it, I’d love to hear a little bit about how your team is set up, and how the developer program runs at New Relic.

Mark: Sure. I’ll talk specifically about the developer ecosystem part of our organization. We think about that and ask, “What’s required to enable our core platform?” These are the tools, the APIs, the SDKs that we build to enable developers to extend our platform. Then we think about things that are built using that. Again, going back to the idea that all developers are created equal, when we start to build integrations on top of that, we want to be using the same tools, the same process, the same methodologies that we expect our customers to use. The notion of integrations built on top of the platform would be another slice of how we think about that.

Then, obviously, there’s our advocacy, evangelism and enablement aspect of this, where we go out and try to bring some of our thought leadership to our customers and developers by showing them the best practices of how to build onto the platform, extend the platform and get more value out of it.

“As organizations start to become more agile and try to deliver innovation faster, we’re seeing developers have this increasingly important seat at the table in deciding the tools and platforms they use”

Jeff: Listening to what you were saying there, Mark, it seems like not only are you building your internal org, but you’re really focused on building a larger developer community. That spans not only from the obvious (which is people building on the platform and your customers who are using the platform to do their own jobs), but also to your internal teams, who are effectively forced to be part of the community by that guiding principle of all developers being created equal. How do you think about creating a great community experience? And why is that community such an important factor to the success of the platform?

Mark: As organizations start to adopt DevOps practices and start to become more agile and try to deliver innovation faster, we’re seeing developers have this increasingly important seat at the table in deciding the tools and platforms they use. More and more, these decisions we’re seeing are not just based on features and capabilities that pop up out of the box. It’s also how well you can integrate with other applications that are important to their business, how you fit into their tool chain, and ultimately, how you become the seamless part of their business.

When you’re struggling because you’ve got a fire because your systems are down, the last thing you want to be doing is trying to figure out and balance between multiple systems. You want an intuitive way to navigate and solve that problem quickly. This is a key part of why we’re striving so hard to create this joyful developer experience, to provide the right sets of tools and APIs, to make it easy for teams to work with New Relic and to get data in and out of our platform so they can integrate it into their workflows and their processes.

We believe this fosters innovation and helps modern teams deliver faster with much more confidence. That’s really at the core of why we’re building our developer platform and providing the tools and SDKs that complement our products. And I think we’re seeing that this is why customers and our partners rely on New Relic, like Intercom. It’s the ability to have the extensibility, to simplify the deployment and automation, to integrate with incident response and to really deliver faster with confidence. It’s an exciting space to be in.

Jeff: And the sum total of all those pieces means that this community of developers and people using New Relic are doing it because there’s joy in it. They’re doing it because it makes their lives easier, and then because of that, they’re helping each other get better at using this tool well at the same time.

Mark: We’re in this business because we’re passionate about building innovative solutions, and we’re passionate about software. My first computer – I might be dating myself – was an Apple II, and I was programming in BASIC, and I was like, this is awesome stuff right here.

We’ve come a long way since then. But it’s exciting, and this change in the industry and what’s happening now and the ability to innovate – it’s just opening up so many opportunities for everybody. And when you build that software, you need to understand what’s going on with it.

Software as offense

Jeff: Tell us what’s next for New Relic’s developer platform and developer ecosystem.

Mark: We started this podcast thinking about this change in the industry – this complexity that’s happening as we make the shift towards everything being digital. We talked about half the GDP moving through software. That’s incredible.

For companies that are going to survive in this world, you have to change the way you think. You’ve got to play offense with software, and you have to think about the things your developers create as strategic assets that give you a competitive advantage. Because who builds that software? Developers.

So we’re going to continue to open up our platform. We’re going to continue to make it easy for developers to send data from multiple data sources that aren’t just New Relic data sources. We’re going to continue to expand our API coverage, make our platform richer and deeper and provide a set of tools and capabilities on top of that that accelerate your ability to innovate.

Then we’re really going to drive this notion of innovation through our programmable user interface. That’s going to open up an incredible amount of thought leadership and innovation on our platform to create new and exciting solutions. We believe – and you’ve heard Lew Cirne talk about this – that the world deserves more perfect software. And programmability is the future of New Relic that’s going to help us get there.

Jeff: Amazing. One of the things that is great about listening to how you talk about the platform is that it’s so intertwined with the product and New Relic. Building software is what your product helps enable, and your developer platform helps also enable that, too. It’s product, it’s platform, it’s ecosystem, it’s developers.

This has been a really great conversation and an interesting take on platforms and developer communities. Thanks so much, Mark, for joining us today.

Mark: It’s been great. Thank you very much for having me.