Podcast with Okta on Best Practices for Developer Experience
Ep. 2: Okta, best practices for DevEx
Moesif’s Podcast Network: Providing actionable insights for API product managers and other API professionals.
Joining us today are two senior executives from Okta, the Identity and Access Management Service, that you’re probably already using given all of the work from home stuff going on.
In a rolling discussion we cover product manager and DevEx best practices, including: making developers successful through compassion & not just empathy, how to end of life an API, why storytelling’s important across the whole company, what the different roles are in the DevEx universe, and many more.
From Okta we have Albert Chen who is their Senior Product Manager focusing on developer experience in API programs. He’s also co-organizer and speaker curator for the Product Tank MeetUp Group in San Francisco.
And joining him we have Adam Trachtenberg who’s Okta’s Vice President of Engineering for Developer Experience, also he’s in charge of making sure developers have the best possible developer experience with Okta’s platform.
Derric Gilling, Moesif’s CEO is your host today.
Table of Contents:
- 01:00How did Albert and Adam get into developer experience
- 04:35What does developer empathy mean to you and how is it handled at Okta
- 09:25How does Okta organize and separate out the different roles in developer experience
- 15:25There are so many moving parts in APIs like onboarding flows, SDKs for different languages, etc, as a PM how do you prioritize your product roadmap
- 20:32Speaking to metrics like time to value, how do you actually measure developer experience and what is considered developer success at Okta
- 24:25What are the ways that you can reduce developer friction
- 28:00Developer love: how to make sure your developers are happy with your product
- 31:05How do you handle versioning
- 37:40What's next for APIs that we haven't seen yet
- 45:52How has remote working impacted API and developer platforms
- 47:58Tips for new grads who want to get into developer relations
Derric Gilling (Moesif): We appreciate you joining our podcast today and welcome to another episode from Moesif’s podcast network. For us, we provide actionable insights for API product managers and other professionals. I’m Derric Gilling, the CEO of Moesif and I’ll be your host today. Joining us are two senior executives from Okta the Identity and Access Management Service that you probably are already using, especially with all the work from home stuff.
Albert Chen is their Senior Product Manager focusing mostly on developer experience in the API programs. He’s also co-organizer and speaker curator for the Product Tank MeetUp Group in San Francisco.
In addition, we have Adam Trachtenberg who’s Okta’s Vice President of Engineering for Developer Experience, also he’s in charge of making sure developers have the best possible developer experience with Okta’s platform.
Adam Trachtenberg (Okta): Hey Derric. It’s great to be here. We’re excited to be chatting today.
Derric: Definitely and happy to have you here. So that said, you know, would love to just hear a high level overview. How did you get into developer experience?
Albert Chen (Okta): Sure, I can go first. So I started my career in product management doing governance, risk and compliance. And sort of got my first taste of why there are platform requirements - there’s a lot of enterprise software pieces, a lot of tooling and everything needs to be interoperable. I spent some time in Health IT and interoperability, and the importance of having APIs and protocols and standards that talk to each other was was also important there for government compliance reasons. And so at my last gig, I actually served as a platform API product manager onboarding platform partners to try to have them use our platform API to take advantage of the functionality. That kind of segued into my my current gig at Okta as as a Developer Experience Product Manager helping developers of all sizes use our docs, use our tooling, use our SDKs to try and solve their pain points and problems.
Adam: And for me, it’s funny. I had a start up many, many years ago, and this will date it because the web service was FTPing a zip .csv file that, I think, was probably generated by a mainframe every day. This started in ‘95. Every day I would get every TV show that was on air in the United States and Canada, or, more accurately, I would get the 14th day out and then all the changes. Even with something as simple as that you realize you have many of the same issues that we still have today. Like what if it doesn’t arrive on time? What if it’s corrupted? What if they want to change it because there’s new information that needs to be done? Like all the things that we talk about with APIs, around version reliability standards. That was president 25 years ago, and now they’re just in different forms. So through that I started to gain a lot of empathy, compassion for developers, because I would see what I would have to go through. And then after that, when my startup folded, I just started using a lot of things that I learned. So, I was a very early LAMP Stack user with PHP and ended up writing a couple books for O’Reilly helping developers solve problems with PHP. That led me to job at eBay with their platform, where they had one of the very big platforms at the time oddly enough. It was like eBay and Amazon, with commerce and at the time, Amazon Web Services solely existed to help you buy things from Amazon.com They’ve since pivoted and done a lot more but starting to see what was going on helping with developer evangelism marketing. For the last 10 years I’ve been at LinkedIn doing a lot of stuff building experiences for developers and onboarding, and really seeing what’s going on. Now I’ve been an Okta for about four weeks. So new to Okta, but super excited to bring my full range of developer experience. Where I’ve done engineering and product marketing evangelism, tech writing I find that you need to think about everything holistically, in order to provide that good experience. Having done those roles and wearing those hats helps provide insight into what developers need to do.
Derric: Definitely. There’s a lot of discussion around developer empathy. How do you create these authentic relationships? How’s that handled at Okta and what does it mean to you?
Adam: I’ll speak a little bit more generically, because I’m so new at Okta and then Albert can bring in any Okta specific things that’s useful. So to me it’s actually more than empathy, it’s compassion. So, I define compassion as empathy plus action. So empathy is “Oh, I feel really bad this I’m giving you a bad experience,” full stop. That’s not great, right. So what are the steps that I need to do in order to help that developer be successful or not have the pain? So that’s what I focus on. It goes back to a very simple observation which is programming is hard. It’s difficult and it’s really difficult when you’re building on your own platform, which is theoretically deterministic. If you don’t change it, it should still behave the same way every time you run it. But when you’re building on a cloud platform, or on someone else’s infrastructure, it might not behave the same and you don’t know whether it’s your fault, or the internet’s fault, or because the provider has changed. And that just makes it really, really hard to program against, because you’re always trying to track down that bug or build it and understand what’s going on. And so if you have that observation, then it’s about what are the things, the tools, the information that I need to provide to a developer to make their experience as easy as possible? Understanding, what do we do, why should you care, how do you get started, how do you scale that up, how do you support this when things change (and that can be everything from we have a bug, you have a bug, or we’re actually intentionally breaking you because of versioning and other aspects), how does a person get support. Honestly, the hardest part that no one thinks about how do you shut down an API, end of lifing. What’s the lifecycle of our platform, and then what’s the lifecycle of the developer’s app, and how those interplay. And then through that you can really think about what you need to do to help someone have a great developer experience.
Albert: The question was, what do we think of developer experience at Okta. I’ll also answer it a little bit more generically. I like to think of my job as this analogy. Those of us who are of age to buy things on the internet in the 90s, may remember the first time that they went through a shopping cart experience on whatever website. It was super shady. You had to put in a bunch of fields and if you press back they make you start over. It was a very, very bad experience. And now they write books about it, like what are the common design principles of how a form should behave to sign up, how a form should behave when you are trying to buy something, all to increase conversion rate. It feels to me like developer experience is pretty much 20 years ago what UX was to user experience. And from a selfish perspective, that’s great. That’s job security for me as a product manager in this space. A lot of my job as a product manager is storytelling and trying to explain to people who are not in the technical trade, not close to programmers, what are the things that developers deal with. I feel like a lot of the stories that I tell are just rationalizing to other people, other stakeholders, that their experience does matter. Yes, they are technical, but an API or CLI are interfaces, the “I” means interface, and that interface needs to be sleek and elegant and smooth and have no friction, just like any other experience on the web would be. So I feel like what developer experience for me is, is being able to tell the story of the pain points that that dev’s hit and draw parallels to how people view standard UX that we take as table stakes in the consumer world.
Derric: Awesome. It’s really great to see taking more of a customer experience level and applying it to the developer side. When it comes to Developer Experience, so many different roles touch it, everything from Developer Relations, Devolve Experienced Engineers, you have API Product Management, and even sometimes it’s ambiguous - it’s still a new and developing area. What does DevEx mean to you, how do you actually separate these different roles and how do you organize developer experience teams at Okta?
Albert: Well, at Okta we have developer experience in what we call sphere, a sphere is just our internal term for a collection of scrum teams. What we like to say is that developer experience is like the Center of Excellence for things that we should do as a developer friendly, developer first platform, and company. But I would contend there’s no such thing as an API product manager, every product manager for features and functions have to be thinking about APIs right from the get go. When they’re writing their PRDs or one pagers, to when they’re executing, to when they’re measuring success of a feature, and then looping the feedback back into the product and back into the roadmap. So at Okta we have a variety of developer experience engineering teams. We also have a developer relations, or evangelism, team that goes out to conferences and talks about the new tools, and shows awesome new ways to build on top of the platform. We also have a support team and various go-to-market functions, all dedicated to to DevEx. So, it is huge priority for Okta.
Adam: I think the the key piece is what Albert said before about how all product managers are API product managers. If you have a group that’s appending an API on top of your product experience, then it will not really be a first class citizen and then that will create a subpar developer experience. A long time ago when I was at eBay (I left in 2010), more listings were being posted via the API than on the website. Some of those were first party tools that eBay wrote and some of them were external tools. And so, at some point, you’d be having conversations with product managers about how they were thinking about APIs. I would tell them, “You know, you’ll never get to greater than 50% adoption unless you have an API. Logically, you should build the API first and then the web components, because that would actually give you a greater market.” People would be like “What?”, because not everyone had kind of come along with that. But, as it happened we started to have a shift in terms of how people thought about the importance of APIs. And this was, as I said, more than 10 years ago. And you’ve seen that continue to go in a lot of companies over time.
Derric: Oh really agree with that, especially with everyone that’s a product manager having to think about those APIs as first class citizens. It’s not just delegating it to a single team or anything, it’s more of a company wide culture.
Adam: Yeah, we used to talk about how people had mobile PMs. Wait, we have more traffic through your mobile app then we do through your desktop app. Everything’s backwards. Everyone has now become a mobile PM. And I think Albert talking about that transition, user experience / developer experience, it’s like, right now we no longer have mobile PMs, we just have product managers. As this continues to evolve, you won’t have API PMs, just product managers, or API engineering teams, just engineering teams. It will just be expected, it’ll be how companies just do business.
Derric: Love that analogy I don’t think on LinkedIn there’s a mobile PM role anymore. It’s have you just need to know mobile.
Adam: Right. And I remember when I started there was a mobile team and they built the mobile app on our APIs. At some point, someone’s like, wait, we can see the trend. We will get more than half of our traffic from mobile, at which point product and engineering were asking ourselves “If we have this huge team that’s for the minority and then the small team that’s where the majority of traffic is, then it’s inverted.” Then the company has to think differently about how they do business. And then there was similar awakenings at companies around what they think about APIs and what that means for them to do business and build products.
Albert: It’s a tough shift for company leadership. I get it. From a leadership perspective, if you want to do better with your APIs it’s easier for you to say let me just quarantine those responsibilities and pain points to just one team. You are the API team. You are the platform team. The problem is, what’s the rest of the entire product engineering org doing? Anytime a scrum team turns out a new endpoint or updates anything about platform functionality, is it then the role of the one team to go and be reactive and fix things after the fact? And for many startups that’s a luxury that can’t be afforded, they don’t have bandwidth in your roadmap to just take a quarter off to fill in missing public APIs, or update docs that you didn’t do when it was released. So I think the shift is that leadership at companies are starting to get it, from startups to enterprises, that you need to have this inherently built in within each scrum team, or at least more dispersed than just one team that is responsible for making sure you are developer friendly.
Derric: Definitely. Speaking to your product roadmap, how do you prioritize different API features? When it comes to APIs, there’s so many different things: SDK for different languages, onboarding flows, etcetera. Is there a process that you have in place for this?
Albert: From a high level, the way it works at Okta is that we have teams that are dedicated to SDKs and tooling for the 10+ different roadmaps for the various languages that we need to support for authentication and management of resources. A large part of their job is actually removing the need to understand every API. So having APIs is like the bare minimum, having all public APIs does not mean you’re developer friendly, it just means that you have everything that’s possible published. A large part of what DevEx means to us is trying to see how much complexity and content we can remove from a new developer having to understand. Like they don’t want to understand all your endpoints; It’s not a badge of honor for them to know everything; It’s a badge of honor that they completed their use case and got on with their day. So, the less they think about Okta, the better. The other side of product and engineering for us is pretty much everything not related to SDK and tooling. So that relates to the onboarding UI, the docs, the presentation, the content roadmap, growth hacking, community relations, making sure we have a good support SLA and everything else.
Adam: Yeah, I also think of it a little bit like the horizontal and the vertical. The horizontal is the systems and platforms that we want to put in place that lift up the developer experience, such as improving the docs experience, improving the onboarding experience, and how you want to think about SDKs in general. You can do that and optimize it, but that kind of assumes a static snapshot of the APIs. But the truth is that while you’re doing that, the rest of your company are building new products, or evolving their products, and that means those APIs need to transition. It could be a net new API; It could be changing an API that’s just new features; It could be changing an API in a backwards incompatible way; It could be changing an API because you’re actually getting rid of it because there’s a new version. Those are all the vertical flows, so that when you’re thinking about it, you need to reprioritize. The developer experience team is really pushing on the horizontal piece, which is like raising the boats for everybody, about making it a better experience. They’re also being a center of excellence for coaching teams internally about how, as their products are evolving, which means their APIs are evolving, how does that fit into the developer experience for someone who is specifically trying to do a use case that is powered by that API. What does that mean about how they need to change their code, everything from awareness, how this might change, to actually stopped using the old one rolled out to me.
Derric: Totally agree there, especially reducing the complexity to get you on board with the new platform. I love the saying “batteries included but optional,” you can get going as quickly as possible, but then when you’re ready to use those advanced features they’re there. But. you don’t want to expose all that immediately.
Adam: There was a line from the Perl community, which was “the easy things should be easy and the hard thing should be possible.” Now I always felt that everything in Perl was hard, but that was my own linguistic issue. I still think that as a developer who’s just trying to do something that’s the core of the company’s platform offering I should make it easy to get going and see if that will solve my value - can I get that time to value very quickly. But then as I grow and mature and I want to do all those other more complicated things, does that mean I have to abandon the platform because it doesn’t grow with me? Or yes, now that I’ve seen that there’s value and I want to invest that time to get to it, will I be able to grow up with that platform because it’s supporting all the complicated needs that I have. And that’s in some ways what I love about Okta so much. It’s like, “hey, do you need four nines of uptime, and SLAs and commercial guarantees?”, we can provide that for you. If you need that because it’s enterprise class. Or you could be like, I need to sign an experience that basically works and does want I need to do. All right, well, I could get started on that and then as my app matures or I’ve sold this inside the business and we want to scale that up, I could move to a more commercial, enterprise grade set of features and support that I need. And I think that’s very, very important.
Derric: Definitely true and, you know, speaking to metrics like time to value, how do you actually measure developer experience and what is considered developer success for Okta? Sometimes this is hard to actually measure and put a metric to it.
Albert: I think that like every other company, the ultimate metric is that, if you’re public it’s the stock price and if you’re making money. One thing about Okta is, yeah I’m not going to lie, that is important to us, we do want to make our company financially successful through enabling developers. But, it’s actually more than that. We have a mission of being the de facto identity standard for developers. So I think that companies like Twilio or Stripe, being the communication standard or the payment standard, have done a phenomenal job of paving the way and not just like “yeah we want to make money off of developers”, but also they actually really care about building cool tools, and things that people like to use in their apps and products. Okta shares a mission statement and a vision for that: we actually want people to like the things that we build. And that’s what makes me happy to work on these things. It’s not just about the numbers at the end of the day, it’s actually the individual interactions that we have with developers commenting in our open source SDK. They say “hey, maybe you guys should try this” and then us doing that, and then him or her having a smile. It’s corny, but it’s our own end user. Some PMs in some teams work on really back-end problems all day long, and I’ve been part of those teams, and sometimes my role is very backend heavy, but I think the mission statement for being the identity standard for every single developer’s app is one thing that inspires me.
Adam: I really think about, look there’s someone who comes to your site and they probably have a job that needs to get done. I mean, they could be “hey, I’m just super passionate about identity authentication. I want to learn about OAuth 2, SAML and I really want to scale up on that.” And that’s great, but there’s also a lot of people who are building an app and need to have identity. It needs to be good, it needs to be modern, it needs to be secured, it needs to be trusted, it needs to have a high experience and I don’t want to have to invest my time in doing that. I want to focus on the core problem of solving my app. No more than they want to figure out hosting - they’re like, I’ll just build everything out for that, I can use AWS or Azure. Or I can use Stripe for communications. This is something that you we should be able to find you a better, superior experience for less time, so that you can get your job done. And so, as I think about it, there’s awareness of: this is what we can do and why it’s important, how can I get you up and going quickly so that you can be like, this thing works, and I can smoke test this and see it in my app. And then, to your point, I have to think about how the developers think about building the app and what are the customizations that they need to do in order to make it the experience they need and that they can launch it in production and roll out with that. And if you really map through those use cases, then that really helps you think about your metrics and then your funnel. And then as you’re doing that, you’re really trying to think about how does the developer vision success, how does Okta envision success, those have to overlap.And then how do we track people going through their journey to make sure that people are progressing as fast a rate as like they want to go. And that we’re not adding any friction and removing that friction as much as possible.
Derric: Are there certain ways that you’re reducing that friction, so that developers do move to that next step in your developer journey?
Adam: You’re always looking at what it is to get people going and where they catch up. It could be simple things, like instead of saying “and then these are the pieces you need to configure your app”, and then someone has to go to three screens, could you put them on one screen. Or, do we even have to go there, could be automatically configure the samples and the SDK to pre-populate with that data. There is a ton of little things that you can always do to remove friction, which I think is you need to really take that incremental, iterative, experimental approach to doing it. And then there are bigger things like, “hey, is this just holistically a new feature that people really need that’s going to just make their lives, different?” And you kind of work on both of those paths - what are the big step function changes, and then how do you optimize all the little bits along the way. No one of those things would be too much friction to stop someone from doing it, but all of a sudden, when you see the compounding effect of all those changes on it and then it really makes a big radical improvement in DevEx.
Albert: It’s often death by thousands of paper cuts, so it’s not this one, shiny feature that just is the magic bullet that solves everything. I think it’s important to take the funnel very seriously and have very crisp entrance and exit criteria for each funnel stage. So, if you have a roadmap item dedicated towards sign up, after you make the change, you better be able to look at your funnel stats for sign up and know exactly how that impacted or didn’t impact the change. A and just be honest, like you could have a hypothesis: if we make this update to sign up and onboarding better, that we’re going to see more Devs activate, and if it doesn’t, it’s just important not to ignore it, but to dive in deep, investigate and see why your hypothesis was not correct. See what tweaks you can make and what’s the next step. So, pretty much like every other PM for any other use case developer, or non developer related.
Adam: We like to think about developer products as products. So, the same mentality that you bring to bring any product to market, you need to bring that same mentality. There maybe even be more complications, because of who this audience is and often the developer is like an intermediary, they’re building something for somebody else, so it’s like a channel product versus you’re just giving it direct to the person. But, you need every skill that you need just to build a regular product and more.
If you’re like, “oh, well, I’m an engineer, therefore I’m a developer, so I can just do what I want to build it.” It’s actually very rare that you are your own customer, even if you’re an engineer. Once I had an SVP who was building a debugger at Silicon Graphics, so maybe, in that case, he really was his own end client and he didn’t need a PM he could just build it. But, most of the cases you really do need to treat it with all the same hygiene as any other product that you are doing, in fact more so, because they are very complicated products.
Derric: Great point there. It’s easy to throw a bunch of engineers on to a product problem without really thinking about it from a customer experience and empathy level. Once these developers get integrated, what’s next? How do you support them, make sure they’re happy? There’s a lot of talk about developer love and making sure that you can get these folks to to be happy about your product.
Albert: There’s a lot of vectors for feedback. The one vector for feedback that developers don’t have is a lot of time in the phone. They don’t want to talk to you on the phone. They don’t want to have scheduled calls to chat about their feelings, unless you’re recruiting them for a paid engagement on the side. So, for example, we have our dev forum, we monitor Stack Overflow, we have in-products tooling, we use Pinto to solicit feedback at appropriate times, we have a way to provide feedback on our dev docks - people can actually submit a GitHub pull request if they want to make a change themselves. And obviously all of our SDKs and tools are open source, so people can send us issues. So all of that goes into consideration and into the road mapping process. So we have various teams in charge of all of those channels and we try to pull them all together so we can have a bird’s eye view of what’s going on.
Adam: And then I think simultaneously, it’s a little snarky to say so, but developer love could also be - someone came in, they figured out that we solve the problem that they need to solve, they were able to solve it, and they moved on with their lives. They still need to check with Okta’s if new features come along, but they don’t spend a ton of time babysitting it. I think we’ve all built on platforms where you’re like, “oh, that thing broke again” or “they have a backwards incompatible upgrade”, or there was a blip, and then you’re stressing out all about it. And then they give feedback and you need to show love and ask “tell me why that’s causing pain.”
I think there’s also like a ton of love from just like stability. And managing expectations so you know when things will change and you have a notice in your plan for that, and the rest of time it just works. Right? So like, you don’t have to think the telephone or electricity, there’s the expectation that it just works. You don’t need love from your energy company, because it’s managing what you needed it to do. And I think that as we get to that, they become more of a utility. This is the identity utility that you have and you can just set it, integrate it and, not forget it, because as I said this world is always changing, there’s always new things and new functionality that you want to take advantage of - making the sign up experience even more seamless, more secure, reducing that friction for your customers, which will matter, but you need to balance lots and lots of feedback with building a great product that solves people’s needs. So that the people who don’t need to have an intimate relationship are actually perfectly fine with that. Like, they’re just being successful in their business. And then we’re successful in our business as a result.
Derric: I totally agree there. It’s funny that when you think about a developer facing product, you have to think about versioning, deprecation and these type of things. When it comes to a consumer app. I don’t think I’ve ever worried about downloading the latest Dropbox version on my Mac and “oh my gosh, everything’s gonna break and my file is going to be gone”, that just doesn’t happen. How do you handle that? Is there a good process in place or any good tips that you can relate to our viewers here?
Adam: I think with versioning the biggest thing is telling people what to expect, so that managing their expectations and making sure you have the right communication channel so that they’re actually getting your updates. It sounds really stupid, but I’ve seen a lot of times in platform companies where they make a change, but I didn’t know, or a developer didn’t know that that change was coming. And they’re like, “well, we emailed everyone”, “oh, that was an old address, I don’t check that mailbox”. And then you’re doing your best, but it puts you in a total fear of “oh my god, if I make that change how many people are even going to get that message when we say anything about updating. In some ways the most basic thing that you really need to do is, even if you don’t plan to have backwards incompatible things for like a year or two years or three years, is still manage and set the expectations of: “every three months, or every six months, we will make an announcement about like what’s changing and here’s how you should check it, here’s how will inform you.” Or you can rely upon whatever you integrate to be stable and supported for one year or two years. And then people know “oh, it’s been a certain amount of months, I better go check to see what all those other changes were, because I know I’m coming into warranty.” Just that basic set of information alone gets you a ton of of leeway, because you can do all the other best practices, but if someone doesn’t know that a change was happening and then gets caught flat footed and their app breaks, the rest of it didn’t matter. Then, obviously you can talk a lot about semantic versioning and change, and all those other good things about how to do it, but I often feel like, even just nailing those basics, just puts you in the right spot. Because it is around communication and managing expectations, and that’s what you need to do to start that type of relationship.
Albert: I would just add a war story where I was an ad-tech PM and we had to deal with the Facebook marketing API. And it was versioned very well. They set expectations. There’s a legacy version. There’s a current version. There’s a an edge version. And it felt like multiple times a year, it was still a fire drill. So I think the part that was missing there was some of the empathy that we were talking about earlier. Which is yeah, you can set expectations and have everything properly version, but if you’re kind of tone deaf to what a lot of your customers want and need it can still be extremely painful. Facebook being Facebook, they don’t care, they can just call the shots and they’re just going to do whatever they want to do. For the rest of us, we have to be a little bit more compassionate about developers want.
Adam: I think Facebook probably does care, it’s just that from a prioritization perspective, if you were an ad-tech PM, you’d be like, “well, if one thing breaks, I need to make sure my Facebook’s APIs are working before my Google or my LinkedIn ad-tech APIs. So they do get some luxuries. When I was at eBay, we had a major version migration from some old, super random “we just made up some APIs or a bunch of XML posts” to SOAP. This again speaks how old this was. At least this release was standard definition, lots of standards and how to do that, but we had had both APIs running in parallel for over a year, if not longer. Then we gave a year, maybe 18 months of notice for people to migrate over. After maybe 12 months only new things would be in the soap APIs, and then doing it because it really didn’t matter, it was a large percentage of commerce to do it. The funny thing is, I often found the worst offender to migrating over from the old APIs are internal apps that use your APIs. You can work with all of your key partners and developers to get them going, but there’s always some internal app that’s “oh, we didn’t get the message’ or “we had other higher priority things.” The senior executives like you just focus on that and you’re like, I can’t believe I’ve done all this work to shut things down and I still have that one random internal app going. I find that those are the ones, or those that are integrated with operating systems. I literally had APIs that was in Mac OS 10. Your version migration conversations with Apple were going very much different than with anyone else that you might be having.
Derric: That’s a really good point that when you have an API, you don’t just have the external partners and developers, you also have these internal services and such. Is developer experience different, or does it follow the same flows and onboarding experience?
Adam: I think it depends. I mean honestly, in my previous company experiences, they have access to all the APIs, plus. This is because although the right way of communication is by your API Gateway, since they’re internal apps yhey obviously get access to anything that an internal app could build, which would be different necessarily than what you might be giving third party companies. And so often, that’s where it is that they have the same API, but it has a couple of extra features, or they have an API that’s only being used by them. And so those review process will be different, but at the end of the day, it’s kind of like still using the same set of infrastructures, the same types of APIs, the same types of gateways, it’s just that they probably have a broader expanse of what they get and potentially different types of controls or governance or review processes that might be stronger in some areas, but weaker in others. I have it on first party, second party, and third party APIs, and y’all have different types of ways that you handle it.
Derric: Switching topics a little bit, there’s a lot that’s changed in the last couple of years. Just looking back a couple of years I think that Twilio was a half a billion dollar company, and now it’s $30 to $40 billion, which is crazy to see. What’s next for APIs, what’s on the horizon that we haven’t seen yet?
Adam: Well, I think, at one level for better or for worse, Twilio and Stripe have I think validated a hypothesis that not everyone was willing to bet on. There were a lot of people who, when Twilio started, they’re like “oh, I can see why this would be of value, but I think the total market for this is X, where X is like a 10th or 100th of what Twilio’s market cap is today. A lot of people were like, “yeah, I remember Jeff and I could have invested or used or whatever on Twilio, and I thought they’d be good, but I just never really saw that the market demand for this so large. And that this type of channel where you can go direct to developers is an effective marketing channel at that scale. I mean really Atlassian is probably the company that kind of really started doing that even earlier with developer apps that then kind of built up, but with Twilio I don’t think people really bet on the hypothesis. But now that the success has been validated, it seems that at the minimum people are like “oh, I’m going to be the the Twilio for X.” For a while people were saying “I’m going to be the EBay for —,” their own marketplace. Now I’m seeing a lot of companies, a lot of startups thinking that they’re going to be the Twilio/Stripe for video, or some other aspect of what’s going on, as well as very much specifically developer platforms and tools. Similar to how AWS and Azure have kind of proved out those types of cloud things, so that other people can say “oh, I can do other straight-up developer services that I can then sell.” And you’re definitely seeing those from a business perspective. Which I think is very interesting, because then it just really makes this industry more mature, and best practices and patterns will start to emerge about what that means. And then that will force companies that aren’t developer first to actually start to improve their developer programs as well, because the outside pieces, the bar of what people are expecting as a developer building on a cloud platform, is continually being raised. You’ll have a couple, handful of companies, that will be the exception for world class, like lots of things will be world class and then you’re going to be like, Oh, “now I’m behind”, people will opt out.
Albert: I feel that another interesting phenomenon to keep an eye on is the emergence of low-code/no-code development or building. You see a lot of companies and platforms leaning into this heavily. I think one of my favorites is Zapier. Zapier has thousands of system integrators building connectors, doing complex sort of like IFTTT type things. I was recently at the Slack developer conference and I checked out their tooling, and if you want to build a slack bot, you don’t really need to be a developer — they kind of have a WYSIWYG UI that lets you drag and drop if/then statements into their UI. And then you can share it by just copy and pasting in the URL.
Okta is also doing something similar. We have a workflow engine designed to empower IT admins, who might be technical or might not be, just accomplish basic provisioning and lifecycle management use cases. And so it feels like most companies want to be a platform. Most platforms want to be developer friendly. But, it’s interesting to see how the user personas are sort of morphing and changing in that, yeah maybe you don’t have a computer science or programming background, but you know the basics of what a REST API does and how it works. You can see a namespace. You can see a method parameter and know how to piece a few of those things together. And if you understand that, then when you see a low-code environment for building things, apps or integrations, actually do you really need a developer to write the code, or are you just trying to get something done. So I think that’s pretty interesting. I’m seeing a lot of companies invest more heavily into low-code/no-code tooling and that seems to be a growing trend.
Adam: It’s just amazing, and maybe not everybody sees this, but what people built out of Microsoft Excel. As a very low-code/no-code we’re going to do some formulas and calculations and it gives you some graphing and other tools and then they can do Visual Basic on top of it and I think “real programmers” laugh, but at the end of the day there were a lot of people who solved lots of complicated business problems with Excel basically as their database and their UI database tool Anyone could learn and use and share and that was a huge market. Think about how much just Excel alone is actually worth for Microsoft, to say nothing of the rest of the Office Suite. There is that market. It is hard to tap, because you have to hit the right levels of abstraction, but Albert is super on about making it easier for people to solve their problems. Like heck, maybe if I’m still technical, honestly if I can just drag and drop it there’s probably not going to be some compiler issue, or I’m not going to introduce a bug, because I trust my compiler to compile things. It’s kind of the same way. Like if I wire this up to do the logic that I want, that’s going to work, I don’t have to think about it. And again, it’s about making the easy things easy and the hard things possible. Maybe at some point I need to step out of that WYSIWYG and write my own custom functions or other pieces but if I don’t have to, even if I could, maybe I don’t need to. And I’ll be glad to do that and just get my job done and move on with my life. Then I can focus on even more and higher value parts of my business.
Derric: Even us SaaS engineers, sometimes we forget that we’re really here to solve a business problem and meet business objectives, not just code for the sake of coding. And if there is something that can get it done easier, whether it’s Zapier or Airtable, then maybe that’s the right route. There’s just no reason to go and reinvent the wheel.
Adam: Well it empowers so many more people to go and solve their own problems for themselves. If you have to ask me to solve your problem for you, that’s not quite as empowering as I can solve my own problem. And that’s what all these low-code/no-code is like — everyone can be an engineer or many more people can solve what previously you used to need a programmer to do. It used to be can you type, can you use Office, can you use the internet, those were listed skills. Now those are table stakes. As we move into information workers and knowledge management, a lot of people in those jobs will move up to be “can you configure systems, can you run reports, get the data yourself, can you solve these higher level problems”. In order to make that happen we need to bring the tools, so that everyone can be as successful about it. It’s super empowering and I think that’s what’s the most fantastic and exciting about it.
Derric: Has COVID-19, or so many things have changed in 2020, has that impacted APIs and developer platforms? And how do you think it’s going to look in 2021?
Adam: Well, it’s helped me personally because I you lived in the Bay Area for 15 years and then last year I moved out to Minneapolis for some family reasons. And as companies have become more remote friendly, because of what COVID has done, it means they’re actually a lot more open to having conversations about workers who don’t live within you know 30 minutes of an office. And so what you’re seeing is it’s opened the world for talent, to be far more global. You still may be aligned around time zones and languages, or maybe not — perhaps you’re going to have a “follow the sun” piece. And so I think it just increasingly, whether it’s employees at a company for people who are building platforms they are remote first, which Okta is increasingly with our concept of dynamic work and meeting workers where we are. Or you realize now a developer can be building on your platform, it could always be from around the world, but now those people from around the world can actually be working for companies that are also around the world. Platforms are becoming even more powerful because the set of customers and people who you can use them is just going to continue to expand.
Albert: I think from the remote work standpoint, obviously COVID has not been good to the world, but it’s promoted a lot of more healthy interactions between people who were already remote pre-COVID, and where we are today. So everyone is the same. It’s a little bit of an equalizer.
Derric: My last question is just around any tips for new college grads who are looking to enter the Developer Experience or Developer Relations space? I know there’s a lot of economic uncertainty right now, but there’s always a bright spot in tech. Would you have any takeaways or tips for these new college grads?
Albert: I didn’t even know what a product manager was when I graduated college. I’m super bullish on the new generation, by the way. I’m loving the media that I’m seeing about their activism. If I was talking to myself when I was 18 to 21, I wish I would have spent a lot more time just learning about the various industries and businesses that exist, whether it’s tech or something else. I just didn’t think about the real world enough and think about the problems that these companies are trying to solve. If there’s a young Gen Z person that knows that they want to go into tech, they can start their education so much sooner and earlier. There are so many resources online to learn about design, or research, or product management, or HCI (Human Computer Interaction), stuff like that. None of that really existed 10 years ago. So I’m both jealous and also optimistic at the quality of these types of professionals that are going to start joining the market soon.
My advice would be to learn about businesses, learn about how they make money. How many young people really know about how Google and Facebook really make money. Do they actually understand what their business model is. Understanding business models sort of puts you close to the problem that these companies are trying to solve, and that gives you a better perspective in what drives you, what what makes you passionate about the problems that they’re trying to solve and where you imagine inserting yourself in those problems and solution spaces.
Adam: For me, and this is a constant, technical skills are important but actually someone who also has soft skills or non technical skills in addition is actually also very powerful. It could be as basic as technical communication. We’re constantly building things with teams, as the workforce is more distributed communication actually becomes harder, and so to be effective, just talking strictly about engineering - yes, I need you to be able to code, but that’s like the basic - there’s a lot more that you need to be able to do. If you get someone who’s studing literature and can code, then that can actually sometimes be more powerful than someone who just did programming. That’s like crotchety old advice.
When I was in college, which was a long time ago, it was pre-Netscape and Marc Andreessen was pushing stuff out NCSA Mosaic. I remember I had a friend who interned at Microsoft and at the end there was no email, well there was email inside Microsoft where you could message each other. But they would have to go to some computer at the end of the hallway to check their email. Which everyone in college was using at the time. And then during the exit interview, they’re like, “yeah, there’s this thing called email and like we use it all the time, maybe Microsoft should get on that train.” And then that very shortly after Microsoft’s “the Internet, we get it, we’re going on.” But what you realize is college kids now are cloud first. For me, Amazon didn’t exist - I would have to run my own machines. And I think very much like I’ve adapted to the new mentality of how software development is built, but it’s still a change from my original paradigm. Just like email was a change to people and the internet was a change to people who are maybe 20 years prior to me. And so the more that they can just kind of bring up like “yeah, this is how actually everybody builds stuff now.” These are the expectations of dynamic scaling, on demand, good experience, etc. This is how everyone in school is building stuff and these are level setting of what we want. And if your companies aren’t doing that, we need to figure out how to help you shift and grow those. I think being able to bring that fresh, modern perspective into companies, and constantly push them to be on going on where it is, is also incredibly valuable. So your ability to kind of articulate that and show how you can contribute from day one by bringing in that perspective and pushing the company in addition to gaining what the company has going to have to help you grow, that’s a win win. So that’s something to always think about, because I think if you’re in it, you don’t realize it’s a different viewpoint - it’s just how everyone is. Of course we build things that way, that’s just how we build things. But, you need to recognize that this is very much new and sharing that and articulating it is incredibly valuable to other companies.
Derric: Totally agree there. It’s just interesting to see that now college kids these days already have access to Azure AWS account, creating server less functions and that’s the only thing they know. And that is the way that things are thinking going forward. There’s so much opportunity in cloud and SaaS as more of these college grads enter the workplace.
Adam: You bet.
Derric: Well, cool. Thank you very much, Adam and Albert, for joining our podcast today. Super insightful on Developer Experience at Okta and what to look for and how to think about Developer Success.
Albert: Totally. Thanks for having us guys, appreciate it.
Adam: Thanks a lot. Bye.
Make Your API Platform Successful with Moesif
14 day free trial. No credit card required.
Learn More
Related Articles
API Analytics and Monitoring
Introducing AI Explain
We are thrilled to introduce our newest feature to Moesif - AI Explain - a powerful conversational tool that lets you interact with your API analytics data l...
API Analytics and Monitoring
Monitoring Cost and Consumption of AI APIs and Apps
Discover how Moesif can help manage and optimize your AI-driven APIs with powerful observability tools that track costs and usage efficiently.
API Development
Unlock Deep API Insights with Moesif’s HTTP Body Analytics
Learn how to use Moesif to analyze HTTP bodies.
API Analytics and Monitoring
How Moesif API Observability Compares to Treblle
Learn how Moesif’s API observability platform compares to Treblle.