Interview Intro

‍

Richard Rodger:  [0:00:00] Welcome to the Voxgig Podcast. We talk to people in the developer community about developer relations, public speaking and community events. For more details, visit voxgig.com/podcast. All right, let's get started. 

‍

It's not often you get to meet your heroes, so you're going to have to excuse me going a little bit fanboy on this one. I've had the very great pleasure of using Stytch.com in a recent project and it's awesome. So, I was absolutely delighted when Chris O'Neill, who was the first developer advocate at Stytch, agreed to come on the podcast. 

‍

This discussion is pretty practical. Chris gives you a three-step playbook for succeeding as a new developer advocate. Chris talks about the three different kinds of developers you'll meet in heaven – well, at least, the developers who are going to use your APIs. And then we really get into the weeds about how Stytch does developer relations. Okay, here we go. [0:01:01]

‍

Main Interview

Chris O'Neill

‍

Richard Rodger:  [0:01:02] Welcome, Chris, to the Fireside with Voxgig Podcast. It is great to have you here today. It's lovely and sunny in California; it's rainy in Ireland. Welcome. [0:01:10]

‍

Chris O'Neill:  [0:01:11] Thank you so much. Nice to have – nice to be here. [0:01:13]

‍

Richard Rodger:  [0:01:14] So, I'm just going to dive straight in. We were talking a little bit about this beforehand, but I think it's – your history in Stytch, your current employer, is interesting. You were the first dev rel and now you lead the dev rel team there. Take us through that experience. This is what, the last two, three years? [0:01:33]

‍

Chris O'Neill:  [0:01:34] Yeah, about the last year and a half or so. [0:01:35]

‍

Richard Rodger:  [0:01:36] Awesome. 

‍

Chris O'Neill:  [0:01:38] When I joined Stytch about a year and a half ago, there was a pretty small team, about 20 people. I joined about two months before our Series B – pretty big valuation number. This is my first role as a developer advocate. Previously, I'd worked at some other developer facing roles in a few other startups in the Valley. The biggest thing that I thought about when joining the team – we sell an API, an authentication API to help developers build secure and flexible login flows in a couple of hours, rather than sprints. 

‍

So, the first thing that I thought about when joining Stytch is learning the product as deeply as I possibly could, to try to figure out – when you're building login, which developers have been building for decades at this point, one of the problems that you run into when developing those sorts of flows, one of the gotchas, one of the footguns, trying to figure out as much as possible about this space. So, I knew what Stytch was trying to solve for. 

‍

If you're not clear what it's like to build a cabinet or build a table, you're not going to build a great hammer to give to a carpenter. So, learning as much about the space as possible was first job. Second job was then to figure out, what is Stytch's current product? Learn that as deeply as you possibly can. And then finally, that third part was, all right, I know the login space; know the authentication space. I know Stytch's product. How do we get this in front of developers and make that value as clear as possible? [0:03:22] 

‍

Richard Rodger:  [0:03:25] That – so, you've just given us a little three-step process for how to succeed in dev rel. Number one, learn the space; number two, learn the product and number three, learn about the developers. [0:03:36]

‍

Chris O'Neill:  [0:03:38] Yeah. That's the kind of playbook that I take to everything. We just developed and released our first foray into B2B authentication, similar to consumer authentication, but slightly different. And you got to learn that all over again; you got to do the same process. In consumer land, you're really caring about conversion; you're caring about frictionless, ease of use, all that sort of stuff. 

‍

In the B2B land, you're worrying about – well, this person's a member of this organization and they want to use this SSO protocol, SAML or OIDC, whatever. And you have to relearn all of that over again, to then figure out, I have a really good sense of what we're solving for on a consumer space. What do we need to be solving it for in the B2B space? And repeating that same playbook in a new place. [0:04:34]

‍

Richard Rodger:  [0:04:35] Anyone has ever tried to get single sign on working, they know what Chris is talking about. 0:04:39]

‍

Chris O'Neill:  [0:04:38] Oh, my goodness! This is one of those things that the developer within me really wishes we could open-source our SAML service. We have an internal service we built up; we have a bunch of great engineers who put a ton of work into building this. Because , a spec is not a spec. The SAML spec is implemented a thousand different ways across a thousand different products. [0:05:07]

