Dev advocacy FTW

Tamao: As you can see, we were supposed to have Randall Degges...is that how you pronounce it?

Alex: Degges.

Tamao: Degges, here together with Alex but he's on a plane right now and he's very, very sorry and as probably many of you know, you know, we make a lot of commitments within our dev rel, developer relations, and developer experience team. So he was saying that he has a really, really good track record of not being flaky so he felt really bad but it's good that he said he trained you with his side of the story. Actually, so why don't you tell a little bit...and you did get the intro but maybe we could start a little bit, explain your history again. How long was Stormpath? How long has Okta been now? Just a little background?

Stormpath and Okta: setting the scene

Alex: Yeah. So Stormpath started about 2010 and we were building an identity service for developers so authentication, authorization, user management, out of the box as an API service for developers to wire into their customer applications.

Tamao: How many people ever used Stormpath before? We've got some passionate…

Alex: Yeah, it's a great product. Thank you for using it. I miss it too. And so...

Tamao: It's true, I saw the Stormpath page and it's just like shhh...just nothing.

Alex: The company was great. I mean, we were very, very developer experience and very developer relations forward and we really sharpened a lot of...we learned a lot from other companies during dev ex and dev rel and we took...we basically talked to everyone who was doing it and tried to take all the best practices and implement them ourselves and then implement a lot of things that we were learning along the way. So we were really happy with our dev ex and dev rel. That's ultimately why...part of the reason why we got acquired. You know, Okta had a product in the market as well and they wanted that developer experience, developer relations, developer marketing DNA in the organization and so they acquired the team. And we're now taking all that greatness and applying it to the same product at Okta, ultimately a competing product but ultimately the same features and rebuilding all that greatness now.

And the part that's really exciting and I think you mentioned this in the intro, part of it is more than just making their product better or faster for developers but also part of it was trying to drive a developer DNA all up into the organization and really trying to make Okta into a developer company, the way that Stormpath was.

The difference one developer can make

Tamao: So, part of the reason I wanted to call them back was so we had lunch a couple of years ago and the result was that he told me a really great story and I said wow, you know, really, we want DevXCon, DevRelCon to be a practitioner's conference where we really try to move away from the high-level talks and really get people to share their real-life stories, what they're dealing with in their particular use cases and not have all the answers but, you know, to share it so we can start the conversation. So hopefully, those of you who were here last year, you saw Alex come to speak and I said, "I love the story that you told me. I really want you to share it," and then he didn't share it.

Alex: I’m sorry, it was loud.

Tamao: I was like all these people, I need to wrangle them more like, "Where was the awesome story?" So fast forward, I said, "Okay, this time I'm gonna get you in this seat. You don't even have to prepare slides, I just want you to talk about it." And of course, you said, "Well, you'll have to talk to Randall because he was part of this really great story." And so I was on a call with Randall months ago and what I loved was, I was like, "This is what Alex told me." It's just amazing sort of this history of like what happened in the early days at Stormpath and what you did and the example was really of, you know, someone who even though he's a little different because he's not just a dev advocate, he's sort of a CTO dev advocate, but you know, someone with very much a dev advocate hat had gone and kinda done something and really influenced the direction that the company would go so I really wanted to share that.

And so when I chatted with Randall a couple months ago, he's like, "Let me tell you my side of the story. This is how I experienced it." So, with him not here, hopefully, you know, if Alex…Alex supposedly is trained on both sides of the story from Randall, but if he doesn't, I'll try to insert some of my memory. So give us the scenario. What I heard was a scenario, was sort of from the executive level sort of a request and a vision of what they wanted Randall to be doing, how he should be spending the time and what you thought the product direction might be at that time that needed change.

Alex: Yeah, so let me go back and set the stage. So this was… I mean, remember, this is fairly early at the time. We did not have developer relations at the time. We had no developer advocates and...

Tamao: How many people were there?

Alex: I think we were like 12.

Tamao: Twelve.

A big shift in vision

Alex: It was very early stage. And we had a product people were using, people really liked it, it was really early stage. We had a really nice REST API. We had great REST documentation. I think we had just rolled out some SDKs in the major languages like Java and .NET and JavaScript. And you know, we got really lucky, we were at an event in San Francisco and this person walks up to our table, if you’ve ever met Randall, Randall is like a bodybuilder, and he just walks up, and he's like...he never wears pants, he always wears shorts. So he comes up in shorts and sandals and says basically, to our team, he's like, "I wanna join your organization," and we're like, "Who are you?" And he basically tells us, you know, that he's, you know, he's awesome, he's great and it turns out he is. He is like really well known in the Python community. He wrote one of the first books on Heroku and he was the CTO of his own company and he was so passionate about our problem space that he was offering to leave his own company to go effectively lead developer relations at our organization. And so we were incredibly fortunate to have Randall join us and right out of the gate, there was a big difference in vision.

