Ep. #7, Enterprise Infrastructure with Paul Querna of Okta

Grant Miller: All right. Hey, Paul. Thanks for joining.

Paul Querna: Thanks, Grant. Great to be here.

Grant: Cool. As we get started I'd love to hear a little bit about your background and how you got into enterprise software.

Paul: Sure. I've always been in infrastructure, whether that was more operations side or more making software. I had a long background in open source, and the Apache Software Foundation, and it was probably almost 10 years ago now that I got involved in a startup called CloudKick.

I was the first employee. It turned into a enterprise cloud monitoring system, and that was my first exposure in a product company making enterprise software, versus just working on infrastructure.

Grant: Great. After CloudKick, what did you get into?

Paul: So CloudKick was actually acquired by Rackspace. At the time Rackspace was trying to build out its open stack cloud, so we really turned into one of the teams there that was building many different cloud products for enterprise customers.

That was a really good experience where I worked in a mix of product development, product ownership and corporate strategy. For how we went from Rackspace's origins as a managed hosting company, to trying to beat Amazon at building a public cloud. There's a lot of experiences there that informed how I think about enterprise software.

Grant: Cool. After CloudKick got acquired you stayed at Rackspace a couple of years, and then your next step, was that ScaleFT?

Paul: Yeah. I stayed at Rackspace almost five years and then I founded ScaleFT with a group of friends who all at the time worked at Rackspace, and we started ScaleFT based out of our experiences at Rackspace around security, around how DevOps teams are operating in clouds, how do you make that more secure was our initial nugget.

We took our experiences from Rackspace, not all which we can talk about, because no one likes to talk about your stuff getting hacked. But how do you address that in a way that DevOps teams don't hate?

Grant: Cool. Then the outcome at ScaleFT was--?

Paul: We were acquired by Okta back in July of this year which was a pretty fast and fun ride. It really, through ScaleFT we started really marketing the BeyondCorp approach. I think it's really awesome we ended up at Okta, where that kind of approach is like heavily believed in as well. It is a cornerstone of modern security.

Grant: Now you're scaling out your product within the Okta customer base and beyond.

Paul: Yep. It's all about scale. Go to market scale, product scale, security compliance. It's a whole different level. It's different when you're a startup, you're trying to acquire one new customer every day, versus when you go into a thing that already has thousands and thousands of customers. You need to scale even faster than you thought you had to before that.

Grant: That makes total sense. OK. Now I want to dive back in to some parts of the story. First, I think we should talk about the foundational concepts behind ScaleFT and tell a little bit more of that founding story. How you started going to market, you started finding some early customer signs. Just talk about the early days of ScaleFT.

Paul: ScaleFT, we started with server access. One of the things we saw in our previous jobs was when a security incident happened, it lingered a long time a lot of times. Someone would break in using maybe something creative, maybe something really silly, but then their goal was always to pretty much always steal credentials so that then they could stay inside the network.

It's way better to steal someone's SSH each key or steal their password and then keep logging into things as that person, then to always using a zero a day or always trying to find some exploit in some PHP web app.

The lesson we were first tackling is if you're familiar with privilege access management as a category, it's a legacy category that says "We're going to take all these secrets and put them in a vault, and then we'll rotate them once a day." That, one, just didn't work in cloud environments. Two, it wasn't very effective, and three, how you even authenticated to that thing was often your static password.

So we said "How can we make an access management product for DevOps people, where they enjoyed using it? Where it was built into their workflows?"We didn't want to break Ansible from working, but every other product out there at the time you couldn't plug it into Ansible. That was like our first requirement, was all the DevOps tools I'm using, they have to work.

We brought a "meet people where they are" thesis, and make their environments safer and more secure.

Grant: OK. The founding principle was basically that the world has changed, now we use automation and DevOps, and a lot of the security tooling around privilege access management just aren't designed to work in that modern environment. What can we build that understands that paradigm shift and solves this problem in a modern context?

Paul: Yeah. That's how we entered the market. We said, "You have DevOps teams. They're on cloud machines, they're on on-prem machines. But they're starting to use automation. How can you do that in a way that is secure, and in a way that supports them," instead of hammering them down and saying "You can't use automation."

Which is a big gap in how the PAM work was approaching it, and it was through that when you started breaking down "What is access management?"

One of my favorite compliments a customer ever told me was, "You guys aren't really in the access restriction game, you really in the granting people access game. You're helping people be successful and get into things." Which I think is a different way than a lot of security companies approach their world, they're all about restricting things.

That was where we cut into some of the BeyondCorp concepts of by default you don't have any permissions, you upgrade people, you give them temporary grants of permissions. That is one of our building blocks. We were building that in our product even before we adopted a lot of the BeyondCorp monikers.

Grant: OK. So, you start this company and you are entering the market probably like a handful of early customers, maybe friendly folks that you're talking to that are using your product and giving feedback in the first year.

Paul: We hit a bump in the road pretty early. We got a large scale multimillion dollar enterprise deal in our first six months, and we only had the four founders at the time when this deal floated into us. It's one of those deals that your friends and advisors, it's a split vote.

Some people were like "Don't take. It'll distract you from building an at-scale repeatable business model," other people were like, "Take it. It's money." We ended up taking it. We spent almost a year working off the debt from that, but it let us do so much more. It's a balance.

Grant: I would vote to take the money as well.

Paul: Yes, take the money. Because otherwise you have-- We had seed money at the time. We would have just ran out of money.

Grant: OK. You've got this early, big customer. Can you share who that was?

Paul: It was actually Rackspace.

Grant: OK. That makes sense. It turns out when you have a relationship with a company, and you've done great work there, and you go off to solve a problem that was a problem for you there, they can be an early customer. Makes total sense.

Paul: Although I mean, I think it was an arm's length relationship. We went away for six months, and then they said "Wait, what are you guys actually doing? This is really helpful. Can we be your first customer?"

Grant: I think this is a somewhat common thing that happens for enterprise software companies, especially where people leave and then they've seen this problem and they're like, "This is more than just a single company. We should solve this." But the context that you're bringing into that is often the problem that you solved from when you saw it at your previous role, so you end up building a pretty well tailored solution for that first customer.

Paul:

Yep, and then the challenge is, of course, you have to go get a thousand other customers. This is the advisor side of this. If I was consulting someone in a similar situation, it's like "You have to balance your overall growth of your company." You're not going to survive and win off one customer, no matter how big they are. Google could be your first customer, it doesn't matter. You need other people. It's a balance, for sure.

Grant: Also in the world of venture funded companies, getting a multi-million dollar deal means that you need to get three multimillion dollar deals the following year in order to still triple and have the growth that you want to have.

Paul: Yeah. Many lessons there, I think. Even just describing optics there, on what is recurring revenue and what is non-recurring. There's a whole separate podcast about discussing large enterprise deals with VCs because a lot of it's recurring, but some of it is non-recurring.

That relationship with your customer is important to figure out, because their needs are going to change over the years and you don't want to have a weird pricing relationship with them too.

Grant: Setting up some amount of non-recurring revenue early, which is professional services and custom work that you might be doing, integration implementation, and then having a recurring fee on top of that.

Paul: Yep.

Grant: OK. You discussed before this, you mentioned a couple of times--BeyondCorp. For those uninitiated, what is BeyondCorp? Describe this concept and where it came from.

