October 7, 2015
Your Presentation Sucks: A Guide To Better Developer Presentations
Giving a technical presentation is hard work, giving a great technical presentation is a serious challenge. Should you give a demo? Should y...
In episode 7 of EnterpriseReady, Grant talks with Paul Querna, Senior Architect at Okta. They discuss Paul’s founding of ScaleFT and how it got acquired by Okta, the zero-trust concepts they evangelized, and what it’s like to integrate into a vendor’s go-to-market process.
About the Guests
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.
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
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.
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.
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
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."
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
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
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
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.
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.
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.
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.
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."
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.
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.
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,
encryption, all the things you'd expect
when you go to a consumer website. It's
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
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?"
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.
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
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.
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.
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."
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.
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
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--
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.
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
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
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
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--
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.
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?"
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
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.
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 .
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
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
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
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--
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.
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
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.
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.
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.
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
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.
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
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.
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
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.
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
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.
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."
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.
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."
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.
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.
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
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.
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
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.
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
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."
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."
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."
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.
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.
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.
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?"
Grant: And I was like, "This is-- How the tides have turned."
Grant: "We are no longer worried about us dying, we're worried about someone buying us."
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.
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.