Lorinda Brandon, BetterCloud

All right, here we are again for the next edition of Breaking Changes, and I’ve got another good friend of mine in the lineup here. I’ve got Lorinda Brandon from BetterCloud. Welcome to the show. Thank you, Kin, it’s nice to be here. Yeah. So you and I have known each other for a while, so this is old hat for us. We’ve hung out in a lot of places around the world in several different capacities. But recently this year you joined BetterCloud as their VP of Engineering, so get me up to speed. What is BetterCloud?

One of the things that I love about BetterCloud, that brought me to them, is this crystal clear vision they have. They are a SaaS management platform. What that means is, I should say we are, because I am part of them now, happily. So BetterCloud is a SaaS management platform, which means almost all companies have multiple SaaS applications that they use for their work, right? And they have lots of employees who join the company and need access to all the things, and they need different kinds of access. They share the Google Docs, for example, with other people outside the company and people inside the company. They leave the company and they offboard, and you’ve got to remove their access to all of these applications. So there’s actually a big need for companies to have a SaaS management platform where it’s very simple to set up a workflow that says, I’m onboarding a new hire for engineering, here’s all the stuff they need access to and the ways in which they need access, and let me set up a workflow and just make that automated. And so that’s what we’re basically doing, is automating functions that normally take hours to days for people to set up for their internal use.

So this sounds like something you’re pitching to business users at a company. This is like leadership knows, hey, we’re using Dropbox, we’re using Google Docs, we’re using all of these different things and we need to manage them. But I’m guessing APIs play a pretty central role in how you guys stitch all this magic together, right?

This is all APIs. It’s the same turtles all the way down, that’s APIs all the way down. So we have our own external API that customers can use if they want to use our API capabilities and automate their own stuff. Then we have our own internal APIs which we use for our platform functions to talk to each other. And then of course we’re completely reliant on provider APIs. So Dropbox, Google, Microsoft, we use all of their APIs to actually make the magic happen. So it’s every flavor of API we have ever talked about, and that’s BetterCloud, which is another one of my draws to the company, because it’s such fun. It’s not trying to solve an API problem in one space in your company, it’s solving it everywhere. It’s solving it on the edge to your customers, it’s solving it on the edge to your providers, and it’s solving it in all the places in between. So I love it.

In this reality though, the business folks you guys are catering and selling to, are they going to care that this is all stitched together with APIs, or is it just a pure kind of organizational sell?

The only time that they’re going to care about the API aspect of this, I think, is really when it comes to what we’re exposing to them. So we’re finding that as we get larger and larger customers, they have development staffs. They have teams that are building internal capabilities for them, and they want to be able to access our capabilities through our API. But in general, the work that we do with the provider APIs to make all the magic happen, no, an IT professional shouldn’t have to worry about that or think about that. We handle all of that under the covers. So it’s a big part of our reality, and we have great relationships with a lot of the providers. We have some pretty interesting API discussions with a lot of these providers about what their endpoints can do and can’t do, and how we can make some of the functions that we want to layer on top of all of that happen. So we have some really great conversations around all of that, but our goal is to make it invisible to the IT professional. They shouldn’t have to care. They should just be able to manage their own business’s infrastructure with BetterCloud as their tool to just get access to everything.

So is old school software even relevant in this world that we’re building? It seems like the future. We’re just going to keep moving towards this stitched-together reality where we use a variety of different apps. Are there old legacy Oracle ERP type solutions that you guys connect to? Do you do everything, or is it just the newer generation SaaS solutions that you guys stitch together?

It’s the newer generation stuff. We’ve been around for nine years, about, and so when we say newer generation, I’m talking about within the last decade. But at this point, I think the real benefit that we can all get, it’s sort of all the dreams that we had about APIs enabling all kinds of business capabilities across all providers, a lot of that is coming to fruition, because there’s so much that we can do using modern applications. And so that’s really where we’re focused, is using modern applications to do what is basically modern IT, automated IT, that removes some of the daily keep-the-lights-on kind of activities that people are doing manually. The magic of APIs in this space is that we can do the automation layer by leveraging all of these APIs and building our own, and then it really is just magic on the IT side.

So let’s focus in on the APIs and the API lifecycle at BetterCloud. For you guys to develop your APIs, can you speak a little bit to what your vision is for how you design, develop, deliver, and support your APIs?