Paul: I think before we describe BeyondCorp we have to describe the last 30 years of security.

Grant: Yeah, that's a great idea. What problem was BeyondCorp solving? That would be first.

Paul: Yeah, the context of this is really a lot of security was built around the network, for a very long time. Cisco has Cisco certified Network Associates, and engineers, and security engineers, and their entire job at many companies is literally configuring network ACLs. There's processes and products and a whole ecosystem around "I'm getting traffic from one place," identified via IP, and "I want to white list it or black list it, or analyze it."

That worked OK when you had flat enterprise networks where one team could put a ticket in and approve that you're adding a web server somewhere, and then add a white list. If you have a top down perfect vision of the world, it's an OK architecture.

What's challenging is when your employees don't work in the office, when your apps are hosted in random places, when your organization is so big that it's hard to exchange information about, "Where did that web server go? Did its IP address move last week? I don't know."

Those are the problems that push you towards a new model, and I believe I would describe it as a model that focuses on Layer 7 attributes. Who is accessing what, and then finding ways at an architecture level to authenticate, authorize, and encrypt that in a way that has a good user experience.

In late 2008-2009 one of the triggers of this is Google was hacked by the Chinese government, Operation Aurora, there's a whole Wikipedia page about it.

Grant: Supposedly hacked.

Paul: Supposedly hacked, right. Sorry. Everything's alleged. Although they did write a pretty pointed blog post and The Wall Street Journal reported on it. But yeah, Rackspace was also involved in that supposed incident. Inside Rackspace at the time the path taken was very different. It was a, "We're just going to put firewalls everywhere. We're going to put VPNs in front of everything. We're going to really harden our network centric approach to security."

What that really led to though, was as an employee my user experience was terrible. We actually were in situations where we had people working on open source projects, like this is a full time job, like an open stack. From the office we egress filtered GitHub because we were worried about people exculpating traffic to GitHub.

If that's your job to work on GitHub you can't do your job anymore, but we did that for a good reason, we were trying to stop an attack. It was very disconnected because our our network view of the world was we didn't have any other hammers. We just literally had a banned port at 22 was the hammer we had.

So there was this big operation where the Chinese government-- Google, they said "One, never let this happen again. This is not acceptable. Two, we need to rethink this from the ground up. How do you actually go about doing Access management in a modern way? In a scalable way?

Where disparate teams can make their app, ship to a bunch of employees and not have to open a ticket with central IT to change an ACL somewhere."right. How do you eliminate things like VPNs that are very clunky? They have a bad user experience. Your VPN drops every day, every hour, every minute, and you're frustrated by it.

Grant: So, what's an ACL, first of all?

Paul: Access control list.

Grant: Great.

Paul: If you're coming from 10.00.1 you're let in, if you're coming from 192.168.2.1 you're not let in. You would assign people ports, so when you plug into a port in the office you get an IP address--

Grant: Like a physical, ethernet port?

Paul: Yeah, like a physical ethernet port. You would get a specific IP address that you're in engineering, and engineers are allowed to go to this set of addresses. But if someone from accounting plugged into that port, they might be allowed access all the engineering stuff. That's a decade ago, 15 years ago, that's where the world was in a lot of internal security . It was physical, it's based on where you are, your IP address determines all your access. You can see that doesn't work very well pretty quickly.

Grant: Explain to me, why would that have ever worked really well?

Paul: It works in a model where you come into the office to your desktop computer, and you're accessing four servers that are two floors down.

Grant: OK.

Paul: That is literally the Cisco reference architecture for how an office should be set up for 30 years. That's how your office is supposed to work.

Grant: So this is before those servers were exposed on the internet. They were only exposed and you could only access them if you were--.

Paul: At work, at your desk.

Grant: At your desk, and it's probably similar to maybe that's how-- What did they used to call those, thin clients? Used to work?

Paul: A thin client with a mainframe sent somewhere else.

Grant: Yeah, but sending somewhere on your premises in your environment that you could secure the access to from a physical perspective. You had it in a closet with a lock on it, in a cage with a lock on it. You had to use a key to get into that office, so they were physically securing all of the resources.

To secure who can access that server from inside the building, everyone can plug in the ethernet so let's just lock it down to these IP addresses. We'll use an access control list in order to specify who can access it, and that is like how we will determine access controls.

Paul: Yeah. In fact your PCI audit will pass, because that's good.

Grant: Still today, it'll probably pass.

Paul: Right, it would still pass with that exact same architecture.

Grant: Despite the many differences, it's like "That's the PCI architecture."

Paul: Obviously things change. Employees use Wi-Fi. Employees work at Starbucks. Like, your servers are now on Amazon.

Grant: And so for a while I'm guessing people were remoting into their desktop computer. This is like the I go to My PC and these other technologies they would use, they actually are basically like somehow getting access to your PC remotely and that's what you did. Then eventually they created VPNs.

Paul: Even better than that, there's a whole market category called VDI which is literally virtual desktops.

Grant: OK.

Paul: Like, yes. There are products that do exactly what you're saying, because we're locked into the security architecture. We couldn't fix the security architecture. Instead we gave people virtual desktops and VPNs to live in the old architecture.

Grant: Eventually the VPN was probably like, "This is better than remoting into a specific desktop." Now you could actually use your same laptop and use a proxy into the overall network.

Paul: Yeah.

Grant: That's a huge advancement. What an improvement, right?

Paul: What's funny about VPNs is there are some companies who do a very good job of maybe managing their VPN, but for a lot of companies it's a carte blanche access mechanism. You get in the VPN you can access every app, even if you really only want to access the Wiki from home once in a while.

The VPN became a one place hammer. You're like, "We're going to put two factor on the VPN,"or "We're gonna do X to the VPN layer," but then the VPN really only understood layer 3 layer 4 protocols.

Grant: When I first read the BeyondCorp paper I was actually confused, I was like "Wait. People just put these services on their internal networks and then don't put any authentication in front of them? And you just need access to the network, so all the communication is unauthenticated? And then you can access it from a VPN, which you used as your authentication layer?" I was like, "That doesn't seem good."

Paul: If you look at incidents, security incidents over the last 10 or 15 years it's definitely not good.

From an attacker's perspective, from a threat model perspective, it's open season.

Because the only thing is, once you're in the network you lose identity, actually. When you make a request the Wiki, the Wiki doesn't know who you are. From an attacker's point of view it's a huge advantage. The request to the Wiki was never authenticated and authorized to go to the Wiki, it was just that some laptop got on the VPN.

Grant: Right. "It's in this trusted network. Now it can access it." What it's doing, you don't really know. You just know that it's--

Paul: That's right.

Grant: Doing stuff inside the VPN.

Paul: Yep. So then, but by the way because you had this architecture people build products to try to make that better. You have a whole generation of network packet inspectors. There's a whole category of products where their goal is "Let's look at those packets that the VPN can't understand and try to understand them." This is what I'm trying to articulate, is the old architecture, we just kept trying to patch it.

We said, "OK we are going to start with network ACLs. Every time there's something that doesn't work well about that, we're gonna invent a new product category like VPNs or VDI or deep packet inspection to try to make it so we can keep using network ACLs.