And so you know, one of the problems of developer products is that you typically have great developers building that product. You know, your CTO, your architects, your engineers, I mean, they're typically, you know, what we refer to as like Level 6 to 10 developers and that's great, that's why you end up building great products. It attracts great talent, you build great products, it all works, it scales. The challenge that level…you know, high-level developers have is that they tend to not understand and have empathy for the average developer, you know, the level one through five developer. They think everyone is as smart as them and if they're not as smart as them, they should be. And that doesn't really work well for dev ex and dev rel. But we didn't really put the dev ex, dev rel function yet and so we were still in that mode. But our whole organization thought every developer is very comfortable with the REST APIs and they should all understand how to make them work and it'll all be magic if we just give them a good REST API.

And then we started to run into problems where a lot of developers just couldn't get our stuff working fast enough and so they were abandoning the onboarding flow which we were spending a lot of time and money on. And then we started building SDKs for them and we thought, "Okay, great. Well, every Java developer knows how to use a Java object and they know how to wire this stuff into their web framework of choice and that will all work great." But every time we kinda went up a level, we always got really nervous because the level of engineering investment was going up. Now I put on my business hat on and I'm like, "Well, that's really expensive. I don't have that kinda resources, I don't have that kinda budget. I can't put that much money into dev ex because they’re not the star of the core product."

Empathy for the developer

And so we were always holding back on making the product easier to use for the average developer. And part of it was cultural, we thought developers, you know, like could do more and should do more and part of it was just cost. So Randall shows up and Randall is like this magical like combination of being an amazing software developer... If you're in the Python community and you’re working in Flask or Django, you've probably used one of his libraries at some point. But he's also incredibly empathetic to developers of all levels and he's, you know, he's absolutely religious about there being a really good developer experience that's like frictionless. So he shows up on day one and he's like, "This product sucks. I would..."

Tamao: I wanna work for you and this sucks.

Alex: Yeah, "I wanna work for you. I believe in the problem statement. I love your product but this product sucks. I would never use it even though I already use it." And so we're like, "That's great, Randall. Go write some content." And so Randall is like, you know, he's doing meetups, he's doing blog content, at the end of the way we told him to go do dev rel. And he keeps coming back, he's like, "No, we need to make this product easier." I'm like, "Yeah, it's nice, you know, let the PMs and the engineers do their job. You know, go write some content, go get some talks." And he walks into our office one day and he's like, "Look..." my co-founder and me, CTO and me, and he's like, "Look, we need to build integrations into the web frameworks. We need to make this stupid easy so the developers has to go, you know, you know, PIP install, Stormpath, Flask, and everything will just auto wire in. And my co-founder and I both stared at him like, you know, "You're crazy. Like we can't do that. You know how many web frameworks are out there? You know how much engineering effort that's gonna be?" I'm like doing the math in my head, I'm like, "Oh my God, it’s gonna be like $4 million to get all this working and maintained and I don't even have Python staff. I don't have like .NET staff. We can't operationalize this."

This became such a big, hot topic that even in our board meetings with our venture capitalists, we were walking them through all the reasons why we could not do this, that it was technically infeasible. And Randall being Randall...I'll put this succinctly without the cuss words, is, "You're wrong." And we were like, "No, Randall, seriously. We're right, you're wrong, but we're in charge. Get back to your job. We've already given you your OKRs for the month, please deliver on that and don't deviate." And Randall being Randall, said, "You're wrong, I'm gonna prove it to you." And over a weekend, he builds an integration to the Flask framework and Python, which is a great framework if anybody is building like micro-services or APIs in Flask...in Python. And he builds this thing over the weekend despite us literally...I literally told him, "Don't do it," and he did it anyways. And he comes back on Monday with this big grin on his face, he's like, "I did it," and my co-founder and I are like, "We told you not to. Why are you wasting time on this when we're not gonna do it?" "Because I did it and I published it to GitHub and here's a blog article and I've already pushed it to the blog," and I'm like, "What have you done?" And so as I'm staring at him like, "I'm gonna fire you."