So we are on a journey to standardize across all of our API ecosystem in the company, which, as I said, is pretty widespread in how we work. We’re standardizing on OpenAPI. We just started the work to evolve what our standards are, how are we implementing that, how are we making sure that we’re reviewing the APIs that are being built across the company, and figuring out what is our taxonomy, how do we want to structure our APIs internally. We’re starting there, and how do we document them, how do we monitor. As I said, it’s APIs all the way down, so we’re also looking at how do we monitor third-party APIs and make sure that we’re staying on top of any changes or performance issues, because our business relies on them. So part of our journey is not just looking at our own internal APIs and how do we create standards and some level of governance, or at least review of those APIs, but also how do we get more deeply tied to the provider APIs that we rely on as part of our business. So treating them in many of the same ways that we treat our own APIs when it comes to monitoring and testing and alerting. We need to know if any of that changes, because it affects us. And so it’s a multi-pronged journey. I hate using the term multi-pronged, it makes me sound really old, but it’s because we’re trying to figure out how do we standardize our APIs for our own internal use so we can develop faster and communicate more cleanly, but also how do we then put some due diligence around the third parties that we rely on. And ultimately, finally, once we get those pieces more rigorously defined, then we’re going to really take some hard looks at our external APIs. We have a dream and a hope of building a really rich external API layer that lets people integrate with us more cleanly and easily. So rather than us integrating with a lot of the third-party API providers, we would also be opening up the door for people to say, I want to be part of the BetterCloud ecosystem, how do I get in? So that’s sort of our, it’s going to be a multi-year journey, but that’s the path that we’re on. We really want to go all in on APIs. They already are the power behind our system, but we want to go all in on really getting rigorous about it and getting more public interfaces up there.

So it feels like you guys are doing everything that a company should be doing but doesn’t necessarily have the time or the resources to do, when it comes to their own APIs but also the third-party APIs, because companies are increasingly dependent on third-party services and SaaS services. And you guys are kind of putting yourself in the middle and saying, hey, we’re going to do all this work, we’re going to standardize and work with these providers. So what’s that average engagement with API providers look like, third party? Do you guys have regular meetings? Is it mostly self-service within their developer ecosystems? Are you guys just another developer? What do those look like?

No, I wouldn’t say we’re so much just another developer. We have actual partnerships with a lot of these folks, at least the bigger providers. So we have a regular cadence to the discussions that we have with both Google and Microsoft, with Box. For the larger providers where we need lots of capabilities from them, we have regular discussions. Some of that is, here’s the stuff we want to do, tell us how to best use your API to do that. Some of it is, hey, I wish you had this endpoint, this would be really great. But some of it is just, help us understand, here’s how we implemented this, is this the best way to do it, and what is the best way to use your API to make this happen? And what I love about this community, what I’ve always loved about the API community, is how willing everybody is to help. Once you’re all speaking the same language, once you start explaining what it is you’re trying to do, everybody wants to engage in helping you figure out how do you do that. And we have some of the providers who are just so deeply engaged that they try things, they do proofs of concept on their side and say, oh okay, yeah, I see what you’re doing, and I could get it to work by doing this. So we talk to a lot of the DevRel folks on a regular basis, and it’s very collaborative, just as this space always has been.

So it feels like API providers should definitely be investing in those DevRel and partner resources, so that there’s someone there for companies like you to talk to, and not just talk to but engage with, and have the energy and curiosity to actually try to understand what y’all are needing, because you’re kind of a dream developer in that way. You guys are really pushing the roadmap as far as what they should be delivering. What’s easier for you guys to work with, smaller or bigger partners, would you say, or is it a mix?

It depends. I think it’s a mix. The obvious thing is that the larger API providers have more DevRel, so they have more ways for us to engage. They have more time, as you just said, more time and energy to spend understanding our use cases and engaging in a dialogue about it, giving us metrics about how we’re using their system. Sometimes we process so much information. We have some large customers who are processing lots of data, because we do things like scan the files in their system to say, are these meeting your security restrictions, or has this document set that has secure information, confidential information, has that been shared externally? And we flag it. We don’t do anything unless the IT administrator wants to do something with that, but we at least give them the insight into what’s happening across their organization. So you can imagine how much data we’re processing on a regular basis. So we’re pushing those API rate limits to the breaking point sometimes. So we’re working with these folks to figure out, we are one of your biggest users, tell us a little bit about how we’re using your system, give us some metrics, give us some insight, so that we can plan ahead, because we know what we’re going to be building next and we want to make sure that we’re getting ahead of any performance issues or throttling issues. And then of course we’re looking for all kinds of data that helps our customers, and we’re going back to a lot of these providers and saying, here’s what we’re looking for. The bigger API providers, we have account managers, we have DevRel, we get on the phone with the product managers. They just have the staffing and the energy and the time to spend with us to understand what we’re trying to do and help us out.