Grant: Because you have a system set up, and then you realize there's a problem. So you try to solve each of those problems incrementally as they come along, rather than questioning the entire system. Because that sounds expensive and complicated, and like a project that no individual sane person at a company is going to undertake. As like, "I'm going to totally remove everything that we've ever done in this space, and invent something new."

Paul: Yep.

But that's the basis of a movement, right? It's a generational shift in technology.

Grant: Eventually it sounds like what happened was, at Google, this thing got so bad and they realized that the current system was so fallible and terrible that it was unsaveable. This like big project Aurora, is that what it was called?

Paul: Operation Aurora.

Grant: Operation Aurora, comes in and exposes this, and everyone's like "We can't protect against it in our current model. We're just not there yet. So let's throw it all away and start--"

Paul: And Google wasn't the only one to come to that conclusion. It's just, when you're Google, you're able to put a large number engineers and security people on it for a while. Then a few years later, after it works, you can write a white paper about how awesome it is.

Grant: They don't write white papers about the ones that didn't work.

Paul: That's right.

Grant: You only read the white papers about the projects that went really well.

Paul: That's right. And if you look at even like Forester who wrote some analyst papers back in 2010, but they coined the word "zero trust." BeyondCorp was the Google project name for the internal development of the system, and zero trust was the broader industry wide message around that whole network perimeter thing. Like, you can't base trust decisions based on that.

Grant: I think we eventually started to refer to it as what, "Hardened shell, gooey center."

Paul: Yeah. Castles, moats. All these analogies, they really actually describe how it fails. Everyone understands a castle has a moat and once you're through the moat everything's over.

Grant: But I also do think, whenever you're looking at these enterprise problems, it's important to go back to the beginning and be like "This made sense. This was fine. It was totally rational, you're not dumb people for having thought that this was a good solution to the problem at some point."

Paul: Yeah. Constraints changed.

Grant: Yeah, exactly. Constraints changed. But like, OK. Now we know that. Let's try to invent the better solution, let's just acknowledge that it's not going to work. Let's not get all defensive and try to be like "But that's what we know, and we have to stick with it. Let's just-- Let's change."

Paul: I love your perspective, but the challenges in any-- Even as a startup trying to educate people around the space, like BeyondCorp, to a group that feels they're Cisco certified, is not an amenable alternative. They're like, "But then I won't have a Cisco firewall to administrator." Like, I'm not trying to take away their jobs, but in some ways I am.

Grant: No, you're just trying to get them BeyondCorp certified.

Paul: Right. That's right. We're working on that.

Grant: Though I guess my perspective is just that everything that's happening, we just have to be more welcoming to change, and acknowledge a change is going to happen.

Paul: Yep.

Grant: And be willing to look at our current systems and be like, "Does that still make sense?" Let's question everything, and if it doesn't, let's build something that does or look for a solution that solves this today.

Paul: Yep.

Grant: OK. Let's dive into what BeyondCorp is. I think we've gotten pretty good at what the problem is and why it made sense, let's talk about what the solution is.

Paul: I tend to think of it as taking it from a layer 7 approach first. So, what are the things we want to accomplish in a layer 7? Authentication, authorization, encryption, all the things you'd expect when you go to a consumer website. It's encrypted.

When I log into my bank they know who I am and I'm authorized to only mess with my bank account, so how do you take those kind of concerns and make them something that can be platform sized? So that it's not up to every app to implement them themselves?

The traditional enterprise stack would be like if I'm deploying a new enterprise app, I'd put in my own load balancer, my own firewall, my own WAF. I'd build all the ACLs myself, I'd build a custom SAML integration if I'm lucky, or I back into some LDAP server. We want to take that whole stack and make it a platform feature.

You could describe it almost as building all those features into the load balancer. That was, I would say, a big chunk of BeyondCorp.

Grant: That's that access proxy.

Paul: Yeah, but I think a lot of the other parts are more implementation details, like how for you as a company do you manage devices? Or how do you assert trust about different factors? But that is the core bit that I think is actually the thing you need to repeat first, is like "How do you try to consistently implement authentication authorization and encryption?"

It's like, "How do you make your front door a really good front door?" Even though we're trying to avoid analogies about castles and front doors, try to almost productize that little component. Then around that you see Google did a lot of work on what people are calling device trust. Like, "Can I trust that this MacBook Pro is up to date and patched?" And all these other things.

But I tend to view those as really factors for authentication and authorization, their inputs to your decision, just like a U2F key is a good factor. Maybe a Chromebook having his own TPM is a good factor, but those are really inputs to authentication and authorization.

Grant: OK. Define authentication versus authorization, so everyone has the same context.

Paul: The problem with that is I'm contrarian on the view of authentication. Authentication in theory, like a Wikipedia definition would be identifying who you are. That you are Grant, and Grant has this job and this title, it's almost a directory lookup. It's like, "What are the things about you?" It's really just trying to establish that, like who you are.

Then authorization is, "Are you allowed to do something?"That's the traditional split of kind of auth-n and auth-z. First you just focus on who someone is, and then you focus on "Can they be allowed in?" The reason I'm a contrarian on those is that authentication is not absolute anymore, and the factors that we use to determine who you are are relative.

You remembering a password, a password you share with 400 other websites, is a very bad authenticator. Any one of those 400 websites can take your password and use it again. A U2F key is a pretty good authenticator. It is cryptographically secure, it's a little device. Unless someone steals your key chain and also knows your username and your password, that's a much better authenticator.

I tend to think of authentication as relative. Like, there's different levels to it. But that, in a traditional sense, would be how you describe authorization. That MFA is traditionally thought of as an authorization step. You need MFA to access the site as like an authorization statement, when it's really asserting that your authentication is stronger. So, I think they're actually highly intertwined, and if you look at how people write authorization rules they're often making assertions about how good the authentication was.

Grant: Interesting. OK. So, just to add to the confusion, they're even more intertwined than most people think of them? Because some people think about them interchangeably.

Paul: Right.

Grant: In most of the world, authentication and authorization, you could use one word instead of the other. In this context they generally mean different things, but in your perspective, authentication is a spectrum?

Paul: Yeah, and how much you want to trust that spectrum is an authorization decision. Like, I'll let you into the phone directory for the company even if you just know your password, but I'll only let you into the Wiki if you MFA, or if you have a U2F key, or your boss approves to let you into some finance app. Those are attestations of identity in the traditional sense.

Grant: All right. It touches on a few points around how this is a complex topic, and authorization and authentication are-- Maybe there's not a totally defined world where everyone thinks they mean the same thing.

Paul: There is, in a canonical Wikipedia sense.

Grant: OK.

Paul: Right. Like, clearly authentication is just who you are. I just think one of the things you really need to understand about the BeyondCorp thesis and where we came from, from network identity. Network identity used to mean your source IP. That was a good enough identifier, that was your auth-n, you came from an IP address. What I'm trying to say is password as your auth-n factor is flawed.

Like, most people would agree today that password authentication is flawed. We're like, "U2F is better." "Well, today it's better. I don't know if it's going to be better in 30 years. I hope it's better in 30 years." These factors are changing continuously based on our trust levels of them, and that traditionally is an authorization point of view.

Grant: OK. I like that from a timescale perspective, it's like, "If we look at everything, even authentication as an authorization, that's a time oriented and delineated piece then we understand that while that is the strongest form today it might not be the strongest form in 30 years."

Paul: Right.