Within a week, it had more GitHub stars than all of our SDKs put together. And you know, and staring at this, I'm man enough to admit when I'm wrong and I was like, "Wow, that actually really, really worked." And I’ll never forget, like the blog post was like Flask authentication in 15 minutes, something like that, and it was so successful. And look, I mean, I don't know how many of you follow like the size of different, you know, communities but the Flask community is not the biggest community of developers. It's a fantastic framework. But compared to something like Spring and the Java community or ASP.NET or Express for Node, like it's a relatively small community and the fact that it could perform so well in a 0.1 version in a week was a strong signal to us that the very next week we pivoted our whole product roadmap and immediately started like moving headcount over to staff, people to go replicate that framework in all the major languages, from Node, to Java, to .NET, and even in Ruby. Like we were like, "Okay, let's staff these teams out and have dedicated people to just do nothing all day but build for the frameworks."

Creating a culture of prioritising feedback

And when you unpack it, I think that was really insightful, was a technical insight. I mean, it's...in the moment, we didn't really understand why this mattered so much but in hindsight, it became actually pretty obvious for our product. Well, let's take us back. Web frameworks do a lot, right? They do a lot of heavy lifting for modern application development, and identity, like many other parts of an application or just a really big part of most apps, and a lot of the frameworks have some notion of a user object. What was happening, and we didn't really have empathy for this until like Randall forced us to, was that developers, you had to be really motivated and really good to monkey patch in our notion of a user into whatever web framework you were using and try and line up their user object or their user context with what was happening in our service. And like the big secret to the web framework integrations was that we ended up just rewiring that in for you.

And what all that means in English is that for a developer who has no idea what identity even means and just wants a login screen, they could do PIP install, Stormpath Flask and inside of five minutes, have a fully functioning login screen with full-blown account recovery and it all just magically worked and it was production ready. And all they had to do if they wanted to was, you know, change some functionality here and there, change some logos, some colours and they had it all working. And the reason we tell that story, and the reason you had this conversation was that this is a really powerful example of what developer experience and developer relations can be, right? You know, the lesson we learned is, unfortunately, a lesson that a lot of organizations who are committed to going to market with developers, it's a lesson they oftentimes don't learn, and which is your dev ex and your dev rel teams are more than just how you push your product out. It's more than just, you know, generating a bunch of content, going to a bunch of events, you know, writing nice documentation. If it's done well, it also needs to be a feedback loop back to the product organization. Like the product teams need to be able...need to be listening and that's the hard part, you get the partners to listen to the developer advocates and developer experience people to make sure that they're funneling all that feedback into feature requirements and prioritizing it which is a really hard part too.

We might all agree that, you know, this could be done or should be done but finding a way of prioritizing it against all the other requirements you have from all your other types of users is a big challenge, and so that's something that we culturally had to institute in our company and it ultimately became the heart of our business and our culture for the years after that. And even now into our acquisition and new life in Okta, it's probably one of the biggest things that we've brought over into Okta.

Going guerrilla

Tamao: A slight bookmark, speaking of events, because part of the story was Randall's shut up and meet up with 10 shirts with his new little thing and that was also, I thought, just very growth hacky and I thought, you know, sometimes I, you know, forget about the quick ways that you can get some wins. Did he tell you about that story?

Alex: So Randall is very much a guerrilla marketer and so especially when we were early on, we had, you know, we were like 12 people, we had no money and we were having to break into a lot of events and, you know, we didn't have a big brand either. You know, when you're 12 people, no one's heard of your developer brand before. You know, by the time we ultimately sold, people knew who Stormpath was but at the time, nobody knew who we were. So Randall had to go break into events, get speaking slots. Luckily, he has a following so speaking slots weren't the hardest thing for him, but other times he couldn't sponsor and so he would just show up with shirts and guerrilla and just be effectively be like the unofficial sponsor of the event, he would give shirts out. And then the cool thing that he would do, and this is for people who do developer relations, I think this is one of the things we actually were able to get value out of meetups, it's hard to get value out of meetups because oftentimes, you're either speaking or you're not, and one of the things that Randall was great at was making sure he was grabbing people between sessions, offering them shirts and then dragging them into a computer and giving them a demo, not to sell them on the product but to get their feedback on the product. And that ultimately became a big...of one of our kinda big ways we did events, is making sure we were forcibly engaging people even if we had to jump on them.