And it sounds like, in addition to having the staff and the people to help you, having that investment in API management, the right API management layer, that provides a slice of that data and that awareness that you guys need. But what your ask is, of that observability and visibility into rate limits and usage, and even the types of API products that these partners are selling, this reflects what I’m seeing in the space, which is this awareness isn’t just from an API provider side, it’s a shared relationship between the consumer and the provider. And I think this is the future of not just API analytics but observability, monitoring, and awareness, and having endpoints that give you as a consumer access to this data so you guys can automate and programmatically respond to rate caps or heavy usage. And programmatic recommendations, like, I would love to have an API system that kind of does what BetterCloud does, gives me recommendations based on my past usage, or based on what you’re seeing us doing lately, what are some recommendations you have for ways I can optimize how I’m using your API, or ways I can get ahead of rate limit issues that I might be bumping into.

So I think there’s lots of future for something like that, because this is the world we live in, where I haven’t worked for a company that wasn’t relying on third-party APIs, and I don’t even know how long, really long time. This is how we build software now. And so having that visibility across all the providers, here’s what my API landscape looks like. And just to go back to your question about the relationship with the providers, I think the smaller folks, the smaller businesses, don’t have the money and the investment in this kind of DevRel environment. One of the things that is fueling some of our dreams and hopes is not just how do we make the BetterCloud ecosystem larger and more extensible for our customers, but also how do we solve that problem for small to medium-sized businesses who want to be in the ecosystem and can’t spend as much time with us as Google and Microsoft do, answering all our questions and running through use cases and showing us analytics and doing all of that. How can we enable them to integrate with us so that the burden is on our side? It’s our API that we are now the API provider to them. I think that’s kind of where we want to turn the tables a little bit, not only because it opens up our platform to a greater number of integrations across the board, but it also enables some of these other businesses to get into the ecosystem without the burden of us coming at them and saying, here’s what we want from your endpoints.

And I feel like that really is the next iteration of, we use the phrase a lot, API economy. I had this in the first episode, I talked with Shutterstock, and they’re very much of a similar mind. They want to allow smaller providers to just plug and play and do what they do best and nothing more. They don’t have to worry about all the partner infrastructure and all the other capabilities. BetterCloud in this case is a green steel table, and they can just plug in and offer one little slice, one little specialty, and then have access to all these other resources. There’s no reason they should have to spend their little resources to build out this infrastructure that they can just piggyback on. And I would say, you guys are a SaaS management platform, that’s that SaaS enablement, but for me that’s what puts the platform in platform and makes you guys a platform at that level.

Yes, exactly. Because I think in the API economy, in the sharing economy, the Ubers, the DoorDashes, we’ve got to have these enablers, people who do email really well, people who do SMS really well. And it’s really a burden for so many startups to have to do it. So that’s what I really see with the future of SaaS. And I don’t usually do a lot of Postman plugging on the show, but that’s where we’re going with Postman as a platform. We want to enable other API providers to plug in. So it’s not just about the old days, where you and I got involved in this, where you build an API, you launch an API, you publish a portal, and everyone comes to you. It’s like, no, I create an API, I can plug it into a series of other platforms, and then now I have all those platform effects.

Exactly. And I think this is one of the lessons learned over time. When we used to travel the world banging the API drum, there was a lot of, here’s the perfect world in which we all need to live, and we all need DevRel and we all need a portal and we all need all these things. And so if you’re going to have an API, you need all this other stuff. And that’s not really reality. APIs are ubiquitous now, and because they’re ubiquitous, they have to be economical for everybody. And so I do think that this is the next level of maturity, where you have companies like the Googles and Microsofts who have invested, their APIs, you look at the Graph API, and that thing’s a planet all by itself. It’s huge. And so of course you need to support that with a bunch of staff. But it’s not reality and it’s not practical for a lot of companies to do that kind of infrastructure. And so I think we’re at this next stage of saying, look, there are some of us who can just open up these capabilities and let you do your thing without causing you to have to hire an entire function and spend money on portals and all the things that come with that. I think that’s the maturity of where we are now as an industry, which is great. It isn’t where we all started when we were running around telling everybody how they needed to build their API programs, but I think this is the natural evolution and it makes sense to me. I’m doing a lot of refactoring of the stories that I’ve told over the last decade, and I love finding the flaws, and I’m like, well, that was just not sensible.

So since you’ve elevated to the history of how we’re here, how did you get into this game? I’ve known you so, SmartBear, Capital One, Twilio. How did you get into the software game? What’s your backstory?

