Randall Degges Highlights Okta’s Scalable Approach to Engaging Developers

Randall Degges, OktaRandall Degges, Okta

In today’s business climate, the need for companies to be agile, innovative and able to scale is greater than ever. APIs are drivers for these needs but before an organization can reap the benefits of APIs, it must set up an API strategy.

Developing an API strategy can be broken down into four stages: establishing your strategy, aligning your organization and culture, building the technology needed to support the strategy and engaging with your ecosystem. This series of articles examines the fourth stage by speaking with the world’s leading practitioners of developer engagement to find out more about their best practices.

All successful API providers make it a priority to actively engage with their developer communities. Doing so helps build a vibrant ecosystem of developers and partners who can extend the reach of their API strategy. ProgrammableWeb has spoken to a number of providers about their best practices for engaging with developers. This article will focus on Okta, one of the world’s leading cloud-based identity and access management providers. We spoke to Randall Degges, Head of Developer Advocacy at Okta.

Over the last four years Okta has gone on a journey from launching a new developer product with no developer users to now having a community numbering in the millions. Degges discussed how small companies can’t always follow the playbook of larger, more established companies. In Okta’s case that meant being efficient with its resources. Instead of taking a presence based approach where developer advocates would travel from in-person event to event, the team at Okta focused on building open-source tools for developers and creating technical education materials. These techniques scaled well a feature that is key for a business of any size.

Degges also discussed how Okta measures overall awareness among its community and how it chooses to target audiences on its various subdomains. To find out more about Okta’s approach, read the transcript of the interview below.This interview has been edited for clarity and length.

ProgrammableWeb: Hi this is Wendell Santos, editor of ProgrammableWeb and today I’m speaking with Randall Degges, Head of Developer Advocacy at Okta. First of all, I really appreciate you taking a few minutes to chat. Could you give a brief background of yourself for our readers?

Randall Degges: I currently run developer relations at Okta over here, which includes developer advocacy, developer tooling, there's a few other things as well, but generally our goal is to make Okta popular in the developer community. My background is I've been programming for a little over 20 years. I used to be the lead open-source developer on a Telco project. Later I founded my own startup, and I was the CTO there for many years. Then I worked at a small security startup that sort of grew quite fast, and then we got acquired by Okta. So for the last, I want to say about eight years or so, I've been leading developer relations at that company.

PW: Okay, so you've been at Okta for a while it sounds like. During that time, have you been doing developer relations and developer advocacy or is that something you've grown into over the years?

Degges: Well, I got started as a normal engineer early in my career, and then I founded a company and became a CTO and sort of a lead engineer and stuff like that. And then I got into developer relations when I joined a different startup called Stormpath and then I worked there for about four years. And that's when we got acquired by Okta.

So I've been at Okta for almost four years now. I sort of landed into it after doing an engineering career for quite a while. It's a really fun mix of engineering and writing and speaking and things like that. I've always sort of had a passion for it.

PW: Yeah, to say nothing of traveling and meeting lots of people. I want to ask about something that I had read in one of your blog posts. You talked about how a developer evangelist at a company like Twilio may have a certain strategy for going out and engaging with the community. But that same strategy may not be the right one for a company at a different point of their API journey. So I was curious to hear more about this, because it sounds like you've kind of been in companies of different sizes and at different points of their journeys. Now that you've been at Okta, how would you describe your strategy for developer engagement as it currently stands?

Degges: Yeah, I mean, it's a really good question. I'm happy to talk about it, but I'll also give you a little bit of background. You're spot on that you need to do it differently in different places, and some places, it just doesn't make sense at all. And in the perfect world, this function actually would not exist in any way, shape, or form. I think this is going to be a terrible example, but Tesla is a really interesting case. Now they are not a developer company, they're not marketing things to developers necessarily, but one of the interesting things about Tesla is that they have no marketing function. They don't spend any money on paid advertising. I think it's a very similar thing with developer relations. If you are the perfect API company and you have perfect documentation and the best products, and everyone just knows about you, then you don't really need anyone to manage these functions.

It's more of a growth area. Today most companies treat developer relations as a way to get people to discover your product as engineers, and hopefully start using it to build that awareness. Now there are a lot of different ways to do this. So I'm just going to loosely break it down into the two high level categories that I see today.

PW: Okay.

Degges: The first approach is a presence based approach. This is what a lot of companies that you're probably familiar with choose to do. They hire developer advocates, sometimes called developer evangelists, the terms get used interchangeably, but they'll hire advocates and say, "Hey, as a company, we are going to sponsor every developer conference. We're going to go to every single hackathon. We're going to go to every single developer meetup in every city, across the world. And we're going to make sure that people know about our company name by showing up in all these places." That's what I would call the old school developer advocacy approach.

The way that we do it at Okta is we focus much more on the engineering side. When I started here about four years ago, Okta's developer product had just been started, and we had no developer users, no developer awareness whatsoever, and we wanted to grow things from the ground up to make this a big successful product. So the approach we took was we said, "Well, people don't know about us. We've got to do some grassroots stuff. We don't have a ton of resources. So we need to be really efficient with our time and efficient with our actions."