Grant: OK. So, let's go back to BeyondCorp. What does the end to end experience look like on BeyondCorp? I think we understand what the end to end is for network based ACLs and all that, just describe the end to end on a BeyondCorp zero trust system.

Paul: From my point of view the end to end is, as a user, I go to a resource. Whether that's a web app or something else, and transparently to me, a bunch of magic happens and then I'm logged in. That thing that I'm logged into, whether it's the Wiki or some other app, it knows about me and knows what I should have access to. That connection is encrypted and safe and audited.

That's the end to end experience. It's really describing almost "What is it like to log into a SaaS app that has SSO set up?" It's pretty close to that and in some cases you can even make it better than that. You can actually get rid of a lot of prompts for people to re-enter their SSO password. We can actually eliminate a lot of that.

So, I think of it from an end user perspective. It's very crisp. I literally just go to whatever I want to go to, and I'm logged in.

Grant: So, there's there's no VPN, right?

Paul: No, yeah. I open Chrome. The Google point of view would be like, "Chrome is the basis of all this." But yeah, you open your browser and you go somewhere. Now if you're not trusted, because you don't meet the access policies from a security team point of view, from an internal engineering point of view, the viewpoint is very different.

But I'm just trying to say from a user point of view it's a very clean, crisp experience. It's either you're in, or if you're not allowed in, we try at least in our product to tell you why. "You weren't allowed in because your OS is not up to date anymore. Apple came out with a patch five days ago and you haven't patched yet. If you want to self remediate that, we'll help you do that. Some things you can't self remediate. You need to go down to the helpdesk and they'll fix your laptop for you."

Grant: OK. That makes sense from the end user perspective. It's a seamless way to authenticate and the app knows who you are, so it can give you access and you know who's doing what in your internal applications.

Paul: Yep.

Grant: But as a product folks, what does it look like on the implementation side? What's happening? What are the details in this?

Paul: Generally you have, in the traditional world, you use a policy enforcement point and access proxy. It's somewhere that you're centralizing control, you're treating it almost like a cloud feature.

Like, "Amazon has load balancers. We have access proxies." All my apps just go behind those, and once they're behind those it's that component that deals with authentication, authorization and encryption. And the policy mastering.

The security team, most large enterprises have a information classification document. They say, "People's personal phone numbers are classified as low, but any customer data is high, and if you're accessing something high you have to have MFA'ed within the last hour."

Grant: Generally this is-- There's like a NIST matrices that describes this, and it's basically looking at confidentiality--

Paul: Impact--

Grant: Availability, all these these different factors. Then you grade them on low, medium or high, and if it needs to be highly available and it's highly sensitive then it's classified as sensitive data, or something.

Paul: Yep. That's like-- Most companies have some kind of classification. The reason they classify is actually to derive policy, and your CIO or CISO if you were a big company signed off on "High means this. These types of documents. It means we have to use these access policies."

That's what the access proxy really enforces, is as an app owner I just need to classify my thing. It's low, it's medium, it's high. I have customer data in there, or no I don't have any customer data. It's the lunch menu. That's my role as an app owner, that I classify my data.

Then the security team can say "OK, great. For everything high, these are our policies. For everything low, these are our policies. For low, the cafe menu, we're gonna let you log in on your hacked Android phone." We just don't care. It's the log in for the cafe menu.

But the thing with customer data, you have to be on a managed machine that's managed by IT. It has to have been patched within the last day. You have to have MFA'ed within the last two hours. All those policy decisions can be driven by a security team based on the information classification.

Grant: And that logic is living in the access proxy?

Paul: Yeah. Part of doing BeyondCorp is you have to understand your resources, in a way. It's a resource aware system. The resources are not hidden here, you need to know, because one of the things you want to do is you also want to create an audit event of, "Grant logged in to the finance system 48 hours before announcing earnings, and then bought a bunch of shares of stock."

You actually want to know that, you want to audit that. So, the audit ability is also related to having a resource graph.

Grant: Then the benefit is there's no VPNs, you're putting that access proxy on the public internet most of the time?

Paul: Yeah, but part of that is also just centralizing responsibility.

I tend to think of it as if you have one team that is good at running one thing on the internet, it's way better than having 100 teams running individual things behind a VPN.

In most organizations to deploy BeyondCorp there's a small number of people who are actually responsible for their access proxy equivalent.

Grant: OK, so it's a shared resource across all these different teams, and they're able to--?

Paul: "A center of excellence," to use a sure big company word.

Grant: OK, and this is used primarily for employees to access internal tooling, correct?

Paul: Yeah, that's where the origins started. That's what Google described in a white paper, is that it's all about employees and contractors. But even some of our customer base, if you acquire a company and six months later you're trying to give them access to random things, you don't want to give all 5,000 people and the other company access to your VPN.

So, yeah, it's employee access and contractor access, but I think in the context of "What do you trust? What are you trying to assess about a person? How do you classify information and how do you classify an access attempt?"You'll see in the consumer side that this already exists, like how fraud detection is done for credit card transactions is already not trusting your IP address very much. They know that the bad guys can fake an IP from San Francisco.

So in the consumer world a lot of these concepts about "How do you derive trust? Do you trust a factor more than another?" Already exists. Google does it in Gmail, like if you fly to Hong Kong it's going to ask you to MFA again. Consumer products already deploy a lot of these techniques and they just take the IT version of it and make it more employee centric.

Grant: Taking advantage of some of the-- You have more control over the environments that your employees compute and access things with. So, you can use accessing an internal tool as a impetus to get someone to apply a security update on their laptop, or on their phone. Right? To update to the latest version.

Paul: I view it as "Self remediation, whenever possible, is helpful." Google published some numbers about this in one of their later white papers that they saw a 30% reduction in help desk tickets. And that's just about having a context of what the user is trying to do.

When you're on a VPN, your VPN either successfully connected or it didn't. There's very little room for helping a user be like, "We're not letting you into the Wiki today because you haven't updated to the latest iOS." In the access proxy world you can actually return to them an HTML page, it says "Here's what you need to do to go fix it."

Grant: Instead of every application needing to do that same thing, it's like "Just put that in front of, even accessing the load balancer, you need to hit this access proxy first, which does this core screen to access control to verify that you've got the latest system and we know who you are. Then you can start to go into trying to access the internal resources."

Paul: Yep. That's right.

Grant: Cool. One of the other things that I think is really interesting about this from stepping back out of the details of BeyondCorp implementation, is ScaleFT's adoption and flag carrying of this topic.

When I look at enterprise software companies one of the important go to market techniques is this movement based marketing, where you want to create a movement in order to get other folks to sign on to what you're doing. You guys didn't work at Google, you didn't write the BeyondCorp papers, you didn't do that.

But you took the flag for BeyondCorp and you really brought it to life in an ecosystem.

Paul: From a startup point of view it's an efficiency argument at some point. You're always gonna have less capital than some public company you're competing with, you're always going to have less people for a long time. My belief around movements are is you get a spin wheel going, where initially it's really hard.

You're trying to do your first meetup and three people show up. That was our first BeyondCorp meetup. We were like "OK, how do we get 10 people next time? How do we get people who are interested in this topic? We know that people are interested in this topic, some of them follow me on Twitter. How do I go get them to come to the meetup?" Next time ten people showed up, next time 50 people showed up.