Oh my god, into software in general? This is like a prehistoric dinosaur story, but I will tell it. Here’s how I ended up here. I was an art history major, actually, and art history majors have very limited career options. I ended up taking a job at the Air Force. This is in the mid-80s, I have survived this industry for a long time. So I joined the Air Force as a civilian in the mid-80s, and when I joined I was working in the A-10 office, and we were keeping track of all the A-10 aircraft and all the modifications. I don’t think I’ve ever even told you this story, Kin. All the modifications you had to make to the aircraft, we were one of the logistics centers the aircraft would come into, the hangar. I wouldn’t make modifications to the aircraft, but I would track all the parts, track all the documentation, and I’d go down to the hangar and make sure the guys knew this aircraft that just came in, these mods, and here’s all the parts. The reality is that in those days we kept track of all of that with paper and pencil. Every screw that was coming in, every company that we talked to to get better prices on whatever, all of that stuff we kept track of with pencil and paper.

And one day, I was in my early 20s, and so this was paying the bills but it was really not my dream job. Our manager called us in one day and he said, they want to computerize all of this stuff, they want to put our jobs in a computer, and I need a volunteer from this office who’s going to work with the developers to explain what we do and test what they make and see if it works. And everybody was so negative about it, and I was the only one who raised my hand and said, I’ll do that. And this is how beloved this program was in the A-10 office: they stuck me in a supply closet with a dumb terminal, and I sat for two years in a supply closet working with the developers who were on the other side of the campus. So I would write things down on a piece of paper and I would run over to the developers and I would explain what we were doing, and how I tested what they wrote, and that it didn’t really work, and here’s how it didn’t work. And I was basically product manager, tester, documentation person. And I was part of automating the inventory for the Air Force. So when I look back on it, it was pretty exciting. But I never turned away, because to me it was a world I had never seen, and the fact that I could go to the developers and say, here’s what we do, here’s what we’re required to do, here are the reports we’re required to create and send to the Pentagon, here’s the kind of information we track and how we track it, and then magically out of thin air they created a system that did that stuff. It was like, how do they even do this? This is insane. And so I never looked back, because to me it was not that far away from art, where I had majored, because it’s a maker culture. They’re creators, and it’s amazing to me, and it’s creative and it’s exciting. You’re always thinking about how can we design this better, what is the next thing we can do. And there’s so much brain power that goes into it. So anyway, that’s how I ended up in software.

You really feel like what you were doing was a very analog version of what happens in an API consumer-provider relationship, as far as a portal. And what you were just talking about with your partners, you feel like you were the human form of Swagger, OpenAPI, going and writing on pencils, writing the little details and running it back and forth. We have portals and we have Slack and Zoom and all this to do this now, but you were laying the groundwork for a lot of that.

And I think it took a lot of us doing similar things. I did that in the education space, mine was in school districts in Oregon. I actually had access to my grades in high school in the 80s through my first job. And I was such a good boy at that age, and then I became a bad kid a couple years later, but I didn’t have to access them.

I was just going to say, before we move off this topic, there’s a real joy in looking back over your career at some point and saying, I was part of the beginning of a lot of things, accidentally. But I love that I’ve got this landscape to look back on. The software industry is what it is right now, and some of the stuff, honestly, 40 years in, and we still haven’t solved some of this stuff. It’s crazy. But it’s so different than what it was, and it’s so exciting to see it growing up and changing and adapting.

And kind of what we were saying about the stories we’ve told over the last decade, I feel like we’re learning. That’s what this API game is always about, it’s perpetual learning. There is no destination. And I feel like the last decade and the last 34 years have all been training to get here. And I feel like that’s where you’re at. Watching you in your career, you’ve had, I would say SmartBear, so integration testing, a very fundamental cornerstone role in the whole Swagger, OpenAPI journey, which is the machine-readable version of you writing things on the paper, the requirements on the paper that you were doing in the Air Force. And then to Twilio, which is a fundamental unit of resource in the API economy, SMS, video, email, all the things they do. But now you’ve leveled up to this three-dimensional chess game that’s like your own APIs, your partner APIs, and then you guys are doing this public API. And OpenAPI is playing a central role in that, because it allows you to communicate and bridge the human and the machine-readable. So talk to me a little bit about the role that OpenAPI is, you’re back in the OAI Foundation helping lead conversations, so talk to me about the role it plays in this BetterCloud journey.

So we recognize that we need a way to design our APIs before we start coding them, and design them in such a way that is predictable and understandable and relatable, and gives us the foundation to standardize how we build APIs, how we build and document and communicate our APIs. I was thrilled, just giving BetterCloud all its due and all the credit it deserves, they were on this journey, they had just started this journey when I joined, so I didn’t propel them there, they were already on their way. And it was just a happy circumstance that this was already underway, because for anybody who doesn’t know, I’ve been involved in OAI since it was born, and so it is a definite love of mine. And so when I got there and realized they were on an OpenAPI journey, I was excited, and we joined the OAI right away.