Tamao: Part of what he shared with me was...I think it was with the Flask integration but when you guys were still not knowing that he'd gone guerrilla and done this, that he had found a meet up really quickly, gone with 10 t-shirts and said, "I'll give you a shirt if you test this out and give me feedback."

Alex: Oh, he didn't tell me that.

Tamao: See, I knew, I knew. Well, the way he told it to me was like he's like, you know, "They told me not to do it. I found a meetup, I went. I showed up with 10 shirts..." which maybe he stole from the marketing closet and got 9 people to engage with him and again, I don't think he was a speaker. I think he just showed up at a local Python meetup, said, "Hey, I have this cool thing, you know, while we're over pizza, I’d love for you to try it." And he claimed that they became users and he said...those are such the early days that he said, "They couldn't say no to me because I brought nine users and that was nine more than we had." That's the way that he told it. So yeah, I think it's really powerful. So just to sort of underscore this, what was so powerful for me was example in which dev advocates, even community managers who build in developer experience or developer relations can have such a huge impact but also to have an internal executive advocate who could get it, right, who could see it and to bring it all the way up the chain and really pivot your business model, right? It’s so important.

Turning anecdotes into process

Alex: The part that's interesting now is, you know, now we're, you know, now many, many, many years later, we're operating at a much larger scale. And you know, it's the story of how you do it when you're early stage and you're just a handful of people with no money. You know, that's a really powerful story, a compelling story, but the thing that's been challenging is that it doesn't really reflect all the way up when you're now 1,000-person organization or I guess bigger than 1,000 now and, you know, you're pulling in thousands of developers a month. So there, we've had to actually systematize this, you know, like this anecdote has now had to turn into like a rigid process that's happening, you know, in a large organization. And so one of the things we do as to kinda systematize this is every single month, we go on to something like Upwork and we find, you know, a handful of developers, we offer them an hour. We say, "Look, you know, we'll pay you for an hour of your time and you've never...” And we go find people who have never used the product before. “So you've never used our product. You're on Upwork. We're gonna give you an hour, we'll pay you for an hour, and no more, and in that hour, we want you to land on our website cold, figure out what the hell we actually do, and make our product work, and get yourself to this particular technical milestone I want you to hit."

And then we do that and we do probably like half a dozen a month and we record 'em. And, you know, they get paid an hour no matter what, but they have to record everything they're doing, audio and visual, and then we have our whole dev ex team, you know, sit and watch the videos. And you know, it's our way of replicating that at scale but we still get the same value, right, we still get that, "Oh my God, they're struggling with that? Okay, let’s get two engineers and just like, ‘Take that step out.’"

Tamao: Do you guys also use something like FullStory? That's what we use at our company and we actually watch people go through our SaaS product and, you know, and yeah, notice the places where like, "Why do they keep stopping there? Okay, let's focus on that." So anyway, I’m just curious. So I wanted to back up a little bit because you kind of gave the story of how like once sort of Randall had his success, that you then went through all these steps to, you know, decide how you were gonna put your resources in different places, but… So tell a little bit more because you had the shift from literally, "I'm doing math in my head and it's $3 million, $4 million," to "Okay, now I can do this and we're gonna go all out." Obviously, there was a lot more going on in there at the time, right?

Alex: Yeah. We didn't realize how successful it could be and so once we saw the math, once we just simply solved the pull and that pull was so different than the pull we had had prior to us going into frameworks, it no longer became a financial conversation. It was like, "Well, that's what the market wants and we're trying to win this market so let's give the market what they clearly have demand for." And so we went from like thinking through it from a financial perspective of how we're gonna make this work and flipping it around like, "No, no, no, we're going to do this. Now let's figure out how we're gonna stay in budget."

Setbacks along the way

Tamao: Would you be willing to share any setbacks that you might have had like surprises along the way that didn't turn out as...?

Alex: Yeah. Django and Rails were not good for us. It turned out like most of the web frameworks were awesome. Some already had this stuff like way too baked in, like some of them were just way too coupled and we couldn't build an integration into them, and even after spending a ton of money trying to make it all work, it was just too hard. So those were challenges. We also learned a really important lesson which is it's really hard to break into a developer community when it's stagnant. There were some communities out there that were really big and had been around for a long time and it's just really hard to get anyone to care. A great example is ASP, right? Like until ASP Core came out, we couldn't get anyone in ASP to care. When ASP Core came out, we jumped on ASP Core really hard, built a great integration and suddenly our ASP numbers started going up. And so now as we look at it, you know, we're always very focused on like what are the latest things happening and we try and keep our developer experience and our developer relations focused on the leading edge of what's happening in dev land, not on what was working before.