And so what we chose to do instead was focus on building open source developer tools that are tangential to our core business. That way, for example, if you are a developer and you are trying to figure out how to authenticate a user using the Python programming language, you might stumble across one of our open source tools that helps you do that. And in the process of doing that, you learn a little bit about Okta and sort of get pulled into our product umbrella. We also spend quite a lot of our time focusing on technical education. That means writing articles, creating screencasts and videos, doing things that are going to scale really well for our time commitment. So if we're going to put 40 hours into building this amazing guide or course that walks developers through the fundamentals of web security, for example, that might be discovered by 10,000 people a month, every month for the next five years. That's going to be a lot more effective than me simply showing up to one conference or sponsoring one event. You know what I mean?

PW: That's an interesting approach, especially for smaller companies with limited resources. It allows them to scale their work and in effect broadcast their message to a wider audience. You mentioned technical education and how you would create assets such as blog posts, webinars and the like. Where do these assets live? For example your blog posts, do they live on the Okta website somewhere? The developer site? Do you push them out on Medium? Are they guest posts on other sites? 

Degges: All of our articles live on our developer blog on our developer website, developer.okta.com/blog. All of our videos, like our screencasts and video tutorials and the like, those live on our developer YouTube channel. We also have a Twitch channel where we live stream all sorts of events and do webinars there and interactive things with people where we’ll pair a programmer with people and show them how to do things. We also use YouTube Live for broadcasting live streams. For example, once a week we host this web security "Ask Me Anything" hour long sessions on YouTube Live. And so basically any developers that are interested in web security or have questions about “how do I make this thing work?” Or “how does this technology work?” Whatever it is, we have a couple people just sitting on live streams, answering questions, and helping people out.

PW: Interesting.

Degges: One of the reasons, by the way, we don't use platforms like Medium, and I'm going to mention this since you brought it up, is there's a lot of strategic benefit to having it on your own domain. There's a big reason, especially in terms of SEO optimization, that you want to have a lot of content on your own website and on your own domain. It's going to help improve your rank in Google’s eyes, in search engines’ eyes, that your domain has lots of authoritative content on these various subjects. And when you outsource that hosting to Medium or wherever, you lose a lot of control over those things, and it's not as beneficial in the long run.

PW: I feel the exact same way as you. You mentioned Twitch, and now you're the second person recently that has mentioned Twitch to me. I had never previously heard of Twitch as a way to reach developers. Can you tell me a little bit more about that? 

Degges: I started using Twitch years back and historically Twitch is really just used for gaming. That's what people think about when they hear Twitch.

PW: Right.

Degges: But there are a lot of developers, particularly younger developers that will spend their time watching other developers write code on Twitch streams and asking them questions and interacting with them. Years ago I would actually just live stream on Twitch, everything I would do during my day job. So I would literally be working on building some open source cryptography tools or something like that, and I'd have 50 or 60 developers watching my stream, asking me questions. They'd say, "Oh, why are you using this tool? Or how did you configure the editor?" Or like, "That's really awesome. I didn't know this thing, like how does that work?" And so it was a cool way to get developer engagement that's just very authentic. It's very ephemeral in the moment, but people just really enjoy watching it.

PW: That sounds so cool, I’ll have to watch it sometime.

Degges: I'll drop one other thing about Twitch. Back in the day, one of the Twitch streams I would watch is Notch, the creator of Minecraft. He did these amazing Twitch live streams where he would live stream development work, while he was building video games. I don’t watch Twitch streams all the time, but watching those was incredibly interesting because you get to see how someone who's incredibly skilled at something is actually making things happen. It's just really fun.

PW: That's really neat. Switching gears a little, are you able to speak to any of the KPIs you use to kind of measure your engagement efforts?

Degges: Yeah, absolutely. I'm an open book, so I'll give you the high level. I'm not going to give you specific numbers, but I'm definitely going to tell you what we look for and what we measure.

PW: That sounds great.

Degges: Let me explain how I got to this point, because this is something people talk about in the industry a lot and people disagree about it, the way that we do it here is very selective of this iterative process. Our team's mission is to make Okta popular in the developer community. So the question becomes, how do you measure popularity in the developer world? Okay, and because we publish content on all these different places, right? So we have open source tools, we're publishing to get up, we have articles we're publishing on our blog, we have YouTube videos, we have Twitch live streams, we have all these different things.

The sort of naive approach is to take a look at each of those mediums and set specific growth goals for viewership, right? I mean, at least in my mind, that's sort of the obvious first approach. So for example, I might take a look at Twitter and say, we need an extra 500 Twitter followers. Or I might take a look at YouTube and say, we need an extra 500 YouTube subscribers to hit our growth goal. But that's slightly misleading, because you're not necessarily measuring awareness, you're measuring potentially the same people multiple times. So we might have someone who goes to visit our blog posts and then clicks over to our YouTube video, so we might be misrepresenting Okta.