But it is giving us, I want to be clear that the OpenAPI is serving a very specific function in helping us with what I just said around standardizing, documenting, being more predictable about our APIs, doing some design-first work that, once we get our standards in place, it all becomes easier from there, because you’ve already standardized on OpenAPI, you’ve already developed your taxonomy, the next API is easier to design because you’ve laid the foundation. We’re doing that. But in addition, the OpenAPI Initiative itself, joining that has already had immediate benefits to the company. There’s smart people in there who know all kinds of things about APIs and all types of flavors of APIs and all kinds of circumstances, who have learned a lot of lessons, or are questioning things or pushing on the spec and saying, what about this, what about that. And because you’re in the OAI as well, the minute BetterCloud joined, it’s a very enthusiastic, lovely group of people, and they just sort of swarmed the OAI Slack channels and meetings. Every meeting, marketing meeting, technical meeting, you guys were everywhere, everywhere, everywhere, because they just want to learn and they want to contribute and they want to be involved. And so it’s been exciting to be part of the OAI, because a lot of the questions that we were trying to answer in our own little silo, now we can tap into the larger API brain and say, what about this, or what about that, or just read the articles that get posted, and now you’re like, aha, we don’t need to invent this, we don’t need to spend all the cycles talking this through, because here’s a whole bunch of information that gets us jump-started. And so it’s been an incredibly exciting thing for the company.

So I would separate those two things, because I think OpenAPI has a technical implication to how we do our work, but the OAI has an added education and relationship benefit that gives us access to people and places to go and things to learn about, different types of things that we haven’t maybe even built into our plan yet, but we can start investigating. Oh, what about AsyncAPI, what should we learn more about for GraphQL? Because we do have a GraphQL interface as well, and so how can we learn more about that? So I think it feeds two ways into our journey.

Yeah, I mean, you touch on several layers. I have like three or four stories open to go on the OAI blog that are slow-roll, kind of writing stories about different topics, and I’ve gotten comments and questions and edits from multiple people on your team. I got a story on GitHub’s OpenAPI right now and there was a whole bunch of edits, and I’m like, all right, more people doing this work for me. I was super impressed. So would you recommend that your partners join the OAI too? Is this something, and is them using OpenAPI in a technical capacity, making your guys’ world easier?

Well, this was always sort of our stance from the beginning, that if we can get to a place where we’re speaking a common language, the whole point of APIs is that handshake between people, maybe I shouldn’t say it that way, between systems, but I feel like it’s a very people-oriented community. And so I think the more we standardize on one way of speaking to each other, the easier it is, the faster it is for us to pick up. And of course it helps us if we know how OpenAPI works, if we’re using OpenAPI as our standard, if we’re using it for our design and documentation. The ultimate best scenario is for us to be saying, hey Google, we have this feature request, we’d like to see these things added to your API, and having some design sessions that are based on OpenAPI. Show us your OpenAPI definition, let us take a look at it, let’s see what the payload would look like when it comes back. It’s an easy way to design together, to talk together. It’s not just the implementation like, oh yeah, it’s easy for us to understand how to use that API. It’s also all the conversations that come before that, where the product managers can talk to each other by just looking at what those APIs can do. So of course it would be a perfect world if everybody was using OpenAPI.

Yeah, we should have t-shirts. We’re working on it, we’ll get there. But that sounds like a much greater vision than the original one of Tony Tam, who created Swagger. Swagger UI, documentation autogen, your docs are going to always be up to date, Swagger documentation. This is after a decade or more of evolution. It’s clear that it’s a more human connection, communication, vocabulary, collaboration thing, as well as documentation, mocking, testing, and all these other things, monitoring, that you guys are using it for internally and externally.

Yeah, like I said, I think there’s always been multiple aspects to APIs. There’s the communication and relationship aspect of it, and there’s the technical, what it enables. And so as you just said, and as we were talking about earlier, the OpenAPI itself gives us the mechanism to do all the things you just talked about. It’s easy to find the tooling to generate mocks and do your testing and create your designs and mess around with your designs and monitor, all those things are easier if you’ve got that kind of framework. But the design, communication, collaboration side of it is so key to making all the rest of that successful. And standardizing on OpenAPI, the more we can all talk the same language and just be able to visualize each other’s APIs, it just jump-starts the whole conversation and gets you so much further down the road.

Yeah, and I think that velocity is what a lot of us are looking for, and velocity across a growing complexity. We have a lot more APIs that we have to deal with, and that would be myself for BetterCloud. I think people are waking up to the need, they have a lot of APIs across their organization but they’re using more third-party APIs, and their API programs aren’t really paying attention to that. So I think that’s you guys paying attention to it for us, for these people, which is pretty critical.