‍

Richard Rodger:  [0:05:08] Of course it is. 

‍

Chris O'Neill:  [0:05:08] And – yeah, exactly. And then some companies have their own special twist on these protocols. And so, building out that service to be flexible, to make sure that you're hitting the actual spec for those companies that do hit it. But then also having those – the flexibility to support SAML-like implementations of SSO is huge. I wish we could open-source it; the developer in me wants to. But I understand it's a ton of work. [0:05:40]

‍

Richard Rodger:  [0:05:43] And open – we'll come back to open source in a minute. People really underestimate how hard user authentication is. I've built so many different login screens over so many different years; there's so many weird, horrible edge cases. Over time, how has – so, we can take it as given that what Stytch does is a useful service. But have you found over time that there's been more acceptance in the market? Or is that something – have you had to engage in educating people about hey, this can actually be really easy. [0:06:23]

‍

Chris O'Neill:  [0:06:26] Yeah. I actually like to think about it similar to the AWS paradigm shift that happened a decade or more ago at this point, where you used to have our own servers, your own metal running in that closet somewhere. And now, that's definitely not the default. Default is you're on Manager, you're on AWS; you're on something like that. 

‍

And if you were to talk to most IT professionals at the time, it would have sounded crazy. Hold on; I have a box in front of me. I control it. If it's down, I can fix it. It was a big risk to a very critical part of their company to have a third-party hosting company run your infrastructure. But over time we've seen the advantages there: the flexibility, the security, it done for you and done well. All of that stuff that's really hard to do: uptime, availability, all that sort of stuff. It's really hard to get right. 

‍

And so, relying on those third-party hosting companies has offloaded a lot of that responsibility and allowed you to reap the benefits of the technology improvements there over time, even at a really small scale. And a similar sort of pattern can be applied to authentication, user management. And that's where Stytch comes in is, we are doing login which, to your point, is – it feels simple. 

‍

Everybody's built a username, login password at some potin in their life. But as you start to find those edge cases and poke around the space and do in-production at scale, you realize how hard it can get. And also, the downfalls. If you do something wrong, your name, your company might end up on Hacker News, with a recent hack or something like that. [0:08:24]

‍

Richard Rodger:  [0:08:25] Have I been PWNed? [0:08:26]

‍

Chris O'Neill:  [0:08:28] Yeah. Haveibeenpwned.com. You type in – you see how often companies mismanage things. And so, offloading a lot of that responsibility will make your compliance team happy. But also, all of the development time to build those flows out, that is the sort of thing where Stytch comes in. And you're right; we do have conversations from time to time with companies who are like, oh, we built it in house, or, that's a critical part of our app. We don't want to outsource it to another company. 

‍

But when you sit down and you start walking through their implementation and what it can look like with Stytch and how quickly they can make changes, make improvements, really fine tune it. And make sure that they're not getting conversion drop-off. All those sorts of things start to come into play, and the value add of having Stytch do that for you can be made clear. [0:09:24]

‍

Richard Rodger:  [0:09:25] Yeah, and I can speak from personal experience on this one. In the past, I have built password-based login systems that only did one round of hashing, and I thought, it was – hey, I have assaulted a hash; I'm doing it right. And I've done – I've written my own 0Auth implementations. Why? Oh, my God. 

‍

But in a recent project – and this is the reason you guys came up on my radar – we used Stytch, and that was – it just works; it's fabulous. And it does save a huge amount of time. You'd be crazy – and you're right. The analogy with servers is nearly exact. These days, you tell your boss you're going to run your own servers, you'd probably get fired. [0:10:16]

‍

Chris O'Neill:  [0:10:19] They'd definitely balk at that. [0:10:19] 

‍

Richard Rodger:  [0:10:20] I've done the whole lock yourself out of your SSH – shut down your SSH, even lock yourself out. You have to have people go physically to data centers to rescue you and all that sort of stuff. So, I've been there. Bring on serverless or whatever. I think – is this a general trend, do you think, Chris, that there are various vertical slices of the – of a web service. And I mean that in a more general sense across – there's a website and an app and various bits of functionality are offered to consumer business users. Do you think we're seeing this break apart into vertical slices, where certain parts should, as a matter of best practice, be outsourced? [0:11:07]