It builds upon itself. That's why you want a movement. So in theory, two years down the road , your cost of acquiring a customer is lower. That you are known for something. Part of that in the context of enterprise software is customers they need to have both a need for your thing, and they need to know about you. You can make the best damn--

I don't know, some container product right now, or best service mesh thing in the world. But if it has one star on GitHub and no one knows about it, it just doesn't matter. So I think the movement thesis we had was "We got to make some good products. We got to be interesting and we got to fix actual security problems."

But when an enterprise realizes, one, they have a need, and they do all the time. Everyone's always redoing their VPN architecture or deploying a new app on EC2 or whatever. But they have to then, two, also know about us. They need a friend that said "Did you read that BeyondCorp thing?" Or, "Did you go to meet up about this, or see some tweet about it?"

They need that first intro to your ecosystem, and a movement or movement oriented enterprise software is a pretty efficient way to do that.

Grant: Yeah. You did a few really interesting pieces around it, though. One is that you've literally adopted it from Google. You took their white papers, you built a website around it, you published it. Like, I mean--

Paul: Yeah.

Grant: You didn't probably have permission to create the website and stuff, you probably just did it, I'm guessing.

Paul: Yeah. We did it. We knew one day, Google, and they did, they said "Come visit us." And you don't know. Are they going to be angry or happy? I think in Google's case there are many different parts of Google, and some parts are really excited and some parts are confused.

Grant: Their marketing team is like, "We were gonna do that someday."

Paul: Right, "Someday."Then the people who actually worked on BeyondCorp was like, "That's cool. We're happy to see more people like this idea."

For us, we just tried to keep it really clean, we weren't trying to be slimy. We were just trying to be like, "This is a good idea. Google gave it a word and described how they did it, but how are you going to do it? How are you as a Fortune 1000 in the Midwest thinking about these problems?"

Trying to frame it in almost an iterative model, like Google is an example of it working. That is where we really tried to frame a lot of our content marketing. "Google shows us that it can be done.

They showed us their vision of it, but you're not Google. You have way different constraints, you don't make Chromebooks. Google has some advantages here. So, how are you going to take some of those core ideas and apply them in your own business?" That's right sizing the message in a lot of ways.

Grant: Yeah. It's just an interesting way to do it. Say, "Google wrote a white paper about it. We think that's really good." It fits. You didn't start a company around the BeyondCorp paper, you had this company going and you realized the thing that they were publishing was pretty much in line with what you were doing.

Paul: Yeah.

Grant: Something that you said before we started recording was that it helped you establish context. Right? So, talk about that a little bit.

Paul: I think as a startup you're always told, "Make your elevator pitch." What is an elevator pitch? It's really a compression of what you do. You're trying to have one sentence, "We're Uber for microphones," or something. What does that even mean?

You're definitely not Uber. They're valued at $100 billion dollars and they have tens of thousands of employees, so you're not making microphones that are like Uber. So, you're trying to compress it down.

What we found is BeyondCorp was a pretty good compression word for us. It compressed down,"How are you actually thinking about authentication, authorization and encryption? How do you actually implement that? Are you doing it in this old school way, or are you doing in this new school way?"

If someone talked to us and they had already read the white papers, we said "We're doing BeyondCorp style stuff but for DevOps." It was a super easy conversation. It was a great compression word that just got us over the hurdle of, "No we don't need to explain why static passwords are bad for the first 30 minutes of the meeting."

It lets you just move really fast, and you need things like that as a startup. Your time is really valuable, and also assessing if a customer is ready for you, especially in the enterprise context, is so important.

The worst thing is to work with a customer on and off on the enterprise timeline, and then a year in they're like "Actually guys, you're just way too far out there for us." You want to find people who already read the paper, already believe in what you're doing, and are like "How can I bring that into my big company?" That is a huge leg up down your funnel.

Grant: That's a great point. You create this aspirational thing, they did a great job naming it, the papers were really helpful. It puts this new concept in. It does it in a very academic Google-y way, and then you can say "Here's the first steps to implementing this."

Paul: Yep. We viewed Google as like, not to say Googlers are certain ways, but Googlers are like summiting Everest. They're way out there, they're summiting Everest without any oxygen. We're going to help you get to base camp. It's beautiful up there. It's still something to look at, it's still way better than where a lot of people are. Let's get you there.

Grant: Yeah. You're not going to build your own hardware and rack all of your machines and recompile every bit from the ground up for everything you compute on.

Paul: Right. But we can make it harder for when an employee leaks their password for bad things to happen.

Grant: Yeah, right.

Paul: We can use this new architecture to do that.

Grant: Take care of the things that actually happen a lot that we don't have great solutions for and make that like, "Here's the first steps."

Paul: Yep, that's right.

Grant: OK. So you take this thing, you get it moving, and then you get acquired. Now you're inside of Okta, which is a publicly traded company.

Paul: Yep.

Grant: And Okta's core business is sort of around kind of single sign on, SAML concept, right?

Paul: Yeah. They call it an identity cloud, but yeah you nailed it. I'd summarize that its growth engine for many years was, "How do I SSO into Salesforce?" Which is a great growth engine, because everyone was buying Salesforce.

Grant: Right, and I think the team from Okta started at Salesforce.

Paul: That's right. The founders are both from there.

Grant: Maybe even, I know there's definitely some pieces of the SAML protocol and SCIM protocol, which is written by Salesforce. They helped to lay the foundations for these things too .

Paul: Yep.

Grant: OK. Now you're inside of Okta, and what are they doing with their product? Are they going to scale it out to more customers, what's happening?

Paul: It's an interesting process. You go from a startup mindset of like, frankly "How do I get one new customer at a time or two at a time, or how can I go to a conference and meet the right people?" to, "How do I arm 1,000 salespeople with the right thing and how do I scale this to thousands of other existing customers?"

There's technical scale challenges, you have to grow up real quick. Thank goodness for the cloud, in general it makes our lives way better. There's a lot of collateral challenges, like how do you educate a lot of people?

They know about SAML, they know about SSO, but they maybe don't know about BeyondCorp very much or about how privileged access management has traditionally been talked about you know. There's a big mix of scaling challenges there that hit throughout an organization.

Grant: I just had this realization that maybe SAML was how you interacted and got access to external applications. Do you think about BeyondCorp as how you get access to internal applications in zero trust?

Paul: Yes. The summary version is "Yes." I think what we're learning though, and this is one of the reasons Okta acquired us, is they wanted to take many of the techniques we were doing for internal applications and apply them to external applications as well. Where the access proxy, in the same way that SAML works.

You want to take all of the device context, self remediation, real time awareness, dynamic policy stuff that you had in this internal world, and you still want to apply it when you log in to Salesforce. Because it is, again, back to the CSO's world view. They just mark things as low, medium or high.

If Salesforce is high, you need all the same policy enforcement there. So, yes, they're just both ways to enforce policy but I think we're learning from the BeyondCorp world how to make those things exist in the SAML SaaS world.

Grant: Interesting. The lessons from that internal, and access proxy for internal resources, taking that and applying it to how you access external resources?

Paul: Yep. You want very similar outcomes.

Also, companies are modernizing. Very few companies build everything themselves, and at the same time very few companies are 100% SaaS based. Almost everyone has both.