So when it comes to your team, back to your team, because the energy of your team has been great in the OAI. I want to keep trying to find ways, I almost feel bad because I don’t have enough work, so I’m co-chair of the Business Governance Group, and I’m trying to move forward a lot of different projects, and they have so much energy to do stuff, I’m trying to find more work to give them. But I’m assuming they’ve got a lot of work within BetterCloud.

Yeah, I shudder a little when you say that. But they’re just so energetic, and they have some of the feedback on, well, GitHub’s not a member, Xero, a couple of the API providers I was doing write-ups on, they just have really good feedback. So how do you motivate them? How do you feed this crowd, how do you get them learning, doing things? Or is it just natural, is the curiosity there?

It’s an incredible group. The culture is just amazing, because this is the culture of the whole company, regardless of whether it’s the tech team or not. The API side of our journey, obviously this has been key to our business, but launching ourselves into the API community full force and just being members of that is naturally exciting to the company. They just love being part of the future and part of shaping this world that they depend on. They depend on the API world to be well-organized and well-documented and to progress in all of the visions that we all have had. And so they’re just naturally excited. And I’ll be honest, I think we all feel, at BetterCloud, a lot of these folks have been here from the beginning or close to the beginning, they’re all in, they’re all invested in the value of what they’re building. And because they’re invested in the value of what they’re building and they’re excited about it and what our future vision is of extending this platform, that enthusiasm and excitement just spills over into everything. So I just lucked out, because I kind of walked into it and they were already like this. And so the minute we joined OAI and I saw them all show up and do their thing, this is what they’re like inside BetterCloud too. They’re just enthusiastic and happy to help and always jumping into everything with that same level of energy. So it’s a dream team to be working with. I completely lucked out, I can take zero credit for that. They were this wonderful batch of people when I showed up.

Yeah, you just gotta harness and lead that in some interesting directions. I would suspect there’s an external factor that you guys are dealing with, SaaS solutions and partnerships, and you guys have a very outward focus, and I think that somewhat lends itself to a certain type of personality and work. And you guys aren’t bogged down in a lot of back-end proprietary legacy systems. You work with software that’s open, and these types of realities let the sunlight in to a certain degree and foster a certain culture and type of people. And I think that’s one of the big things. I would encourage folks to join the OAI, but I think embrace their SaaS usage, how you’re using SaaS solutions and these types of partnerships and APIs, kind of connect folks and make people feel like they get to work together, collaborate together, and then OpenAPI just throws more fuel on that fire. And I had a question in there and I just kind of rambled until I didn’t anymore. That’s something I gotta get better at as an interviewer.

But I also blame you, you gotta take some responsibility, because I just feel comfortable talking with you. I’m not used to interviewing you, so it’s just more natural for me to just ramble with you, what we’ve done around the globe for many years. But I feel like this platform vision that you’re leading right now, I feel like we’ve got some momentum here. I feel like there’s a renewal, a renaissance in the API space. I feel like SaaS has matured, where it’s not a hobby toy thing, no, actually our business depends on these solutions. They’re not new and cool little things, they’re functional pieces. So I feel like we’re at the cusp of something pretty big when it comes to stitching together how the next wave of business gets done.

I agree. And I think one of the things, going back to the enthusiasm of the team, one of the things that the BetterCloud developers are starting to realize is how well they know the API space. They’ve relied on it to realize the vision of the product, but now, especially being exposed to the OAI and all the API brains that are in there, they’re like, yeah, we live and breathe this, we know this inside and out, we know everybody’s APIs inside and out. And the knowledge set that’s in that company is amazing. So tapping into that and harnessing that and spreading the wealth of knowledge so that everybody can benefit from what these developers have learned over time, I think that’s where the value comes in of all of us collaborating together. And organizations like OAI are, to me, a big collaborative group of people who are just grappling with the same problems.

I think you added another dimension why I think your team is like that, and something I want to get across to other listeners. There’s a confidence level when you’re a producer and consumer in equal ways, that comes with that type of awareness. If you’re just a producer and you’ve never consumed and felt that pain, lived through that, or you’re just a consumer and you’ve never had people relying on you, there’s a certain amount of confidence that comes with being both, out in the open in a third-party arena. It takes a certain type of personality, and I think that’s part of the journey that I always want to try to convey with folks, and it shows in your team.

And it doesn’t mean they know everything and every bit of the system is perfect, because they’re working it all, right? It’s that they’re confident in their journey, they’re confident in what they know, confident in what they don’t know, and ready to evolve and change with what’s happening. And that’s the API lesson I think a lot of organizations don’t quite get. We’re still struggling here.