‍

Chris O'Neill:  [0:11:10] It's definitely a trend. The amount of time you visit a website and you're seeing HTML and maybe vanilla JavaScript hosted on some web server somewhere, is rare. There's almost always a framework involved, whether it's XJS or something else, where it's hosted, all those sorts of things. You might have seen database as a service, whether Supabase or [Inascale?] Time: 0:11:37. 

‍

More and more, we're starting to realize how many of the things that you can build in house if you really want to. And I say in house, but like we mentioned, you're probably just going to be using some database hosted by AWS or something like that. But how much more quickly you can build and how better of a solution you can create when you're leveraging the expertise across a bunch of different teams who are doing one thing really well. 

‍

Now if you catch me waking up on the wrong side of the bed, I might have a slightly different opinion, which is, do you open up a – any app today and you see 15 layers of abstraction or 15 different integrations that are powering the service. But when you step back and you look at what we're creating today, is a better experience for the user; it's driving more value there 

‍

And that's what we're after. We're not after how well can your company, who may be – I don't know if they're fintech or they're building a social media app. Howe well can that company – how good is your database expertise? That's not the question. The question is, how good of a social media app or how good of a fintech app can you create? It's not about – what's your security team is like. [0:13:04]

‍

Richard Rodger:  [0:13:04] Don’t want to be doing with PostgreS optimization settings ever again, no way. [0:13:09] 

‍

Chris O'Neill:  [0:13:09] Right, yeah. You just want it to perform really well. [0:13:11]

‍

Richard Rodger:  [0:13:12] I have a question for you. In a sense, the – using something like Stytch, because you guys have dealt with all the edge cases; you are the guys doing the configuration options. Do you have numbers or are you able to share them around – let's say someone's using Stytch and you guys have this – you've dealt with all the edge cases and you have a smooth user experience. The drop off in successful registration journeys, login journeys versus homecrafted solutions. [0:13:46]

‍

Chris O'Neill:  [0:13:48] That's a great question. I can dig in on some hard numbers. They don't directly speak to that question, but talk about what it's like to build a really good and smooth login flow for users. One of the things that we've seen when looking across our platform – we've been really surprised and excited to see our fundamental thesis, which is that, presented with less – lower friction login flow, one that converts better, users are going to pick it time and time again. 

‍

One of the big things that we've noticed is, if you present a bunch of users in your app one click sign-in through Google, email Magic links and a password, those three different login flows, Google Auth0, it's one click generally. That is by far, on a 90%, 80% level, of what users are going to pick, time and time again. 

‍

Email Magic link's going to be second, and then password is going to be the lowest down. And we've seen time and time again, when you present users with a lower friction option, that's the one that they're picking. And that conversion comes along for the ride. A better user experience results in higher conversion and vice versa. That – whatever you present to the user is going to be what they pick. 

‍

And so, with Google Auth0, that sort of flow, from start to finish, there's almost ono drop-off there. With a flow like passwords, you'll generally get somewhere between 20 and 44% of people struggling to log in. They'll run into at least one error along the way, whether they forget their password; they type in their email wrong. 20-40% is what I'll generally tell customers to expect with that sort of login flow. 

‍

And then email Magic links is a little bit better than that, but you're – you have a bit of that disconnect. You send an email Magic link; they have to then go to their email inbox, find the email, click it and log in. And so, that's the sort of – the friction and conversion just go hand in hand. [0:16:07]

‍

Richard Rodger:  [0:16:07] Interesting. So, you have this really cool product. Let's switch gears a little bit and talk about how you guys use developer relations to sell that product, to help – maybe developers have chosen to have faith in you guys actually successful. Does Stytch have a particular approach, a guiding philosophy of developer relations? Walk me through how you guys do it. [0:16:38]

‍

Chris O'Neill:  [0:16:40] We start from a mission. Our developer relations team, our job is to create a community and content that leaves a lasting positive impression on developers. That's our mission; that's what we're always trying to do. Part of that is make sure that one, they first have to be aware of switch. Two, that Stytch can click as quickly as possible. If they're aware of Stytch, awesome. When they get to Stytch.com or our docs, does it make sense? 

‍