So what we decided to do is we said, "Okay, what's a really good proxy for overall awareness?" And it turns out that for us, the strongest indicator of overall awareness is the amount of net new unique developers who land on our developer website every quarter or year or whatever the time frame. The idea there is that regardless of if someone discovers us through our YouTube channel or Twitch or whatever it is, if our goal is to make our company's products popular in the developer community, eventually if we're successful, these developers are going to go back to our website. And so we measured unique net new visitors to our developer site as the overall awareness proxy. Does that make sense?

PW: I think so. At ProgrammableWeb, we have dealt with similar issues, I'm curious to hear how you approach it.

Degges: It’s an interesting problem. Here's how it works at a technical level. A lot of people use Google Analytics on their website and that gives you some basic JavaScript focused data. The biggest problem with Google Analytics, however, is it's blocked if you're using JavaScript blockers or ad blockers and things of that nature, which a lot of users, particularly in the developer community are. And so every month when we look at our Google Analytics numbers, we compare them to our raw server access log to see in reality, how many people were actually visiting our site and what we come up with is a differential. For example, I can tell you that if Google Analytics reports that we had a hundred net new unique viewers this quarter and our raw access log says that we have 200, that means Google Analytics is approximately reporting only 50% of the raw data because roughly half of our audience is using ad blockers, for example.

Then what we do is take a look at the Google Analytics numbers, and we use those to reverse engineer what the actual numbers are. And that only works, by the way, for overall big picture stuff. So we can get approximate numbers for example how many net new people did we bring in to our developer site this year. But more importantly than that, when you're talking about the developer community, it's not really one community. The way I think about the developer community, it's broken up just like the world today is broken up by countries and each country has a different culture and different language. It's very much the same in the developer world. So for example, there's the Python community, there's the JavaScript community, there's the Java community and they're all very different.

So what we do is we actually tag and classify the content that we produce under each of these developer community tags. I actually built some custom Google Analytics reporting stuff, which injects this tag information into our Google tag manager. And it allows us to do really sophisticated reporting. So for example, I can take a look there and see with a very high degree of confidence, what is the specific growth of our Python community. I can see the specific growth of our JavaScript community. And we use this information to make decisions in terms of hiring for example, the number of  people we should hire for each community. We can use it to help decide what projects we should tackle. We use it to really make a lot of our core key decisions and it's been working fantastic.

PW: That's really cool. I know that we've come across the GA issue before at ProgrammableWeb, that's a nice way around it. You had mentioned your developer site and the API portal. If you go to some providers, Twilio for example, their entire site is their developer portal in essence. Others treat the portal as its own separate entity. With Okta, how do you guys treat that?

Degges: Yeah. So Okta, the way I'm going to describe Okta is we have three separate products. We have our IT products, which we sell to companies that makes it easy for employees to log into things they have access to. So a single sign-on. And we have our developer product, which is the part of the business we're talking about, which is really just an API service that handles authentication and authorization and anything around storing user accounts. Then finally we have a product for CIS admins, and what it allows you to do is control access to who can basically get into what servers. That is more like an infrastructure tool. So we have these three different tools, and they're all very different use cases, right? Like the IT audience is not developers. They want totally different things, right?

So the way we have it broken up today is our main Okta.com domain is very much focused on our IT products. Our developer product is almost treated like a second, totally separate brand. It's developer.okta.com, and that is a highly optimized website specifically for developers. So everything on that website, the pricing, the articles, the homepage content, all the marketing materials, it's hyper-focused at making sure developers have a good experience. And so that's how we've broken it up. Now, there's some talks internally at the moment about doing some reworking to that in the future to make it even more accessible to developers in the future. But it's all sort of in the planning stages still.

PW: Do you ever have the consideration on the API side or the technical product side, sometimes the decision makers might be a C-level person that isn’t necessarily a developer. If they were to land on your developer, developer.okta.com, are there road signs for them to be able to follow and make a decision if it is something they want to explore more? How's that work?

Degges: Yeah. That's a good question. I think honestly, that's sort of a point of debate. My personal opinion is that we don't really need to cater to those audiences. And my line of thinking is we want to keep things as simple and straightforward as possible. If you look at Dropbox's website, Dropbox is a consumer product. I love it. You sign up for an account, use it to sync and back up your files. It's fantastic. If you look at their website, even though they do have a corporate product, it's not obvious by looking at the website. It's not really optimized for that audience. It's optimized for the 99.99% of users that go there. And we have a very similar approach here at the moment, which is that our website is extremely optimized for our target user. Now, we do have some enterprise content and things that are more targeted at Chief Security Officers or Chief Technical Officers, or the different types of personas that might visit our sites to get information and things like that. But for the most part, we try to strictly optimize for our target users to give them the best possible experience.

I’d like to thank Randall Degges for taking the time to speak with me and share Okta’s approach to developer engagement. This is part of a series of interviews with developer relations experts such as Nick Tran at Postman and Quinton Wall at Twilio. Be sure to keep an eye out for future interviews coming soon.

Be sure to read the next Developer Relations article: Lisa-Marie Namphy Explains how Open Source Fosters Developer Interest in CockroachDB