So in one last piece, you touched on observability earlier, so security is something that I’m going to keep weaving into these conversations. And I’m not a security expert, I did a security webinar yesterday with 42Crunch, but my beliefs around security are more about awareness and observability and having visibility into what’s going on. It’s like knowing where your APIs are, having analytics on how they’re used and understanding that. So is security top of mind for you guys’ customers when it comes to using BetterCloud, or is it just the functionality that BetterCloud delivers across these third parties? Is that security and visibility and observability a major concern too?

It’s a major concern. We have a product line called Secure. Think about it this way: if you’re a big corporation, let’s say a financial institution, and you have lots of confidential documents being generated and passed around, if you’re using Google Suite or Microsoft 365, you need to know what’s happening. Who are they sharing docs with? Did a document that was shared three weeks ago get edited, and did PII get added to it, and now it’s shared externally and now it has additional confidential information? You need visibility into your systems and you need to know that there’s unusual activity in some of your SaaS apps. Is an enormous number of files getting shared at the same time, or opened up, permissions changed? We need to provide that visibility to you, which again goes back to the data, this constant data transport that’s going on in our systems that relies on providers giving us this information. We have to get all of that information from Google and Microsoft, for example. So it’s top of mind for us, for our customers, when it comes to security of the data on their system and having visibility into what’s happening.

I would say there are multiple aspects to security. That’s one type of security that we obviously are building our business on top of, so we care deeply about that. But there’s also all the security implications that come with SaaS applications anyway. How do you make sure you’ve got a secure credentialing system that doesn’t let people get in, or at least if they get in, you know about it quickly? This was something we spent a really large amount of time on at Twilio when I was there, because if you’re going to try to crack your way into an API, you’re going to be looking for the ones that communicate with people. So Twilio is a target for that kind of stuff, and we spent a lot of time thinking about our API security and visibility into who’s able to get in and what they’re doing and is there suspicious activity on the system. And BetterCloud, especially as we start to realize our vision of having this more extensible, larger API platform, that’ll have to be top of mind for us as well. So we have a security team who is very diligent, spends a lot of time looking at our systems and communicating back to us about, here’s some things we need to improve. So yeah, we take it very seriously. It’s definitely something that I have a heightened sensitivity to, coming from Twilio after working there during election season.

Oh yeah, Twilio during the election season, oh man. I can’t even imagine the types of people that want to get access to that. But it’s the same for docs, for any messaging, for any of these critical SaaS services that we’re dependent on. And then there’s just the straightforward auth layer, as you said, tokens and keys and secrets and access levels and all of that. Yeah, it’s a lot to keep up with, and across 10, 20, 30, 100 SaaS services, I can see it just exponentially getting out of hand. So you have a security team, you have API teams doing things. What type of talent are you guys looking for? What sort of skills are you looking to add to your team, and personalities you’re looking forward to bring in?

So I’ll start with personality, because you can teach skills. We talked about the personality of the team: they are enthusiastic, they’re engaged, they’re curious, they’re smart, and they’re dedicated to not just the work they’re doing but to our customers and to the vision of the space we’re in in general, to this whole idea of SaaS management. That’s what we’re looking for. We’re looking for hungry, friendly, collaborative people who want to dive right in and learn things and teach things and do all of that hard work. That’s the stuff that is hard to teach. It comes with you. But that’s the culture of BetterCloud, and that’s what we’re looking for. We’re hiring all kinds of positions, so we’re hiring back-end engineers, full-stack engineers, front-end engineers. We have lots of positions posted on our website. I am growing my team for the remainder of this year, and then undoubtedly we will continue growing next year. So there’s opportunity to join us, and we hope you do. Being an OpenAPI fan would be a bonus, but definitely knowing something about the API space. But if you don’t know it, trust me, you have to learn it, we would teach it to you, and you would learn it quickly because that is our world.

Yeah, no, I find sometimes folks who haven’t been in the API space too long, because there’s a lot of dogma and a lot of belief systems you and I have waded through over the last decade, I find them to be some of the more valuable, curious, ask great questions. So I agree. And you don’t have to be technical, I think, to make an impact when it comes to APIs. Managing relationships, project-oriented, you don’t have to be a coder to be successful and have an impact. I’m a programmer and I don’t do much of that anymore.