Grant: I obviously think that the world will continue to leverage internally hosted applications on a VPC that you secure with BeyondCorp, but you'll also access external applications that you integrate with SAML and there's probably some combination of the two technologies that happens now with Okta and you guys together.

Paul: Yep, that's right.

Grant: That makes a lot of sense. OK. What I want to dive into though is I think there is this really interesting piece around go to market. From a startup perspective you're like, "OK. We got to build this movement, we've got to get a few people to believe the thing that we're doing and create advocates, and get 10 people to show up to the meetup, and be very brute force."And, "How do we create something from nothing?"

Paul: Right. Zero to 1.

Grant: Zero to 1 all day long. Now it's like, "OK. We're inside of this bigger organization. What do we need to do process wise to systematically enable this organization to be successful with this product that we've built?"What does that look like for you right now? Tell me about that process.

Paul: You have to align to how people already consume content, or how organizations already work. A lot of what we're doing is aligning to the big beginning of the year sales kickoff right now. Like, "How do we go into sales kickoff with everything figured out, so that as a salesperson they're fully enabled to really hit all their accounts with it at the beginning of the year?"

Grant: So, first of all, that sales kickoff is sometime not in 2018.

Paul: No. Yeah, it's a different timeline than a startup. You'd be like, "What am I doing on Wednesday?"

Grant: Yeah, exactly. You're planning three months out, minimum.

Paul: Yeah. Everything's like that, but because you have salespeople in Australia wherever, it's a different type of scaling. It's good and you can get a lot of leverage out of it. I'm excited about that. So we're trying to align two ways they already consume information. You can't force them to do new things.

You can't be like, "We're going to do sales education differently than the rest of the company." Like, "No. You've got to do whatever the process is."

Grant: What does that process look like? At sales kick off, what do you need to deliver for that?

Paul: All kinds of collateral. I can't emphasize it enough. Battle cards about how you stack up against a competitor. Context setting, slide decks, "You've never heard of anything on BeyondCorp? Here's a level 1 deck. Here's a level 2 deck of a little more in depth, here's a level three of really in the weeds. Here's how you enable people the edge to listen for the right words.

What are the things that customers say to be qualified? How do you qualify them, what what are they going to say? What are they going to talk about, what problems are they going to describe that they have to know that this product is the right fit?"

If they say that, "What does that person then do? Do they bring in a specialist? Do they say, 'We're gonna connect to you for 30 mins with a specialist next week.' How does that whole thing get rolling?" Really trying to turn that into highly repeatable in a way.

As a startup you hack it until it breaks. You don't have the luxury sometimes for this when you are dropped into a big system.

Grant: Right. So, first of all, battle cards. You said that. That's how you stack up against a competitor?

Paul: Yeah. So, you would-- Generally you describe their pros, just to be honest even to yourself, because it's an internal document. Generally, you're not necessarily giving this to a customer.

Someone in our case, we do a lot of privileged access management and a lot of our sales people spend time on what you'd call the I am market. They're worried about active directory, and they don't know about how some of our competitors really work.

They need a one page or two page fact sheet. "Here's what this competitor is good at, here's what they're weak at, here's how we stack up. Here's how our roadmaps are different." Try to really summarize information so that person, when they're on the phone and someone says, "What about X?" They need to have an answer.

They can't just be like, "I'll get back to you in two weeks." It's a whole different sales experience to then say "Yeah, I know about X. I'm a salesperson here, we're a little bit better in this area and we think our road map is way better."

You can disarm a lot of customer concerns very quickly by being knowledgeable, so you want to build that for people that may not spend every day reading about BeyondCorp. It's scaling that knowledge graph.

Grant: So, you could answer every one of these questions like that someone might have about any of your competitors, any of your road map, technology, everything else. It's just pushing that knowledge to the edge, to the people that are talking to customers regularly, in order to scale all of your knowledge into the rest of the organization in a way that they're used to consuming that information so that it's easy for them to pull out the battle card and review it before the call.

Paul: Yep, and it's not a perfect process. You'll get questions that get pushed up like, "Customer X just asked 'How are you dealing with TLS10 deprecation?' and I didn't put that in the FAQ because no one had ever asked yet."

There's some work you can do ahead of time, you know these things are going to pop up, and then there's always just stuff that you didn't know someone would ask.

Grant: It's stuff you have answers to, or you can figure out the answer to, but--

Paul: Yeah.

Grant: But generally you're trying to capture all that and enable people in a way that they can then have those conversations and feel successful and stop having to-- Because there's going to be some amount of stop and go. OK.

The level 1 deck, then the level 2 deck and the level 3 deck. You're not going to go through all of those in a single meeting, but you want to have it escalate correctly where at least the first hundred people can go through Level 1. Then maybe there's 20 people that can do Level 2, and there's 10 people that do level 3.

Paul: Yep. It's subject matter experts, depending on how you phrase it internally.

Grant: Yeah. It's not just about enabling that sales team though, there's other organizations that you're enabling along the way.

Paul: Yeah.

Grant: Like, support might be one.

Paul: Support's a great example. Especially in enterprise context as well, especially for Okta as a product is authentication related. So if Okta is down you can't log into anything else, you have to be good at support.

When a customer calls on the phone and says "X-Y- Z user can't log in. I think it's your fault." You need to figure out real quick if it's your fault, and if it is, fix it right and communicate clearly and accurately with the customer. Update your status website, and all these processes that are built as a company grows.

The first time that happened there wasn't great process for it. As a product that's getting jumpstarted into this, you start with-- Even at ScaleFT, we had most of our customers on Slack channels. Shared Slack channels for both support and technical onboarding, and as you get bigger that's not great.

You can build tools in Slack, we had all kinds of slack bots that would track SLAs and "Are we getting back to someone fast enough?"But they're used to working in shifts and having tickets, and having queues that they work through.

That's a much more at scale approach to support. So we have to go into their world again and say, we're gonna start with "Let's use your tools. Let's get our team on your ticketing system." When a ticket comes in that's related to our products, phase 0 that we basically started with, we'll take the ticket and we'll try to figure it out. Just as we would a Slack request from one of our original customers.

Over time you try to layer in "OK, there were eight tickets about some feature. Let's write a little knowledgebase article about that, an internal article, turn that into an external documentation as well and processize the whole thing. Eventually you're not handling basic questions, and eventually they become harder questions, and then eventually they're like "You just end up getting bugs," which is great.

Grant: Because unless your support team can fix your bugs which should be pretty great--

Paul: That would be great too.

Grant: OK. That's super interesting. I think that the idea of taking something and enabling these other organizations with your teams within your larger company to do the specialized thing that they do is really important.

Paul: Yeah.

Grant: And that's a big part of product. That's what we have to do, is be able to walk and talk between all these different organizations and make sure they have the things that they need, and we facilitate from engineering into these other orgs to make it successful.

Because our previous company got acquired and we were rolling it into this bigger company and working with all their systems, and at first you don't want to let go but eventually you just have to. It's the only way you get sleep at night is by hooking into their knocks, and their-- All these other systems.

The other funny thing is just how similar the structure is at every enterprise software company. Everybody has some type of GA, general administrative, that's you're legal and finance.

Paul: Yeah.

Grant: Then you have your sales team, and your marketing team, and your support team, and customers success, and product, and engineering, and QA. It goes on and on, and the interactions between those groups if you run infrastructure, maybe you have a DevOps or ops team. It's always the same. The funny part is that I've found that the people in those roles often have the same conflict across different organizations.