I get – it's so surprising to me the number of times I've gone to some software website and I can't figure out what they do, what their actual product is; how do you use it. And then the next one is, they've decided, like you said, to put their faith in Stytch and start to integrate. How long does it take them from zero to one, that time to value sort of thing? And then the final aspect is, make Stytch easy to love. You got awareness, time to comprehension, time to value, and then make Stytch easy to love. [0:17:41]

‍

Richard Rodger:  [0:17:41] Do you measure that stuff? [0:17:43]

‍

Chris O'Neill:  [0:17:45] Do we measure that? [0:17:46]

‍

Richard Rodger:  [0:17:46] Yeah. 

‍

Chris O'Neill:  [0:17:48] Yeah, we absolutely – we go ahead, and at each stage in the pipeline, measure what we can, to determine how people are moving through that funnel. As an example, we do time from signup to first API call. That metric is, once they've decided to create a Stytch account, how long does it take them to figure out, how do I make an API call at Stich? 

‍

Then from there to sign up to first API call; then you have from first API call to first user created within test. And then you can have first user created and live. And then how long does it take them to build actual – an actual user base, to either migrate users in or to start to generate users on their own. All those sorts of measurements along the way help us make sure that we're doing what we can in each of those areas. [0:18:45]

‍

Richard Rodger:  [0:18:46] You've got specific actions against your API, your service. You've identified the transition points. [0:18:53]

‍

Chris O'Neill:  [0:18:55] Yeah, exactly. [0:18:55]

‍

Richard Rodger:  [0:18:56] Interesting, okay. And then on – looking at the developer engagement side of things, you guys have – you have a Slack channel and you have normal documentation. You also have your own forum, which is quite well-implemented for those sort of things. Some forums are pretty bare bones. How do you find – where's the most engagement, and why did you put such focus on the forum? Or why is the forum so good? Does it work really well compared to Slack? [0:19:29] 

‍

Chris O'Neill:  [0:19:31] This is something that's interesting that I've learned over the last couple of years, is that first of all, you got to go find developers that are in your ideal profile. A propos to what we were talking about before with AWS and hosting, you want to make sure that you're not – you're finding and engaging with the developers who are open to using Stytch, who want to push their login flow forward and not just take the easy off-the-shelf thing that's been around for 10-15 years. 

‍

And so, you have to find those developers that fit into that profile, and then within that developer bucket you have sub-buckets. There's risky versus conservative ones; there's readers, talkers and explorers, which is relevant to the forum side of things. We – there's buckets of people who really want to get on the phone and talk to somebody. 

‍

They want to hop on the phone, talk through the solution, talk through what Stytch can do, and interact with a human and have a conversation, learn about our product. The explorers are the people who dive immediately into docs; they probably don't even visit Stytch.com, Stytch.com/docs. They're probably optimistically trying to go to that web address, because that's where they want to be. [0:20:54]

‍

Richard Rodger:  (Inaudible) 0:20:54? 

‍

Chris O'Neill:  [0:20:55] Yes. And then they get in, and then they're using a terminal; they're firing off a few curls, just exploring, seeing how things work and putting them together themselves. And then the other bucket is readers, that person who – they're definitely going to visit your docs; they're going to read through everything. They're also that sort of person who's going to want to take a look at, like you said, our community Slack, read through there. 

‍

Also the longer-lived forum of, what's been around? What are people talking about? What problems have people run into? Maybe I have this issue; I have this question. Has someone else mentioned it before? That sort of person – you have to handle all three of those archetypes. 

And so, the forum, that was the thing we identified, of the readers really want long-lived, threaded conversations that they can search through easily. Slack search kind of works, but it ages out over time. And the forum is a place where they can see that curated list, the longer term of the Stytch history. [0:21:57]

‍

Richard Rodger:  [0:22:00] So, this structure of readers, talkers, explorers, is that you guys? Did you get that from somewhere? [0:22:04]

‍

Chris O'Neill:  [0:22:04] This is something that I feel like we came about as we started to develop these different communication paths with developers. We figured this out pragmatically on our own. But then I heard someone – I forget who; I wish I could credit them with this – but I heard someone in a talk explicitly call out these three different buckets, and I was like, 'Oh, these are the buckets that we… 

‍