Yeah, and I honestly think, a lot of what I do for OAI is not technically oriented at all. I’m over in the, how do we evangelize and promote and get people engaged. But I actually think the API space significantly improved when more product managers got involved. Left to our own devices, as you know, because we’ve been in lots of these conversations, we can go down a rat hole of the tiniest little semantic conversations about how these things should be structured deep within our APIs, as opposed to worrying about what is this API actually doing, and did I need an API, what is the point of this, and did I build the right endpoints, can anybody even do anything with this? And so we build this perfect API that doesn’t do anything meaningful. So I think the minute we saw the influx, and I think it was a couple years in, when we started to see the influx of product managers engaging in these conversations, it changed everything. And I think we are where we are now because product managers and product marketing managers got involved and started saying, hey, you know what we really want to be able to do, we want to do these things, your API doesn’t make any sense to me because it doesn’t do those things. And I think it changed everything when that happened.

I mean, you just nailed the premise of this show, why it exists. We want to strengthen and bring in more of those folks. Postman, we got 15 million developers, DevRel, Joyce and the DevRel team speak volumes to those developers. This show’s about reaching those folks that you just mentioned and bringing them into the conversation and making them feel equipped and confident in what they know. So I couldn’t have, I didn’t even script that, so you’re awesome.

So after a crazy week, because I know your job is priced on your mind, you’re on a freight train all week, and then you hit the weekend, taking this to a personal level, I know you’re a baker. What’s your favorite thing to bake that takes your mind off all this technical stuff?

Any kind of yeast or sourdough bread, something I have to knead. I find it very therapeutic. It’s very tactile, and it’s also slow. Bread will do what bread will do, it has its life. It’s a living thing that you need to massage into existence. So any kind of bread, I bake bread multiple times a week, and on the weekends I make fancy breads, and that’s how I relax.

Yeah, I love your Mimosa Sundays photos. I live to watch what you’ve made and what the theme is, the overall theme. You always have something that ties it together and ties it to the world in a certain way. So big fan. Thank you. Well, thank you for being here today with me. This is great. And now that the world’s coming back together, I look forward to hanging out with you again in person soon. But thank you. I’ll be speaking at GlueCon, so come to GlueCon. I’m not going to be at GlueCon. Oh man, we gotta make that happen. That’s the old school, that’s the original days right there. Exactly. I gotta look at my calendar, see what’s going on. But thank you, Lorinda, I appreciate you being here, and enjoy the rest of your week, and look forward to working with you. Same here, Kin, thank you for having me. Alrighty, cheers.

All right, well that was a lot of fun. Always good to talk to Lorinda. She’s a wealth of knowledge when it comes to the API lifecycle. And for me, what she really brings to the table is that conversation about what matters to the people, the human interactions, the partner interactions that are necessary to make all this happen. So thank you, Lorinda, for joining us. I recommend you head over to the website, bettercloud.com, to check out what they offer. I really feel like SaaS management is kind of the front line of all of this, if you think about it. We’re all using more SaaS applications across our business, we’re needing to integrate with those SaaS applications using their APIs, weaving them in with our own APIs, and they’re just a much more critical part of what we’re doing. And if you’re one of those potential partners of BetterCloud, I definitely recommend you talk to them, because plugging in your service to a platform like that really just makes sense when it comes to the next generation of doing APIs.

So what do we got next? Coming up next week we got Mike Amundsen. We’re going to talk some design, some management of your APIs with my old friend Mike. Mike and I have been doing this storytelling in the space for over a decade. I always learn a lot from Mike when it comes to design, when it comes to the continuous API lifecycle management. He’s just got a wealth of knowledge and experience. He’s traveled the world, talked to thousands of enterprise organizations, and he’s just always got a lot to share when it comes to doing APIs as well. So join me next week for my sit-down with Mike Amundsen.

And I just wanted to thank you for subscribing and tuning in to this. I feel like I’m getting a little bit better at this, got a couple of them under my belt, getting better at asking questions, I’m not rambling on, while still keeping it conversational. I’m having a lot of fun, I hope you are too. I’m doing a lot of research on who I should get on the show next. I’m really researching some interesting topics, companies, people, really trying hard to keep it diverse, meaning in the types of people that I talk to, but also keeping it global. I don’t want this to just be a North American thing. I really want to show how APIs are making an impact around the world. So I’m enjoying doing the research, and I appreciate you tuning in. And make sure you head over to postman.com/events/breaking-changes and subscribe so that you’re part of the mailing list. You get updates with upcoming events, and we’re going to start working on some exclusive content that’s just for our subscribers, to kind of dangle a carrot in front of all your faces. And I know one of the things we’re working on is publishing this as a podcast. We’ve had a bunch of requests that this get published as a podcast series and be available for push through your favorite podcasting channel. So I know that’s coming, we’re going to be rolling out over the next couple weeks, so look for it in Spotify and your Apple Podcasts and other channels. And thanks for tuning in. I appreciate you all listening. It’s been fun. I’ll see you next week.