Tamao: That's very helpful. So we have one minute, we could close it out or if there are any questions, will you take any questions? Oh, there's a hand over there. Does somebody have the other mic? Thank you.

Adam: Oh hi, Alex.

Alex: Hey, Adam. How are you doing, man?

Adam: So Randall is great, met him. I've been fortunate to work with some really great evangelists as well like Josh Long, Jeff Barr, Abby Fuller, those guys. It feels like lightning striking in a bottle when you find somebody like that and he came up and found you. What do you think about how to find the right people to go make that replicable as you scale to 1,000 people, 2,000 people?

Alex: Wow, you like teed up like a great question. So I've got like one...I got one tactical thing and then one that's also kinda tactical but also a bit of an anecdote. So in the early stages of Stormpath, probably for like the first 20 people, I did all first interviews. Every time, every first interview I took as CEO. And it's really powerful, you get to filter a lot of people, you get to really control culture. When I was interviewing anybody who was an engineer, I could immediately within the first 10 minutes tell if they were gonna be great for our core engineering team or great for our dev ex engineering team and the difference was one question, I was like, "Where do you wanna be in 5 or 10 years in your career?" And if they said architect, CTO, VP of engineering, they were gonna be on our eng team. If they said, "Well, you know, I like a little bit of marketing, I like a little bit of sales, I like a little bit of engineering and I don't really have like any one job I wanna do. I kinda wanna do everything," if they had that like career ADD, they were perfect for our dev ex team.

DevEx and DevRel: organising the teams

So within dev ex, we had...like our dev ex and our dev rel were the same team and so, you know, there were...even within that, there was a bit of a spectrum. As we were building out dedicated dev rel people separate from dev ex, there was an additional piece to it. You know, when we would interview people to dedicate at dev rel, what we started to learn is that like everybody wants to be in dev rel. It's a great job. You know, everybody wants to write compelling content, everyone wants to go, you know, give great talks. I mean, not everybody, a lot of people. And we had a hard time filtering based on just the interviews so we started looking for people who already were doing it for fun. And so if you weren't already writing a book, if you weren't already like...if you don’t already have a following, and if you weren’t already active on Stack Overflow or GitHub, or if you weren't somehow embedded in the community for no other reason than personal interest, you know, you weren't gonna be a fit for our dev rel team. But if you did do all of those things, it was almost guaranteed you were gonna be a slam dunk in the role.

Tamao: That reminds me, so I will go 30 seconds over because you reminded me, you have a difference in your company between dev rel and dev experience. Would you mind sharing that really quickly because that's the topic here?

Alex: Yeah. So we used to have one dev ex team but that was everything. We had the people who were...it was great. In the early stage, dev ex and dev rel are in the same team and they’re all the same thing and it’s really powerful because you have the people writing the libraries and all the developer experience, and then they have to go be the ones that promote it, and they have to go be the ones who take the support calls and figure out why what they wrote sucked, and then go make it better and promote it and it's just a beautiful, virtuous cycle. That was fantastic and it made our dev ex and our dev rel really powerful in the early stage. It doesn't scale well. And so we very quickly had to break apart dev rel from dev ex because, you know, all the engineering work was subsuming their marketing work. And so now what happens in dev ex, the dev ex guys are really focused on making sure that developers are having a great experience. They're the ones watching the videos. They're the ones polishing off the edges on a signup flow or on a login flow or off-flow or something like that. They're the ones who are making sure the documentation is great or making it better.

Yes, we try and give them opportunities to go do dev rel because it's important for them to go be belly to belly with developers so they don't lose touch with what's happening in the market, but that's separate from our dev rel team now which Randall's, you know, you know, the head of. He now runs dev rel for us. And that team doesn't...they don't write any production code, right? Like yeah, they'll contribute to our libraries but they're not...they don't own that code. They own blogs. They own talks. They own conferences. You know, if they write code, it's typically samples. They're over here. Now they blend but they're still separate.

Tamao: That's very helpful. So thank you very much. Thanks, Alex. And we will take a short break and next we'll have dual tracks, so if you weren't here this morning, either here or on the third floor, we could go up the stairs this way. So thank you. Thanks a lot.