We're building a postman collection for the explorers so they can easily play around with our API. We built a forum for the readers and then we set up our Slack for the talkers. I was like, 'Oh.' We're doing all these things; we just didn't have labels for those buckets, but now we do, and we can use this internally. [0:22:51]

‍

Richard Rodger:  [0:22:52] Yeah, that's awesome. And that's fun; I can totally which one I am. And I know people who are different, who would value the other parts. That's a really useful little archetype. Let's talk about open source as our final topic. How important is open source to you guys? Do you use it as part of your developer engagement? You had said previously you wish you could do more, but I'm interested to understand what Stytch's disposition towards open source is in general. [0:23:24]

‍

Chris O'Neill:  [0:23:27] In terms of working with open source, we love to do it. We love to be in those open-source repos, working with people to make sure that Stytch fits in neatly with whatever open-source product they're working with. Like we've been mentioning, when you're building an app, you're not rolling everything yourself. You're using this third party paid service; you're using this open-source library, all those sorts of things. We love to work with those communities and make sure that Stytch works across everything. 

‍

Internally, how we like to think about open source, we're an incredibly developer-focused company. We build a product; we sell to developers. They're our core target audience. And the first thing that a developer wants to do if something – they're trying to dig in and understand something and how something went wrong, they want to see the source code. They want to dig into it themselves.

‍

And so, we really like to make as much of our SDK code public as possible, so to enable customers to do that. Then in fact, there's been a number of times where a customer is like, 'Hey, you know what? It might be better if we did this,' Or "Hey, there's this'- [0:24:45[

‍

Richard Rodger:  [0:24:45] Here's a bug. 

‍

Chris O'Neill:  [0:24:47] Here's a bug, exactly. And so, those are the kind of things where we like to get the code in front of the developer as much as possible, for a few different reasons. One, for the developer, so they can debug themselves, identify bugs all on their own. The other side of the thing, it's actually less work for us. 

‍

This is something that I didn't think about explicitly, but you have a situation where if all of your code is internal, it's closed, it's now incumbent, especially on developer relations, to communicate how that code works, how that code changes over time, to developers. If a new version of our SDK is released, it's great if they can go look at what changed. 

‍

If it isn't, now we as a team have to communicate that to developers. And that communication pathway is time; it's overhead. People don't always get the communication pathway that you're intending, and so, that's one of the reasons I really love being able to open source as much as possible. It's better for everybody involved. [0:25:55]

‍

Richard Rodger:  [0:25:55] Yeah. And it makes the developers who are using your stuff way more productive. Because sometimes, even with the best documentation and the forums and everything, you got to read the source code to see how it works. [0:26:06]

‍

Chris O'Neill:  [0:26:08] It's all code. 

‍

Richard Rodger:  [0:26:09] That's my go-to. I always say that to the junior engineers working for me. Read the source, Luke; read the source. [0:26:15]

‍

Chris O'Neill:  [0:26:17] That's exactly it. A forum post, a Slack message, it can be wrong. As much as we endeavor, things can age out over time; things can change. And so really, what it comes down to, whatever the documentation says doesn't matter in the end; it's what the code does. And so, being able to outsource code lets you know, here's how things actually work. [0:26:40]

‍

Richard Rodger:  [0:26:41] Machine never lies, unless it's ChatGPT, which is a whole different story. But I'm afraid we've run out of time, and there's a bit too much ChatGPT conversations these – we could be ChatGPT clients; you never know. Are we real at all? I don't know. Chris, thank you so much; this has been fabulous. [0:27:00]

‍

Chris O'Neill:  [0:27:01] Yeah, thank you so much. It was a pleasure. [0:27:03]

‍

Richard Rodger:  [0:27:03] Wonderful, wonderful. Talk soon. Bye-bye. [0:27:05]

‍

Chris O'Neill:  [0:27:06] Bye-bye. 

‍

Endnote

‍

Richard Rodger:  [0:27:07] You can find the transcript of this podcast and any links mentioned on our podcast page at Voxgig.com/podcast. Subscribe for weekly editions, where we talk to the people who make the developer community work. For even more, read our newsletter. You can subscribe at voxgig.com/newsletter, or follow our Twitter @voxgig. Thanks for listening. Catch you next time. [0:27:34]

‍