Paul: Yeah.

Grant: That natural tension that lives between product and sales.

Paul: In every org.

Grant: Yeah, or between sales and marketing.

Paul: But it's also about scaling it. That is how engineers go off for two months and build a feature, and don't have to check with everyone and the rest the company all time, and the same thing with sales. They're gonna go off to Milwaukee for two weeks and try to get a big fish. Try to to land a customer.

They're not going to be involved in every single thing in the company, and you have to let people operate on their own. That just leads to natural goal drift and just differences of short term goals, especially.

Grant: Yeah, it's funny because I think we think about sales enablement and these other pieces, but are you still managing your own infrastructure or have you handed that off so that there's--?

Paul: We have meetings about that often. Right now we're still running our own infrastructure and our own DevOps team.

Actually, one of our leaders last week was like "We didn't have our own finance team. We were a 15 person startup. We didn't have our own finance team. We said we should definitely use Okta's finance team.

But we had our own couple of DevOps people who were really good, so maybe we build a little nucleus there and keep growing that little group into their own DevOps team, and then I think that's the same thing with our sales team. We had two salespeople at ScaleFT at the time we were acquired, and they're becoming our specialist overlays for our product across many other salespeople.

It's almost like for each one those orgs you figure out "What are you going to keep independent and run as its own way? What are you going to take from the bigger company's existing processes?"And I think it's just org by org and case by case, and size of your group. You just decide. I don't think there's any hard or fast rule.

Grant: No matter what, you're making some of these decisions as a startup. You're like, "We'll outsource our finance, we'll--"

Paul: One of my co-founders, Robert, we're like "Robert, do you want to do basically support and customer success, just for like six months while we figure it out, and then we'll hire somebody to customer success in a while? Just because we're all busy."

So he's an engineer, and he's like "Sure. I'll do support and customer success for six months, we'll hire someone in six to eight months and go from there." It was nine months. We hadn't hired someone yet and then we got acquired, and he's now the support guy. He's like, "No dude. He's like an engineer with 20 years of experience. He's not the support guy. He's a founder. Let's get him back in engineering." We're like, "Shit. He has to hand off and scale support knowledge before we really get him back."

Grant: Yeah. It just says "Never take the support role for your founders. It's a risk you don't want to take."

Paul: Yeah. You're gonna end up running support. That's just how I think a lot of founder stuff ends up being.

Grant: But it's also so important, because if everyone does the sexy cool job you're never going to do anything. You have to put really smart people in charge of the monotonous grinding, hard tasks like doing support really well, or doing infrastructure well, or doing any of these pieces. Like QA. The funny thing is, these are the hardest roles to hire for because engineers want to do engineering things.

Paul: Yep. As we were hiring engineers the engineers got to do engineering and the founders got to do all the other stuff. That was our first four engineers, they basically just worked on engineering and then all that did was free up founder time to do other stuff, not engineering.

Grant: Yeah. I think that many times founders don't really realize that's the life they're going to live.

You start a company maybe because you love building great products, and you have this experience, and you want to see something come to life. Maybe you build the first version of it and then eventually you're handing off all of the like stuff that you thought was fun, and you're diving into "How do I scale up customer success organization and support organization, and a sales team? And go raise money?"

Paul: Or, "How does pricing work?" Or like a thousand questions.

Grant: Yeah.

Paul: You've got to learn how to-- As you get bigger you're also trying to recruit and find people to take over those things too. Very rarely is it permanent, but for that next six months you are customer support or you are in charge of finance. That's just how I think of it as, you specialize in something for a while and then try to find the best person you can to take it over.

Grant: Yeah. Real quick, just changing subject on to the-- I'm going to take a guess on how your acquisition happened. I have no idea if this is correct, but I just-- Based on my knowledge I'll see if I can nail it.

I'm going to guess that either you or they reached out in a partnership-y type of idea. You spent a little time spec'ing out what it would look like to build something together, and then eventually they were like "We should just buy you."

Paul: That is directionally how it went.

Grant: OK.

Paul: I think what happened with us is, I would say we--

Grant: It probably took a while to negotiate the deal, but at some point it happened.

Paul: Yeah, it takes forever. But we started out with our pipeline, and when we started we didn't have any customers using Okta, but as we were getting bigger I think at one point we had like 70% of our pipeline was already an Okta customer. We could ask someone and they were like, "Yeah we use Okta."

Especially in enterprise. The bigger the company got the more likely they were already using Okta, and that was the overlap that drove some of the deal. We were talking to very similar buyers. Even if it wasn't the exact same person at the company who bought Okta, they sat next to the person who bought Okta.

Grant: Had you created some type of integration first?

Paul: Yeah. You could log into our product with Okta, we were doing SCIM integration with Okta. A lot of protocol level integrations.

Grant: You're one of the four companies that have implemented SCIM, I see.

Paul: Yeah. If you want the go bindings we have an open source library for that.

Grant: Cool. Obviously the enterprise ready site talks about how to implement single sign on, and SCIM is this protocol for actually provisioning and deprovisioning users based on the SAML world, right?

Paul: Yeah, and group objects as well.

Grant: Right.

Paul: Groups are actually where it gets more interesting, because then you can do kind of delegated permissions. Just getting users there is OK, but when you start doing groups is where people find the value.

Grant: Interesting. The reason that I always thought it was valuable is because single sign on was never really populated user tables, or it wasn't designed to. It was designed to get you into the thing. So, if you had a user table, how did you know who was using it and what they were doing? People would do something called "Just in time," or "Real time provisioning of users."

Paul: Yep.

Grant: Which was a hack, and then you didn't really ever de-provision that user, you just let them not log in anymore.

Paul: Actually the context of SCIM is going to continue to be more important as you think about a lot of privacy regulations and other stuff, like you actually need to deprovision a user when someone leaves a company. You can't just keep their data around. In general we're going to see more protocols like this, because just keeping data forever is not cool.

Grant: Yeah. I mean, it just makes sense to not have users around after they don't work there anymore. Because oftentimes seat based pricing and things like this become a reality. OK, so we're back to the acquisition.

Paul: Yeah.

Grant: The reason I suggested that is because oftentimes people will ask me, "How do we sell the company?" And it's like, "My opinion is you don't just go sell the company. You build a relationship with potential acquirers, you start to figure out like what's interesting for like an integration, business development deal. Eventually they realize that the thing you're doing is very complementary and maybe there's an opportunity for them to sell it to their existing customer base."

Paul: Yeah.

Grant: The value is the thing that you have, if they can go sell it to all of their customers, it's worth a lot more to them than it is to you.

Paul: That's right. That's the board deck at some point. "We're going to pay low price for them now, we're going to take their thing and sell it to 4,000 people by the end of next year," or whatever the exact numbers are. And that's using their existing salespeople that you're going to go educate. That's the argument, is that they have a an efficient way to sell your product, actually.

Grant: Often at a higher price and faster.

Paul: And bundled in all the contract mechanisms, and Okta has their SOC2 type 2 report, and we didn't as a startup. That's actually a barrier to a lot of our deals. I think a larger company, just having things like compliance already done, it makes deals easier.

Having already the contracting done, already went through procurement at a Fortune 500, those things matter a lot. They're barriers and they're what makes doing a small enterprise startup really hard. Big companies skip those, so if you're product is in the right place they can see a lot of value in it.

Grant: When we got acquired the company that acquired literally sold our product like three weeks later for like 100x the price that we were charging. We weren't charging enough, obviously, but they were able to really turn it around and start to make more money faster.

It's just easy when you think about the enterprise value that you each have, it's like "In their hands your technology and team is higher enterprise value than if you keep it independent, at least today."

Paul: Yep. And to your point about "How do you get acquired?" It's a long thing. We knew people at Okta for well over a year before the deal happened. It wasn't an overnight thing. But you also want to be out there, you want to meet people in your industry too.

One of my good friends and co-founder Jason had no fear calling anyone from any other company and just saying "We're ScaleFT and here's what we do." You need to be out there and saying "Call your competitors. Talk to them, go have beers with them, they're people too. It doesn't need to be a big-- You're not enemies. Go meet the people in your industry."

Grant: Yeah. It's particularly true for the bigger companies that are your potential acquirers in the end, because even though it's not a popular topic, it's important for founders to have relationships and to know what their options are.

Paul: Right.

Grant: You're not building this thing to get acquired, but the idea that you understand and you know who your next potential venture capitalist might be, it's good for you to know who your next potential exit might come from.

Paul: It's not about the exit in my mind, it's even just understanding how they think about the market. If they're like "We're only doing fed ramp and government customers now," I'd be really scared. "What do they know about the market that I don't know?"It's just market research, and people are people. They'll tell you what's going on.

Grant: Yeah, you're right. So it's the advantages you get from spending time with them in person understanding how they're thinking. You get to formulate your opinion even more on other smart people who see the market and see everything else that's going on.

Paul: Right. And if you ever are in a situation where you get acquired, like those kind of sessions you can't just email corp dev at Microsoft.com and get an answer back in twelve hours, "Are they interested?" To your point, you need the relationships if ever it does happen.

Grant: Yeah, it's just one of those things that's not talked about a lot. But I think part of the goal of this podcast is to talk about the things that don't get talked about, and that's one of those pieces where I think you just have to be thinking about a little bit, know who's out there.

Because it's also like, there's companies that you might want to acquire. You might raise the next round and think about acquiring, and that's who's thinking about acquiring them as well. So you should be just constantly in tune with that side of the equation.

Paul: Yep.

Grant: Cool. So, one thing if you're up for it, I've had a handful of guests do it which has just been fun. I would love to hear how you pitch what your product does and why it's important to people.

Paul: Yeah. It's actually hard, because I'm like in the middle of like re-pitchizing it to how Okta would approach the problem.

For ScaleFT, I would say pre-Okta, we started with "How old is your SSH key?" Especially if you're talking to a DevOps person or a sysadmin. And you're like, "How old is your key?" They're like, "I don't know. I generated it like two or three years ago." You're like, "Are you sure? Can you prove that to me? How does your coworkers do it?" They're like, "Actually I don't know."

But then some people are like, "My key is 8 years old." And you're like, "Wait a minute. You've had a key for eight years, have you had the same laptop for eight years? Have you ran untrusted software on that laptop in eight years?" The answer is "Yeah. I've had four laptops, one of them was stolen, and I run untrusted software on there all the time."

And you're like, "Great." So, you have this thing. An SSH key. That's the key to your kingdom. You statically install it on a server, and given that private key you can log into that server. You have no way of testing to where that key's been, who's laptop it has been on, who else has it.

As an attestation of identity it's really bad, so what does ScaleFT do? We move that attestation to be a dynamic real time thing without static keys.

We make that from a static problem to a dynamic problem, and that's really what we do. We make key management and access management a dynamic policy driven thing.

Grant: Perfect. That's great. Also, I acknowledge and love the challenge of how you're like "No, I'm in the process of re pitching it in this new context."

Paul: Yeah.

Grant: That's hard. We're going through, at Replicated, a-- I call it product extension where we built this new thing and now I'm trying to tell the pitch in the story in context, that includes that new thing, which from 100 feet away might not seem like it's consistent with what we do but when you hear the whole story you're like, "I guess that makes sense."

Paul: Yep.

Grant: But it takes a lot of effort to craft that message in a way that is consistent and makes sense with like this larger organization. As a side note, I would potentially just talk about how internal authentication-- Like internal app versus external, and you're bridging those two worlds or something about that.

Paul: Especially in the context of Okta, that is what I was trying to get to. In the context of Okta that is 100% the story.

Grant: Right.

Paul: We're taking this dynamic policy driven world, applying it to both internal resources and external resources in a consistent way using device trust and MFA and U2F tokens, and driving user adoption or those things. Okta has all these features for a workflow around rolling a U2F token and getting it verified by your IT team that it is a valid U2F token.

Those are kind of the features that that drive outcomes for customers, and that's why I was trying to say the Okta world view is exactly what you said It's taking internal resources and external resources and putting them on an equal playing field for how you do policy driven access management.

Grant: That's cool. It's so funny, those two pitches are so different, but the same product.

Paul: Same product. Because, "What does the product do?" "It does some crypto, some RSA operations."

Grant: It's hilarious. The delta between two pitches for the same product, just the context matters so much. "How do you want to frame it? What's the future? How is it going to work together?"It is also a signal to what you're going to be doing more of in the future.

Paul: Yep.

Grant: Because it gives some like, "That's the problem we're focused on. This solves it in this way." But like, that's the problem. It's a little bit different than SSH key replacement.

Paul: That's right, and it's also the difference between trying to win over one engineer and one sysadmin to get your foot in the door as a small enterprise vendor, a more holistic long term relationship story.

Which as a larger publicly traded enterprise software company, you can have that story, but as a small startup they're more worried about you going away.

You almost don't want to tell a big story, you want to tell a really small story. They're like, "Worst case we can replace it." Which is a difference of scale.

Grant: That's funny. So, you think that a smaller company should be cautious about telling too big of a story when it comes to customer conversations, because the risk just gets too big?

Paul: Yeah, the risk is way too big and enterprises are risk adverse. Not oversimplify it, but they are.

Grant: That's actually really interesting.

Paul: And that's also why open source is just an adoption mechanism, it's lower risk because it's open source. Because worst case that startup went away, even though we were going to pay them for the open source thing it's still gonna be open source. It de-risks a large enterprise.

Grant: It's very true. That idea of, "What happens if you go out of business?" It was always a very common question in the early days of Replicated. Partially because we were telling a big story around how we were enabling the future of enterprise software within this organization, and then you're right, maybe it's better to tell a smaller story and then expand over time.

I do have a favorite moment of that, when finally someone asked, instead of "What happens if you go out of business?" They asked "What happens if you get acquired?"

Paul: Yeah.

Grant: And I was like, "This is-- How the tides have turned."

Paul: Yeah.

Grant: "We are no longer worried about us dying, we're worried about someone buying us."

Paul: Yep.

Grant: Cool. Paul, thank you so much. This has been a real pleasure. I really appreciate all of your insight on BeyondCorp. It's funny, we have to spend so much time upfront getting the context.

Paul: Yeah.

Grant: Hopefully for a lot of people over time, that concept, the context is compacted into that one statement and people get it. But hopefully this is that thing that will help them get that in the future.

Paul: Yeah, I hope so.