Ep. #36, Betting On Infrastructure with Shannon Williams of SUSE

Grant Miller: All right Shannon, thank you so much for joining.

Shannon Williams: Thanks Grant. It's exciting to be here.

Grant: Cool, let's dive right in. Tell us about how you got into enterprise software.

Shannon: I've been in enterprise software now since the late '90s and my first job out of college I actually was a journalism school graduate.

I wanted to be a reporter kind of growing up.

And when I came out, I sort of pinged around looking for interesting jobs, being a kid from the Bay Area all of the most interesting ones were in tech.

The first one I found was at this funny little accounting software company up here in Marin where I live.

That wasn't a great fit to say. It was kind of like it was very old school kind of open source accounting software if you can believe that back in the '90s.

Grant: It's cool.

Shannon: But right away, I found a really interesting job working for a company called Securing Technologies in City that was focused on some of the earliest identity management and access control software for the web back in 99 and I just sort of took off from there getting to work on--

Initially a lot of security companies I worked in--

That company did really well and ended up being bought by RSA Security then I went to another company that didn't like the first web application firewall that one ended up becoming part of Citrix, you know, went on to work on a host intrusion prevention systems and actually I started mostly in marketing as a journalism grad writer.

I got into marketing and demand gen and then picked up inside sales and before I knew it I was kind of craving to start working on the customer side and working more closely on building the companies.

By 2008, I met up with my co-founder Sheng Liang who was just getting ready to start a company called Cloud.com which was one of the first players in enterprise cloud computing software.

So infrastructure as a service software and in Cloud.com we started that in 2008 and had a really amazing run with that company, building that up and that led us to getting acquired by Citrix again second time and spending about three years at Citrix before we started Rancher in 2014.

So I've been working in a lot of ways with the same team on enterprise software for 12 years the same co-founders, same head of engineering a lot of the same salespeople and marketers.

It's been great. It's funny, sometimes I feel like I'm always working on startups and new things but so often working with some of the same people.

So it's exciting. It's definitely a cool time to be working in enterprise software because so many people are, you know, they're actually seeing this as a career they want to be in.

So we've got young people sort of pushing to get in, pushing to join our company and that's been a lot of fun.

So yeah, it's been a crazy journey one that kind of touched a lot of marketing, a lot of sales, but for me, I'm so glad I lucked into it.

I never thought I would end up in this market but one of the great things about being a kid from the Bay Area is you can't turn around without bumping into jobs and in enterprise office.

Grant: And so how did you meet your co-founders that you've been working with?

Shannon: Well, it was interesting.

I had been over in Europe the company before we started this was headquartered in the Bay Area and I started with them in the Bay Area.

And the CEO asked me to go over and be the head of European sales while I was there and that was a company called Solid Core Systems which ended up being acquired by McAfee.

And I spent two years over in UK building up the sales organization there and kind of learning a lot--

For me learning a lot of the chops of how to do sales, how to do enterprise sales.

And then I came back, the economy kind of crashed. It was 2008.

It was like I was sitting over there and the organization was falling apart.

So we decided to cut out a lot of what we were doing in Europe.

My visa was up, so it was the kind of time to look for something else anyway.

So I moved back and the CEO of that company that I had actually moved over to Europe for, he said, hey I don't know what we're going to have but my friend is starting another company.

I think you should go meet with him. And that was Shang.

And it was funny 'cause Sheng and I had actually crossed paths at an earlier software company where he had been a founder but left before I joined.

So I knew of him, but I didn't know him but we knew a lot of the same people.

So we had this great connection through the CEO of that company and a couple of other founders that I had worked with at in other company.

So we sat down and just hit it off really well from the beginning.

And at the time Amazon was like a year old, AWS in the early parts of cloud computing were being built and he was really excited about the potential of building effectively a software platform that mirrored what Amazon did but could be run anywhere.

And that, you know, when you think about it, it's sort of the genesis of a lot of what we've been doing that ended up being CloudStack the product we built there was called CloudStack.

And that then led to OpenStack which was a open source project that ended up competing with CloudStack, but also kind of being heavily influenced by what we did.

And before we knew it, we were off and running we got acquired right around the same time OpenStack started to get steam.

So we were kind of--

We had done really well, grown really fast and then Citrix which was one of the founders of OpenStack acquired us to sort of drive their OpenStack vision and kind of bring it all together.

And that ended up being an interesting challenge sort of living inside of a company that had one vision and they were primarily a desktop computing company trying to get into enterprise software or at least enterprise infrastructure which is a little different than where their strengths were.

And so we spent about three years there working on that project, but it never really took off inside Citrix and at the same time we were seeing some of the challenges that would come to plaque OpenStack down the line which was building these big fully enterprise platforms based on virtualization and storage and networking was a lot more than most organizations can handle.

And I would say by 2013, 2014, it was pretty obvious that that level of IT investment in building up massive automation stacks was probably not going to be the future.

More than likely you would have Cloud dominating sort of infrastructure and potentially something much easier coming along.

We were even running into at the time sort of the need for containers because we were already dealing with one of the large banks who was running a large cloud stack deployment on premise and trying to figure out how to move workloads between that and the cloud.

And I remember playing around with very early versions of containers offering even the free Docker and then 2013 Docker kind of springs into being and it became really obvious very quickly to Sheng, Darren Shepherd my other co-founder that there was a really interesting opportunity here to build a new layer that was much more portable, much easier to implement and could be implemented anywhere.

It didn't require hard infrastructure.

It could be implemented right on top of virtualization right on top of the cloud as a new abstraction and that led us to start Rancher.

And from there we started... Luckily we'd had a lot of success. Our previous company had done really well for its investors.

So we had kind of the benefit... The first time raising was brutal.

I can tell you going and raising money back in 2008 in the middle of, you know, for Cloud.com.

Grant: Oh yeah, this is like RIP good times, right? That's quite a deck that, yeah.

Shannon: It was brutal man.

We must have talked to 30 VCs and we had Redpoint, a good friend of Sheng had just become a partner there loved Sheng, had worked for Sheng, was like, you know, we're in already.

So we already had one just getting one more 'cause they just needed another company to kind of set the price and finding that second one was so challenging but we lucked out, we found this amazing company Nexus Ventures that was brand new, was just sort of getting set up in the middle of the downturn.

They were a VC out of India of all places but they had just opened a Silicon Valley office had this incredible guy Naren Gupta who was on the board of Red Hat new infrastructure cold and was like, yeah, this, I like this.

So we sort of scored this unexpected investment and once we were able to raise our--

I think we raised 6 million maybe back in 2008, you know, we could get going.

And that was always the hardest part for anybody with that first time, that first round getting a chance then you can go do something with it.

Then we were able to do really well there. I mean, we grew really fast. We were able to--

We kind of lucked out. We focused on the telcos.

That was sort of our key thing was all the telcos had big MSP businesses and they were all kind of terrified of being disrupted by Amazon.

So we were able to kind of sell in early before there was even an enterprise private cloud business we could sell to Korea Telecom and British Telecom and GoDaddy was an early customer.

In fact that's where I met our other co-founder Darren Shepherd.

He was the chief architect at GoDaddy in the sort of GoDaddy hay days when they were at buying Super Bowl ads and all this stuff.

He was the architect there that was working on the cloud and he was classic.

He would just keep coming back and telling us how shady our product was.

"Yeah your product's horrible. This thing is just garbage."

I was like, my first introduction to Darren was as a customer.

Like, I'm like, well, look and he'd be like, "I think it needs to be like this. I think we're just going to write our own."

"Honestly, I don't even think we could possibly use yours."

And I just fell in love with him. He's one of the best people I know.

And he was so good at breaking our product and telling us how to fix it and then just fixing it himself.

Once we were open source he was just plugging holes left right and center and yeah, I mean, it was kind of the journey just got rolling from there, but yeah, raising the second time night and day.

I mean, once you've had a, you know, even a--

I mean we first company sold for a couple of hundred million dollars.

So it was a very good outcome for the VCs but it's still kind of just getting going kind of when we got acquired.

So it was a lot easier to raise the second time we were able to raise money before we even really started the company.

So you could-- You had a little bit but that actually kind of was in some ways you're not quite as baked.

We knew we wanted to work on containers.

We knew we wanted to work around Docker but we weren't really sure again you have this ecosystem that was just all over the place.

You had Docker going in one direction. MESA was going in another Google building on Kubernetes but it was brand new.

I mean, I think it was sort of announced a couple of months after we started Rancher.

You had companies like Coros and you had Weave.

And I mean, just lots of little companies building pieces and we were kind of debating between two or three different components working on networking, working on storage and eventually we ended up not being able to sell anything other than a platform.

It was like, you know, when we were looking at it, like God that won't sell.

And that was like we were trying to sell tires to a car that didn't exist.

You know, it was like no one needed storage for Kubernetes before they even needed Kubernetes.

And nobody needed Kubernetes before they needed Docker.

It was like we were at the Docker phase and we were thinking we were going to build tires.

And so the good thing about having worked together is this brutal honesty develops really fast.

And so before we knew it, we almost had like just to show the value of containers we had to build Rancher. Rancher1.O like the first version of 1.O.

And interestingly enough like we figured out in that first version tended to be some of the key things that would make us successful later on.

We figured out that some of the stuff you and I talk about.

Multitenancy, access control, policy management, sort of like one of the key ideas was that at the time their big thinking was, you know, if you remember Mesasphere was talking about the data center operating system that you would have this big board like Kubernetes clusters that would be the core of your systems and you would just, you know, ever run everything in this cluster to be super optimized, very efficient.

And for whatever reason that never really struck true with us based on the conversations we were having with customers we were seeing a much more fragmented reality.

And so our thinking was, no, no, no. You're going to have containers running in Amazon.

You're going to have them running in Google.

You're going to have them running on vSphere.

You going to have them running maybe out at the edge you're going to have them everywhere.

And so we started with the idea of building multiple clusters, but then centralizing management to manage multiple clusters.

And at the time wasn't even Kubernetes clusters.

Our first implementation of orchestration was a project called Cattle that we built ourselves.

You know, we tried to use Swarm. We could never get Swarm stable.

Swarm was kind of out there, Kubernetes existed about like I said, a couple of months into the company.

So we played with Kubernetes, but it was really complex.

And we remember Darren saying, "I don't know if this thing is going to take off."

It is creak man, is very, you know, there's a lot going on in here, but it's also-- It has this feeling of something that by comparison Docker is so easy to understand anybody can wrap their mind around it.

So we were playing around trying to figure out what would work.

And we ended up building-- Starting with Swarm and not having it work.

Darren just one like month build his own orchestrator called Cattle and Cattle actually worked really good.

It was just like just enough orchestration. It used compose as the framework for defining applications.

And we put it out there as this open source project of Rancher1.O and it wasn't like a smash hit by any stretch but it was a good, solid, hey, people just liked it.

It allowed them to spin up different clusters in different places.

They liked the composed version.

They liked that the orchestration was very stable.

In a lot of ways the orchestration architecture wise was a lot more like Kubernetes, but the interface was more like Dockers.

It was this weird hybrid of, you know, kind of how you like using Dockers interface whereas you get into Kubernetes and it's got all this robustness of AJ and really good service integration and things like that.

So it ended up being really for the time a pretty good solution.

We were though, we were pretty convinced we weren't going to be able to--

First of all, we weren't convinced it was better than Kubernetes and it was certainly not as robust and it certainly didn't have the engineering resources behind it.

And we weren't convinced that even if it was a company like Rancher was going to be able to set the standard when Red Hat and Google and soon Amazon and Microsoft were all jumping on board.

So we pivoted pretty early off of that Cattle thing though there are people out there still use it.

I get calls all the time. Hey, can you support our old one-six environment?

We'd love Cattle. From surprisingly big companies running it but for the most part, by 2016, we had kind of gone all in on Kubernetes and we just replaced the orchestrator but that same concept of centralized management, multitenancy, multi-cluster management, policy management, security and then from there it kind of just grew like application catalogs and the UI, all the monitoring and logging and sort of more and more of the CNCF ecosystem started to pour in.

And it was funny because we were never really a leader.

We were always, you know, we were behind Docker, behind Mesosphere, Red Hat was enterprise Kubernetes leader but our product was really good.

It was open source. People loved it once they got their hands on it and we just saw like the steady, slow growth like a thousand new deployments every month and a thousand the next month and a thousand and then we started to close a lot of business pretty consistently as people implemented it and just like the product, it was like, yeah, this is great.

And we had a very open model.

From the beginning we're like, look, we're going to go full open source.

We're going to try to get this thing out there.

We know we're not going to have the reach of Red Hat from an enterprise sales perspective, we're not going to have Google's reach to sell a vision of transforming your company.

So we're going to go bottoms up. We're going to connect to the developers, we're going to connect the dev ops teams.

We're just going to put Rancher in their hands and if they like it, great.

The other thing we've realized pretty early that I think was quite different from others is we realized that our distro of Kubernetes wasn't any better than your distro of Kupernetes.

Like a distro of Kubernetes is just a distro Kubernetes.

It wasn't like we knew Kubernetes better or had a better Kubernetes.

We had a Kubernetes distro, but we really in the cloud from like 2017 as soon as there was GKE like a good Kubernetes hosted service, we were integrating with those really aggressively and pushing people to use the cloud-based Kubernetes when they were in the cloud.

And so that kind of strengthened our story because at the time VMware wasn't even in the market Red Hat was still pitching OpenShift everywhere and it was still a single tenant.

It was like, you know, it was more borg like then multi cluster management like and so we were really kind of the only game in town if you wanted to do hybrid, you wanted to do multiple data centers.

You wanted to centralize your policy and you didn't want sprawling clusters.

And so and pretty quickly we just started knocking off really big accounts, right?

Big banks, big insurance companies, companies in the entertainment industry, in the government.

And they all started pretty small. We didn't-- We kind of got one thing right was that we had a pretty high base to enter because we were open-sourced we didn't want to sell it real cheap.

We wanted to sell it for, you know, we needed people to really spend 50, 60 70K to get started 'cause we couldn't really support them for less than that.

But we also weren't charging $500,000, $1,000,000, $2,000,000 to get started.

From an enterprise perspective we had a pretty inexpensive starting point, but from an SME perspective we had a pretty high starting point which kind of got us in the right mode.

We were adding 40, 50 customers a quarter as opposed to adding hundreds of small ones that we probably couldn't have supported or only adding three or four but they were spending 2 million each where we would have been pretty dependent on very long sales cycles.

We had a lot more rapid selling model-

Grant: With velocity, yeah.

Shannon: Yeah and that got into a lot of growth. So expansion became a big part of what we did.

So it all started to roll by 2018. And we started to just feel like, okay, now we've really onto something.

Grant: Yeah, so let's rewind a little bit because I think even the beginning of the sort of like the Cloud.com stuff is really interesting.

And I think it's interesting there's a through line here around open source.

And so what was the relationship between Cloud.com and CloudStack and then OpenStack, like how did that come about?

Shannon: Yeah, so what happened there, you know, 2017, right?

You got Amazon starting to emerge and these other cloud providers as the sun cloud at the time there's a handful of people that are doing like early infrastructure as a service clouds.

And there was one other company that wanted to build a software cloud, wanted to do what we were doing is can be called Eucalyptus software.

So there was Eucalyptus and CloudStack were the two-

Grant: Martin Mykonos, right?

Shannon: Yeah, exactly, exactly, great guy.

And they were building, they were a bunch of professors from down in Santa Barbara who were building a--

They built sort of a first version of their product a little before we did. And then we built CloudStack shortly thereafter.

Both products were open source, Eucalyptus was fully open source.

CloudStack was like, you know, we open-source everything but our adapter to vSphere or something like that we had a few things that we didn't--

But we did have more of what I would call an open core model.

Like we were open source but we hadn't gone all the way but we were getting good traction.

Like I think what we got right that they got wrong in the Eucalyptus side was they really focused on the enterprise to begin with.

It was funny like this market was getting reasonable amounts of investment. Everyone was sort of watching it and people knew it was going to be a big deal that there was this infrastructure as a service software seemed like it threatened vSphere.

So VMware was going to have a product.

There was a lot of talk about the vCloud and vSphere getting in and before OpenStack comes around, there's a couple of like big deals that everyone's paying attention to.

The funniest one was Zynga the like FarmVille the gaming company like one of Amazon's first really big customers.

Like they were at one point, I think about like a third of AWS was running FarmVille games on Facebook and they're like, we're spending a fortune we've got to get out of Amazon.

We've got to move this into our own data centers.

We're going be this huge gaming company.

So they run this big bake-off between us and Eucalyptus and it was probably the first really good private cloud deal to go build a multi-million dollar huge infrastructure investment private cloud.

And we ended up winning this deal and really a lot of the technical improvements we made there were kind of core because dealing with them 'cause the networking in these private cloud things is so complex and you really have to put a lot of investment into them.

And we were coming in to that Zynga deal with kind of neck and neck with UCO. They were sort of the early favorite.

They seem to be in the position most likely to win the deal but we kind of came from behind to end up winning it and winning it was really based on just really working with their architects to build a networking model that would work for the cloud but it ended up being super valuable later on as the market scaled.

We had these big cloud providers that were the telcos but they were all trying to compete with Amazon.

Their goal was to build their own infrastructure as a service cloud and offer utility based computing.

This was like the first company wasn't trying to compete. They were just building a giant cloud-

Grant: For their own internal use.

Shannon: And then there were more and more and more afterwards that but we got rolling with that Zynga when all of a sudden we had a great reference they were talking publicly everywhere.

And then the deals started coming in.

And probably not that long after that it was probably 2010 but I could be getting the dates wrong.

It was before I closed that deal in 2010 and right around then Rackspace, Citrix and Dell ended up being the founders of OpenStack.

But Rackspace kind of reached out to us and said, hey, what do you think about open-sourcing all of CloudStack?

And we were like, yeah, we could probably consider doing that.

And I think they were talking to the team at Eucalyptus a little bit too, but they ended up deciding at the last minute, oh, NASA was involved.

It was NASA was the other one.

But they decided at the end that they didn't want to do that.

They wanted to start from scratch that they didn't like something about our architecture but we were also not fully, like we were kind of semi committal.

We were kind of rolling and we still were doing pretty well with this--

Especially with the enterprise we were doing kind of well with this open core model.

And so in a lot of ways we weren't fully committed to going all open-source and they weren't fully committed to not building their own thing.

And so they say, hey, now we're going to do OpenStack but we'd like you guys to be part of it.

And we're like, well, why would we be part of building something that we've already built?

But to his credit, Sheng was like, yeah, let's just be part of it.

It can't be bad to be part of it. So let's just be part of it.

Maybe if it turns out to be better than what we have we'll throw away what we have and use this new open standard.

And if it turns out to be worse than we'll compete with it and so if you ever go back, like in the open, like we're in there as a founding member of OpenStack and we go, I spent all this time at these OpenStack conferences and they were--

But they were all trying to beat us. Like at some level they would Google CloudStack versus OpenStack.

There's all these CloudStack versus OpenStack articles back in 2010, 2011, 2012, as people were baking off one versus the other.

And at the time we were like, we can't be not open when they're open.

So we ended up making CloudStack and Apache project and going fully in on open source.

But even then it was just all the momentum in the market was really with OpenStack.

I mean, before you knew it you had Red Hat and SUSE and Obuntu everybody was sort of jumping on.

Yeah, let's get onto this bandwagon. The downside is that never really went anywhere.

That OpenStack project ended up suffering from not being great or well-architected, not being all that stable.

And also over time being way more than most people needed to manage infrastructure for their environment.

So it never really turned out to be a big space, but the lesson I took away from the whole thing was even if CloudStack was a better piece of software it's kind of irrelevant if the market is going with an open source alternative that's very well supported by lots of companies that nobody wants to bet wrong on enterprise infrastructure.

You don't want to be out on some island as the only people running something and you see it today, right?

I mean, I think MESA has ended up in that same point, HashiCorp Nomad ended up in that same point where it could have been better could have been not better.

It almost didn't matter. People just wanted a standard.

They wanted us to in Kubernetes was a standard and that ended up causing people to choose and pick more often than not based on not wanting to be on the wrong side of the technology gap.

And I think that's probably a good thing for these open-source projects to see consolidation 'cause it allows the whole ecosystem and to bloom around it once you have a standard piece but it definitely influenced a lot of my thinking at Rancher when we went all in on open and we've never written a line of proprietary code since we started the company.

We just were like, yeah, let's put our product out there into that open source ecosystem and see if it's good enough to get adopted.

And if it is, maybe we get things to start checkup.

And interestingly enough while Rancher took off and became really popular as a management layer the one that really took off for us later was K3S this really lightweight, dumb, simple Kubernetes distro that could run on a single node at the edge just exploded and now is driving a ton of business that's focused on just these new types of embedded systems and shipping Kubernetes with your device, shipping Kubernetes with your ATM machine or your medical device or embedding it in nuclear power plants or now even shipping software.

Just like I just have software.

I'm just going to embed K3S, ship the whole thing out to my customers and that's probably the first time we've ever had like what I would think of as a really huge hit on the open source side.

I mean, Rancher has been really successful, but K3S, you know, 10 times as many people using it even as Rancher.

So it's interesting. The open-source world is a great way to get to users and get to developers. It's very hard to monetize.

It creates an enormous amount of challenge when you're raising money and you're trying to build a business model, but we found that Kubernetes especially was in a really nice place where the criticality of it really drove people to want to pay for support.

And that's probably the one thing that people get the most confused on is how do you build a business model around opensource?

Grant: Yeah, I mean, also talk about what you were offering, like when you say support, like what did that entail?

Like what were people paying for?

Shannon: Well, from the beginning there's a bunch of open source models that people have been successful with.

They tend to range from the simplest which is, hey, here's our open source software.

We'll give you a distribution of it that we support. And that's kind of the Red Hat model.

This is a model that people, you know, the Linux model sort of prove that out and we'll patch it we'll give you the same kind of support you get from EMC, from VMware, from anyone else.

That's the model we ended up going through.

And then there's a lot of open core models where people tack on a lot of closed proprietary software on top and it's like, hey, if you pay, not only do you get support for the open source bits, but by the way we'll give you a whole bunch of other tools around security or multitenancy almost like the SAS model where you add in more functions for your paying customer.

There's an open-source version of that tends to have the distinct problem that once you pay for those things, if you ever stop paying you kind of have to rip the whole thing out and start over.

So unfortunately it kind of breaks the whole point in some cases of open source which is a bit more leverage and less lock-in.

And then there's the SAS model of open-source where, hey, here's the open-source version, but we have a really good hosted version.

You don't really want to run this, do you? We'll run it for you.

We ended up in that first category. We provided just support for Rancher.

So the customers, you know, they'd put it into production and if it was critical for them, they would put it in support contract in place with us so we would provide that enterprise grade support, but one of the interesting things about is you learn pretty quickly you better be really good at support because your only value is how good you are at making sure the customer is getting great support, getting their questions answered, root cause down.

You have to draw a pretty wide circle around what does it mean to support a product.

So getting into supporting the product but also its dependencies.

These days if someone's buying support from Rancher it's you we're supporting the Rancher product.

We're supporting our distro of Kubernetes.

We're supporting our integration to all the public cloud Kubernetes, we're supporting Docker or containerd, the demon below that, the networking layer that's inside of Kubernetes or supporting Prometheus and Istio and OPA.

I mean, you get it, it starts to become... You're not really supporting just one thing, you're providing this ecosystem of support but for the customer, that's what they need.

They need someone who they can call if something's not working in the platform.

And so that's allowed us to kind of increase value over time by providing support for more and more of the ecosystem.

You know, what we think of as the CNCF ecosystem and that it's not easy, it's not as sticky churn can be a little bit higher because there's nothing preventing a customer from leaving They just say the project's not quite as important to them.

Maybe it's no longer in production, but they still running it.

They'll just turn off support even while they're still running the system.

And very often 98% of the users of Rancher use it without paying us anything, right?

They just use the open source and they love it.

They manage all their EKS clusters for example on top of using Rancher they don't need support from us.

So we've been able to really find these interesting use cases and these places where the market does need us to provide a lot of value, but it's kind of a continuous battle to keep pushing more value into the platform, providing infrastructure in more places and also making sure that support is just fantastic because like if we're not getting an eight or nine, on an NPS score, we risk having churn that we don't want to see.

Then it makes it too hard to build the business.

So we were really good at that.

We had a fantastic customer success management team that really enabled us to meet all of our customer's expectations and ensure we didn't get into the problem of paying for support and the not being happy with what you paid for, but it was-- It took some learning to get there for sure.

Grant: Yeah, so this is really interesting.

How did you price that support package? Was it like an ELA or was it based on some amount of usage?

Shannon: Yeah, I mean, this was a really good one learning for us as well.

When we first started we weren't sure at all how to price it.

So we priced it based on like VCPUs or CPU's under management something like that.

And later we just sort of simplified it a little bit with at the time we were kind of competing at some level with Docker themselves and they had approached it in a very simple way.

It was like per node pricing. So the number of hosts you had running Docker you paid them say two or $3,000 per host list price and that was it.

So you could buy two hosts or three hosts or four hosts and get started.

In fact, they rapidly got to six, seven, 800 customers but a lot of them were spending less than 20 grand less than 10 grand.

And I was really worried about that business model because there were a lot of people who want to do the same with us.

They're like, hey, just let me pay for the three nodes but my first starting environment.

But we, you know, I kind of knew support quality was going to be really important and I knew we weren't all that good at doing support early days.

So we decided not to do it that way.

We decided to sell our product based on a per node price but with a minimum of 20 nodes and then a management server costs too.

So we sort of charged for a platform level fee for the Rancher management server which allowed us to get the price closer to 50, 60 grand to start with for our customer and there were people who were really upset about that.

I'd have people say like, I'm just using three nodes or five nodes.

I've got a little cluster can't I just pay 10 grand?

And we would say, look, you're welcome to use the software.

It's 100% free, but for support I can't make any money charging you only 10 grand.

And I can't give you the kind of support you need if you're telling me this is production, this is mission critical, I've got to have people up 24/7 working with you around the world.

So I'm sorry. No, I can't do that. That really helped like being really transparent and walking away from deals being very comfortable to walk away from deals.

That was critical for us. So it probably kept us from having as many customers, but the customers we had they really had to sell it internally.

They had to go get someone to sign off on spending 50 grand and so the churn was less, there was a real commitment to doing it and it ended up being perfect.

It was just sort of the right sweet spot where we were able to add customers. It wasn't too high to be prohibitive.

It also wasn't too cheap that we we'd want to make enough money to hit all of our business goals.

And so we were able to beat our number quarter after quarter after quarter after quarter was just in this model of seeding the market with open source and then seeing it come up, get to production and at least in those big enterprises that had money to spend.

And then somebody saying, look, we can't come to production with this platform without support.

Let's make sure we're connected and working with the guys over at Rancher.

That was sort of the magic of our model and it worked really well. It was just consistently.

70% of our business was inbound, right? It was them calling us saying, hey, we found your product.

We love it. We'd like to talk to your sales people.

We'd like to talk, you know, and that was the other thing our marketing team just knocked it out of the park.

We didn't focus on marketing on who needs enterprise Kubernetes support.

Our focus was all on building with Kubernetes like helping you understand how to build with Kubernetes.

So we ran, I mean, just an almost insane number of virtual events, right?

Every month we were doing an online meetup. Every week we were doing a masterclass.

Every Thursday at 10 we had come to hang out with one of our field engineers and just learn the product learn how to install it, learn how to use it.

We had, you know, we were at every CubeCon, DockerCon.

We were at every dev ops days and cloud days.

I mean, we really invested in being present and having a huge community with, you know, we never put a lot of pressure to buy.

It was always just used, just use, just use.

And so our Slack channel had thousands and 10,000 people on it chatting with each other.

Our forums we're super busy, you know, Darren and I would host meetups that would go for hours.

Like we would talk for two hours, three hours showing people how to do monitoring for containers.

In fact, at one point we had an article that was comparing five methods of monitoring that was the number one article you would find if you just typed in container monitoring.

Like we were writing just enormous amounts of content.

So we made up for our sort of lack of Shannon brand awareness.

We weren't Docker, we weren't Red Hat. We weren't Google.

Like we weren't-- Nobody knew who we were.

So we made up for it with this really aggressive content marketing program and just putting so much of the information you needed to get started out into people's hands.

We did online training that was 100% free this incredible university of classes, you could get certified and never pay a penny just go through our little mini you Udacity.

But in every single piece we captured Shannons.

We captured leads. So we built this really strong database.

I mean, we knew everybody who was doing anything about containers because at one level or another they were ending up on our website or they were meeting us at a conference or they were coming to our things and that then turned quite well as we started to scale into connecting that to an SDR team and beginning to really build a sales motion that allowed us to make sure people didn't fail.

Because one of the things we find with open-source was there was relatively high risk that you download it you'd try it and you'd get something wrong or you wouldn't quite understand how to use it and all of a sudden you'd fail.

So then a lot of our work really came into filtering out the 4,000, 5,000 leads we'd be getting a month down to the 500, the 10% that were at larger organizations trying to do something that probably had a little more meaning, maybe we're comparing us to OpenShift where we could then drop in excellent field engineers and show them, oh, yeah, sorry our product's a little bit non-intuitive, let's fix that.

Let's show you the parts that for whatever reason they weren't coming through.

And then we learned from that and try to go fix the product to make it more intuitive so that people who downloaded it could understand what we were trying to do and fix gaps.

So we were just rapidly iterating.

We were doing a release every, you know, four releases a year, three releases a year, in the early days, trying to get new features out, new more usability, more product capability because it was just very, even now a just very competitive spot.

You had the biggest companies in the world, you know, Docker was a household Shannon at the time in IT.

You had Red Hat, you had later VMware kind of got involved in the market.

You had Google pitching their story around Anthos.

So you had this huge companies who we were competing with.

We just we had to be differentiated and being open-source was great 'cause almost none of them were really on a good open source option.

Even though Red Hat's OpenShift is open it's not the kind of thing people just download and use the open version of.

So where 98% of our users are open source for them it's like 5% of their users are open source.

Most people are just buying it and kind of taking as part of their rail subscription.

So it was great. We had this real community of people that just fell in love with the product.

Grant: That's super interesting.

And so, I mean, there's a bunch of pieces in here.

So I mean, I think the focus on sort of that top of funnel.

And bring in, it's really to create a bunch of value for your audience, right?

Like content, training and everything else you can and get people excited about your ecosystem and then getting them in and eventually they move around the big companies and those companies start using your things and your things need support in order to make sure that they can really scale it out and use it across your org.

And I'm guessing as well, like you mentioned this kind of base platform fee that ended up with like a 50K ASP, every selling price, but there's also this per node pricing or per VCP use.

I don't know which one you ended up using long-term but I'm guessing that allowed some of your customers to really scale well beyond the 50K and so you'd probably have multimillion dollar contracts at some point.

Shannon: Yeah, that's exactly right. I mean, you nailed that Grant.

Is that we use almost like a high low strategy. We tried to have a kind of a high management fee but a relatively low node fee.

So we were price competitive when a person looked at us and they said, well, Red Hat is charging me 2,500 per CPU pair. So it's 5,000 for a host.

We were like, well, we're only 1000 for a host. So this is a much more reasonable.

And now of course, Red Hat's discounts bring that way down.

So it's not like we're really that far out, but we came up with a model that was to strike a fair price for the management server and then make sure the node price is fair is kind of in the right ballpark where a company would say, yeah, that lines with the value, don't discount.

We really were harsh about discounting 'cause we were like we're not the Cate Jewelers or whatever.

Like we're not putting on a 70% markup on this thing where you can tell our price is very fair compared to our competitors.

So we were normally only discounting sort of maybe 10%, 15% 20%, if a person started to scale and then eventually you have companies starting to push for ELA but we really never pushed for them ourselves.

We were like, no, let's just go buy nodes, go buy nodes.

And it was always great because when they came back and said, no, we don't really want to go buy nodes anymore.

You knew you were kind of starting to get to the point where the value was starting to creep up.

They started to see the impact of containers and Kubernetes, the product and again, we always were pretty easy to work with.

We sort of worked with them to understand what they needed and then take it down and do the deals and make sure they were satisfied.

So we started to see that, you know, really 2017, 2018, 2019 lots and lots more now, even now, you know, to these days it's really has never stopped.

I would say the interesting thing is despite that and all that growth happening the quarter after quarter we keep seeing more and more net new, right?

So the net new customers was 20 then 30 and 40 that a quarter then 50 a quarter and 60 a quarter.

The growth in Kubernetes was also rising the number of net new. So the ecosystem now we're, you know, over 500 customers they're running the enterprise platform and adding them really fast.

And that was one of the things that was really appealing about SUSE was just the reach, right?

I mean the one area where we were, you know, despite all of this we were still pretty handicapped is we were at that point we were a 240 person company scaling well, but at some level like IBM putting ads in the Superbowl about hybrid cloud computing with Red Hat.

You have VMware's entire mission to be selling Tanzu you have Google beating the drum at the CIO level about Anthos.

We were definitely still in and I would say a pretty disadvantaged position pretty significantly distant 'cause we just didn't know install base.

We don't have an install base to really rely on and while we were working really well with the cloud providers, because we did such a good job of managing their Kubernetes it was still, you know, we just didn't have that pole in the market that they all had.

And so we had a great product.

We had this nice inbound just really strong messages, but with what SUSE was able to really bring to us and they really sold us on was having 6,000 customers.

Being able to, you know, they had the Linux base and 30% of the world's Linux.

They had this huge, huge market in Europe where they were just dominant and they also have the benefit of having just been spun out.

They were P owned. So they had a very clear desire to grow this obsession about growing a business and driving the growth.

They had a really great new leadership team. So it was really-- It was a very unusual, I mean, I don't think any--

We certainly didn't go into last year especially in the middle of COVID thinking we were going to sell the company.

I think I would have bet almost anything that wasn't going to happen. And we were hitting all our numbers.

Things were going really well but they just had almost a perfect need for what we did and they were kind of at the perfect scale and size to make it a really good fit where they could really help us accelerate plus they had the potential of a future exit of their own that you could sort of see a big one plus one equals three opportunity working with them.

So it was a tough decision. I mean, it's always a really tough decision to sell your company, but I think it was the right one.

I've been super happy since we joined SUSE it's been everything they promised just this amazing customer base that loves them to death and gives us a much better product portfolio and much more interest now in talking about the whole infrastructure stack because now we can talk about Linux plus the container strategy plus everything from bare metal all the way up to the Kubernetes ecosystem.

And that's interesting when you get into, you know, we had tried for a while, we had Rancher OS, we had K3OS we've been trying for awhile to see if we could build a really kind of integrated stack.

And now all of a sudden we get the world's second biggest Linux engineering organization and we're just doing really, really cool things now that start to look at, even if there should be any line between containers and Linux and Kubernetes and such maybe it's all really just one thing, right?

It's just basically the new OS.

The new OS starts at the kernel and runs containers and self orchestrates.

So it's been a really interesting and good fit.

Grant: That's great. And I definitely want to kind of dive into some of the integration acquisition stuff in a bit but back to this, your business model, right?

This idea of you only sell supports there's no proprietary bits you're selling at all. It's only support.

But you mentioned as part of that customer success.

You know and I have kind of a thesis here around you kind of mentioned it too that support is a broader circle than I think many people think it is but I kind of I've been writing this kind of I don't know, blog post or something about supported versus unsupported software and the idea that there's different types of functional activities that support does.

And one of those things I think is customer success because ultimately the responsibility of ensuring expansion if it's unsupported, it falls upon the team like the enterprise to make sure that more people are going to use this standard and going to follow these best practices and are going to like adopt this.

And if someone leaves that was championing it like then somebody else has to take up the torch and fall through on all this.

But when you work with a vendor you are very incented to help them grow their usage of it and standardize on this and so you end up as part of your support like sort of ensuring that this is adopted broadly throughout the company.

And then that there's continuity if someone does leave or there's consistency between teams and so I really think that support is so much more than what people sort of initially think about it as.

Does that all make sense to you?

Shannon: Yeah, I know it's spot on.

I think by the time you're running a real enterprise software company you better be doing more than break fix.

You better be doing more than drawing a very tight boundary around your products bugs and fixing those bugs because that's not what anyone signs up for and that's what they pay for.

That's not what they renew. So it's funny.

My feeling on support has always been that the best support organizations are really close to engineering, you know, to drive product quality and things like that.

At Rancher we put this guy named Bala who ran our support organization.

In fact, our support organization wasn't that good in the early days and Bala was running our services team and we moved Bala over to take on support and he moved it into the engineering organization.

So we kind of reported directly to one of our founders Will Chan who runs engineering and by moving it into that team, we just kind of changed the perspective of the people in there, got everyone focused really on time to address problems instead of time to respond.

So like really started working on how quickly can we understand the problem, engage, get a solution and help the customer with what they're dealing with.

And that was really, really important but it didn't get us all the way because we still needed to build customer success.

And we built customer success as part of the sales organizations was part of my team but we addressed it in a really interesting way 'cause we weren't really sure what the profile of our customer success person should be.

Should we be hiring someone who is kind of a technical person, more like a field engineer or a sales engineer as customer success 'cause they could get into the weeds a little bit more with the customer.

Should we be treating it more like a renewal rep who kind of knew and sold?

And one of my oldest friends, a guy Shannond Dave Gensler who had run our America sales.

I asked him to take on this customer success program and in taking it on he really figured out something I thought was really genius.

We actually started promoting our SDRs into it.

So we had these SDRs that were sometimes a year two years in knew the product really well, knew the company were eager to start working with customers but they were still maybe not quite ready to be an outside sales person and so we started putting them in as customer success reps and the best of them did fantastic in that role.

But what they really learned there was how to understand I mean, they were all reasonably technically savvy having been with us for two years or a year and a half or something.

They knew the product, they understood, you know, they weren't mispronouncing Kubernetes but more importantly they had figured out like qualification, like why people bought.

Like, what was the reason, like what would cause a person to take a meeting, right?

Like when they talk to some of them like why would they be a good potential customer.

They've listened to so many first calls and second calls with customers.

They kind of understood the needs customers had and so when they would sit down as a customer success person, they wouldn't focus on well, how's the implementation or how's the architecture.

They would actually focus on what were you guys trying to achieve?

What was the business goal you were facing with this thing and who was the economic buyer like who paid for this?

In fact, what Dave really trained them to do which was I thought brilliant was to get incredibly close to the economic buyer 'cause the easy thing is to get close to the technical owner of the system.

You have this technical owner of the system who is probably a fan, legs Rancher wants to talk to us all the time.

He's easy to talk to.

But then there's the economic owner who cares about whatever the output of this platform was.

And often he's got people that he's reporting to or sort of dotted line into that are relying on his system in this case on his platform in this case, maybe developers maybe application owners, whatever.

And so by making sure we had both of those relationships obviously we're working with the technical people pretty hands in hand.

They were the ones filing the tickets. They got to know our customer support team pretty well.

Our support team was doing a really good job getting to know them and the CSMs would understand their problems and sort of document them and track features they were looking for in the light.

But they always connected to the economic part and because we have this very clear--

Most of our customers are on one-year contracts like one year support contract.

So one of the first question I'd be like is like, okay a year for now what do I need to make sure I've done to earn your business?

We just asked that guy very bluntly 'cause I'm going to need you to renew next year and you don't have to, it's an open-source product.

You can just stop paying me. And so the person would just lay it out.

Look, I need you to do these things and we figured out pretty quickly that one of the most important things we needed to do was when there was actually a problem when one of their engineers filed a SevOne we needed to make sure that economic buyer knew about it.

Because often the engineer wasn't telling the economic owner that there was an issue and that they were on it and sometimes that would create a lot of chaos internally.

And so what we found was if we-- Every time a SevOne we actually built into Zendesk and Slack and everything these alerts that would actually alert a CSM, hey, there's been a SevOne at one of your clients.

This is what they're trying to deal with. Let you click here and read the ticket.

And then they would then proactively be reaching out to the economic buyer and telling that economic buyer, hey, just so you know we've got an issue with one of your systems.

This is what it looks like, our person's on it.

I'm here if you have any questions, if you need--

We're treating this with the highest level of priority but that outbound at the time of this sometimes telling them about it that, hey, John in your team has already let us know about this.

We're working on it.

I just want to make sure you know we're on top of it we're treating as the highest level of severity we'll be back to you with a root cause analysis as soon as we figure out what happened and why it happened.

Like that made just this massive difference because in those moments where they were stressed out they were getting a reach out from us telling them, don't worry, we're on this and then they could then tell that to someone else.

And you're like, yes, but we're on it. We understand what's going on.

We think we've got a solution and we would update them during that SevOne period.

It was just like over communicate make sure there was no gap in the communication but it's just things like that.

It doesn't seem like a lot but it comes from that person being comped on-

Grant: Renewals.

Shannon: The renewal and the expansion, right? Like he's only paid if.

So it's that sales mentality of you've got to get the renewal and your bonus is really tied to the expansion, right?

Like your salary and your OTE is tied to the renewal and upside is all tied to the expansion.

You really want to drive this thing and younger SDR centric people were perfect for this.

They were hungry. They could be coached.

And though a couple of changes like that we saw about a 30% reduction in churn.

Just getting more aggressive on this significant dropping.

A lot of it came from making sure at the end of the year we knew who had had issues, who hadn't had issues.

Somebody who'd been running really smoothly.

We were really proactive with to make sure, you know, 'cause that would be a challenge too if you're selling support and someone doesn't need it like the products were so good.

I don't file any tickets that, you know, you want to be a little bit careful about those because they tend to be a little less likely to renew than somebody who's in that sweet spot where they've had a couple of issues and they see at least the value in having a support system.

So I think it's just fun.

I mean, I always found the customer success stuff fun and Dave who had never done it, he was always I say, I mean, he was one of the head of BDS at that first company I worked for back in 1999.

Is where I met Dave but he'd always been in sales and he'd never done CSM but he was just such a natural because he understood how much impact the economic buyer had on the renewal and how to work closely with them.

Grant: I love that.

That's super interesting and not something that I would have thought of.

It's a great path for that to kind of BDR, SDR, you know, before they go into sort of that like field sales, enterprise sales, they can really work to get renewals.

That's beautiful. One thing, as you're saying this this idea that those customers who don't have issues, right?

Like what was your CSM team doing to help them? Is it best practices? Is it more usage? Like what were they-

Shannon: It's a little more challenging to be fair when you had people that weren't having issues and especially over time as the product became more and more stable, you know, what we were really working with those people on was roadmap type of things.

We'd make sure we were in doing roadmap briefings talking about what they needed.

Like how was the platform working for them? Was it great?

Was there something that they'd like to see?

The more we could get them hooked into our engineering team the more we could get them excited about the next release the more we could just make them comfortable that they had picked the right technology, they were working with the right vendor.

So we build a customer advisory board would have PMs getting on the phone with them showing them the roadmap.

We talked a lot about new things we were working on, hey, we're working on this new open-source project K3S.

We'd love your feedback on it before we drop it or Longhorn we're going to put that into the CNCF.

It's this new storage platform for Kubernetes let's show you what it's all about and here comes our harvesters, our new thing.

Like we kept building new things and we kept putting them in front of them.

And when they blend it, it was just perfect. It'd be like, oh, I love what you're doing.

I like working with you guys. I feel like I know what's happening in the ecosystem.

We talk, they'd be like, hey what about Istio versus Linkerd?

What about Prometheus versus Datadog?

You think I can get there with this and we wanted to add a lot more value and we would do that for everybody.

But one of our little alerts was, hey, somebody has a ticket in five months, four months let's make sure we're doing some proactive outreach because we don't want to only be talking to them when it's time to renew.

We want to be talking to them before it's time to renew a couple more times, make sure they feel like the 100 grand they're spending with us or 200 grand they're spending with us is giving them real value, allowing them to worry about other things besides what's happening in Kubernetes land.

It's like, hey, you don't have to worry about what's happening in Kubernetes land.

We'll worry about that for you.

We'll give you an update on the projects. Sheng on the TOC, I'm on the CNCF board.

We're living this world. Talk to us, we'll tell you what's going on.

So you can tell us what's important to you and that'll help influence our--

It was those little things like that were really useful for the customers who maybe they weren't having as many issues or are not.

To be fair we didn't have a lot of people where they would not renew because the product was just so stable.

I mean, for the most part they were buying insurance, right?

They were buying support for the day when things did go bad.

Because they were running something really critical.

So it wasn't a huge problem, but it was something that we wanted to make sure we were on top of most of the time.

Grant: Yeah, this idea of like selling insurance. It's funny.

You probably know, Alex Polvi little bit, don't you?

Shannon: Yeah.

Grant: Yeah, so we had him on the show two years ago maybe he talked about sort of what Red Hat does is they basically sell insurance.

But I think there's so much more and this is kind of that, you know, it was alluding to before and this what is supported software?

I mean, like this build versus buy, right?

I think this is even for a product like Rancher these 98% of customers that aren't paying you that are using the product.

What I don't think that the like "buyer really understands" is that they are performing a lot of the roles that your team could be doing if they paid you.

And like so somebody inside their company, if it's a decent sized company is doing some amount of customer success or some amount of evangelism, some amount of like, you know, there is somebody is keeping them up-to-date on the happenings of the CNCF and sort of filtering through projects and bring things that could be interesting to them.

So like, there's so much more that you're doing beyond insurance and break-fix and I don't know if buyers really calculate that when they do kind of a build versus buy or like they see the amount of hours that their team is going to need to do or if they don't end up doing those things then it's just not successful.

Like they end up not getting the transformation and digital transformation that they want.

They end up simply with like a, oh yeah, we have all these different projects and people use them and like, somebody on this and somebody on this and there's different, you know, there's no like cohesive story and unifying like strategy.

It's just like, kind of ad hoc.

Shannon: Yeah. You know, Grant the biggest reason people don't buy support I've found over the years is they don't have money.

Like just full stop, right? Like the vast majority of those 98% there are startups.

There at companies in developing markets. They're trying to convince their company that this technology is ready for prime time.

They're in budget crunches in their company and they just don't have money to spend on this.

They have to prioritize something else. It's like, you're paying salaries and they can't afford to also invest in this.

So there tends to be very few companies that I would say actively believe they can do a better job supporting an open source project and the companies who built it.

But there are tons. I mean, right now at this point China is an even bigger consumer of Rancher than the US.

There's more Rancher deployments today in China than there are in the US.

And while we have a lot of customers in China a lot of big ones, the vast majority there is probably 99.9% of the usage is unpaid.

And whereas here maybe it's 95% of the usage or 94 or something like that.

So it tends to be that there's also lots of workloads that aren't that critical to be honest with you.

There's a lot of workloads that just aren't that important.

It's an internal workload. It's something we're building, you know, not running my company's main transacting systems.

I'm just running something that does some HR processes if it goes down, I'll reboot the system it's probably going to be fine.

So there's this, you know, to me at least I always find that there's almost always a really good reason.

There's a few people that just think they can build anything better and those God bless them let them go and do it because they're the hardest customers to make happy anyways and they're-

Grant: Sure.

Shannon: So I'll tell you this, I don't think our business would be bigger if we were close sourced.

I don't think people would be like just beating us up to buy.

You know, I think there's-- My gut feel is that the people who underestimate that cost of open source, they don't last that long in enterprise IT because you get burned once or twice and you don't grow like your career gets stalled out and that's the problem in IT you're the guy who says, yeah, we got this, don't worry.

We're going to build our own Kubernetes platform.

We're going to build our own version of.

I mean, I can't tell you many times I come in and someone is replacing the guy who built their own Rancher has been fired.

Now they've still got their own Rancher and they've got it like tear it down and replace it with Rancher. That's like, yeah, yeah.

That guy why was he fired? Oh, because the system was totally unstable.

Because he had four engineers trying to do what we have 150 or 200 doing and it couldn't keep up with the latest builds of Kubernetes and it couldn't keep up with the changes in OPA and it couldn't keep up with the changes going on in Promethease and it couldn't keep up the changes in Docker.

And I mean, again, yeah you could build a basic provisioner that says, hey, go create a cluster but building something that also has multitenancy and also has some of the business logic you need about who's allowed to do what and defining-- It's just hard and it takes work.

So I think-- I always feel like those, you know, you see those in the early days of a market when people don't really know that there's good solutions out there and there's bright people who love to build.

I love those people. They tend to be, you know, a lot of the time they figure it out themselves till the smart ones kind of realize, oh, I've been building this thing but now there's this Rancher and it's solely open.

Why wouldn't I use that? And we're starting to see that with this embedded market.

Recently we did a partnership with NetApp where they had been building their own version of Rancher kind of to embed and distribute.

We just did another deal with a very large hardware company and they were kind of going to build their own thing and it was like, well, if you're open, we have leverage.

You're not going to be able to... 'Cause that's what people want.

And honestly, what is really powerful about open-source is it's a fair playing field, right?

Like when I sit down to negotiate any ELA.

I may be the world's best person at supporting Rancher but I'm not the only option to support Rancher.

They have other options. If I tell them, hey, tough, it's going to be $12 million.

You know, they'll say, you know what? I think I can probably do this for $12 million.

I can go find people or maybe I can hire Accenture or I can hire Wipro or somebody else.

And I can actually support this or I can find another option besides being. So they're not going to have to go uninstall it.

They're not going to have to go tear it out of their system.

So I have to meet them in the middle where the value is right and the alternative is fair.

That means two things. One, you have to be willing to walk away. You know, I've had CIOs tell me, I don't care.

It's open-source, I'm not paying you more than 100K I don't care how much we use.

And I've always just said like, well, unfortunately we couldn't build a business that way, so good luck.

You should go and do it yourself. You know, support it yourself.

I can't build a business if I said yes to that everywhere.

And if everyone agrees with you, then I'll know my business will fail and you'll be right but that's the risk I'm taking being an open-source business.

And to be fair in that case that CIO didn't stay in his job and he was gone two years later and they became a customer and paid normal price just like everyone else.

But it's a pretty healthy dynamic. I mean, I think people have been burned, right?

They've been burned by both open-source companies that have locked them in.

I think Red Hat locks people in in a way that is shocking for it has open as they say they are they're incredibly locked in.

They're completely controlled about what they're allowed to do and how they're allowed to use it.

And if you stop paying your cost of getting off the systems is very high.

So we've always tried to be all different than that and say, no, just keep it a very fair thing.

There's no license key. You've stopped paying.

You just keep using the software if you'd like to and uninstall it if you don't and it's forces us to be really good at customer support like we were talking about really good at customer success, find fair value, keep adding more crap to our product because if we don't customers will start pressuring us to reduce the price or not.

We're not adding more value year after year. I've just found it to be a really--

It may not be the most profitable model. I certainly VMware's model is a better model.

They're going to make billions on their products that are proprietary and stuff at least for a few more years, but in the long run I just think this model is where the market's going.

I think open source is real. Organizations are contributing to it.

People are willing to do almost anything as an open source project.

There's plenty of companies that have had success now building businesses around it.

And companies like us that have done well building the most liberal version of open source business.

So I think it's going to be harder and harder to have proprietary software companies in the infrastructure space unless you have just incredible breakthrough technology.

Something that's just so hard to do that people have to use your bits to get that advantage.

Grant: I totally agree. The one thing you said though, that I think is probably not at least it's not obvious to me is you have to be willing to walk away.

And this is a combination of your minimum price that was a little bit too high for some people as well as just like, hey, at that amount of usage your price is going to be X, Y, and Z and we don't discount that much.

And this is how our business works because if you don't do that then people feel like they can negotiate you down to like where there's no business.

But by keeping that sort of pressure up, it's like you either can work with us at a fair price or you don't get to work with us at all.

And there's not like a less nickel and dime me down to where it's like, it's painful for me to work with you.

It's like, it's either this is a great relationship for me and you or we don't have a relationship at all.

I think that's really critical for open source businesses to do though.

And I don't know if that's that well understood.

Shannon: There's two pieces of that Grant.

You're spot on that. That was core because we had to hold the price or we couldn't build the kind of support we wanted either.

If I was doing it at half the price I couldn't hire great support engineers.

I couldn't also have a CSM. I couldn't fund it the way we needed to.

But the other part was we really did have to be really good. Like we actually had to give them something.

We had to be a little bit like either stick with us or don't stick with us. It's your choice.

We think we're really good at what we do. We want to earn your business.

We want to give it to you at a really good and as long as we were it wasn't hard to renew people's like, you guys are one of the better values, right?

You're giving me great support. Our NPS was off the charts.

Like it was always eight or nine it was people were like, yeah, you guys you went that extra mile.

You got me the root cause analysis.

You talked to my economic buyer, you've done these small little steps that just made sure that the customer when they were having their worst day of the year, everything went smoothly for them and you took care of them really well.

But the other part, I think that also helped with that is not being a slave to a number of customers that are super individually high percentage of your revenue like we never had a single customer more than two or 3% of our total revenue.

You know, if that, like, I would say that helped a lot.

There was never one customer that we couldn't afford to lose. Like if a customer just said, hey, take it or leave it.

We could leave it and say, we're not going to still work with you.

And 'cause we weren't doing $5 million upfront two year, three three-year contracts to make AT&T successful or something.

We were doing a lot of start with 100K, start with 150K, start with 200K, grow it, grow it, grow it.

And by the time they were growing they had learned to like us.

So we never lost customers once they really started growing.

But if somebody was, you know this one customer that I'm thinking of if they were like, hey, you know, 100K or nothing it was easy to be like, well, your 100K isn't going to make or break us as a company whether we make it or not.

So I don't need your 100K I'm going to make my number. I'm going to beat my number without that.

So having a strong business where you're doing that and that was part of our-- This help with our board.

We were very, you know, I wouldn't say conservative but we were very pragmatic with our board.

We always, you know, Sheng is by his nature a CEO who's very, very realistic.

He tends to underplay the upside and overplay the downside really focus on the challenges and the business and the things that are disadvantages to us versus the advantages we have.

And so we never got into that like unicorn bubble either where the expectations were so out of whack with what we could deliver that when we were doubling or growing by two and a half, three times a year it was really, really good and people were just thrilled.

There was like, wow, you guys are way outperforming.

You know, where you thought you might be at this year.

And so we kept expectations in line and then delivered head of almost the entire I think the whole time, the entire time we had the company we just were very realistic in our goals.

And we never tried to oversell our investors. Even when we were raising money we were super negative.

We'd be out there pitching and we'd be like, yeah, but, you know, which I think probably depressed our value at some level.

Maybe it costs us a few points but it made the VCs that came in very much the ones who were like us, they were pragmatic.

They were a little more seasoned. They weren't necessarily fighting to get into the deal.

They felt like it was a fair-- Again it was just kind of our nature.

It was sort of be really clear really upfront. For us it worked really well.

It allowed me to do all this as a dad of three kids and still not lose my mind not be in a position where I couldn't balance my life.

And sort of do all this stuff and still be happy because I think that's the challenge sometimes you get all this success and things are going really well, but you're just, you know, you're flying 250,000 miles a year.

You're just nonstop every single minute.

You miss out on coaching soccer and you miss out on seeing the kids play and you miss out on keeping a reasonable balance with your parents as they get older and wanting to be around them.

And I don't know, for me it was really important.

Maybe it's because I don't know 20 years of working at startups.

At some point every day can't be the most important day. You have to get to some sense of like, it's life.

Like this is the only thing I've ever known since I graduated from college.

So that if you can't balance it all together and come up with a plan that's rational and logical and predictable and allows you to sort of--

I don't know it's very hard to keep doing it. 'Cause you just burn through all of that whatever it is all that energy.

So anyways, I found that and that's where finding the right partner.

I mean, Shannon was the perfect partner for me 'cause we're both really pragmatic and both sort of err on the side of seeing the problems instead of getting blown away with the potential.

Grant: Yeah, I love that.

My co-founder and I also like have this like thing where I think one of the more important things about being good founders I say like being super even keel like you can't let the highs get too high or the lows get you too low.

And because like, when things go bad you have to be like, well it'll get better.

And when things are going really well, you're like what's going to go wrong next?

Like there's always like you can't last like this forever. And so there's this balance that you have to have.

And I think it's... 'Cause it's like starting a company is kind of manic and so you have to be just like, as even as possible in order to manage it.

COVID made that interesting. But you know, those like being like on a rollercoaster with a manic person, who's like screaming in your face and you're like, what's going on.

But we know it sounds like you got through it, we got through it. It's a really interesting challenge.

One thing I want to come back to that you said earlier cause I've been thinking about it a bit you mentioned like a customer advisory board that you built.

Was that something that you were involved in?

Shannon: Yeah, yeah heavily.

We built one we've kind of found it to be really useful and they really tend to be this great opportunity especially in a company of our size.

And you're in kind of that mid ground where maybe you've got hundreds of customers, but not thousands of customers where you can kind of identify the customers in your install base that are very thought leadering whatever that word is, show a lot of thought leadership.

And so where you really, you know, that the kind of-- And everyone's got this, right?

They've got the 20 or 30 customers that they just know better than they know their other customers.

They're ones that they've personally spent a lot of time but there may be early customers.

They may be really strategic customers or they're your biggest customers but they could just be your smartest customers.

We've had some great ones.

I mean, we have some great ones in all sorts of parts of the industry from insurance companies to automotive companies, to government agencies, to tech startups and everything else.

And so we just found that by bringing them together on a semi-regular basis we got to get some really honest feedback and we also got them a little more comfortable, especially in the early days like that they're working with Rancher.

They're working with a small company that doesn't, you know, they chose us over Red Hat.

There's people in their organization just almost wanting them to fail or saying like, what were you thinking?

Why would you do this? There's Google's on knocking on their door, VMware was knocking on the door.

And so you want them to feel a little bit more comfortable too that they're in good hands and that other people have made the same choice.

They're like, oh wow. So these guys are here too.

And these guys are here and these guys are, oh, wow.

All right. And so that was a big part of our success was just getting all these companies together and just making them feel more common.

In fact, in many cases we would win departmentally.

We would win functionally, we'd be the solution for a part of their business.

I remember one of the really biggest financial services companies we work for, you know, we were working with part of their stack and the rest of it was all pivotal.

And then pivotal was kind of losing traction on the path side so they started using VMware's Kubernetes story and that struggled, you know, then we were brought in to compete but there was a big Red Hat group so they went to OpenShift for another six months that failed but our team kept supporting us and kept pushing as far as saying, like, I know you guys you don't trust that this smaller company can work for a company that's one of the 20 biggest companies in the world, but they're killing it for our applications.

We're the happiest group here.

We're running Kubernetes longer and more successful than anyone else you really should look at them.

We brought some of the other executives to one of our advisory boards they're able to see, oh, you know, also this huge organization this huge organization has all in, this bank has gone all in this.

And it was that that gave them the comfort finally to kick those other products out and just standardize and do a much, much bigger deal and a much bigger expansion.

But it was, you know, we were passed over twice when they decided to go to Kubernetes despite success in a department, because we were, you know, at the time we were maybe 60 people and then we were probably the second time we were probably 120 people.

And the third time we were 250 people but you kind of have to get used to that as a startup, you have to be comfortable holding your ground sometimes losing out to bigger competitors who have deep relationships who are able to give away the product that is in your space as part of a renewal and a much bigger deal.

So it's almost you're competing against free despite the fact that long-term that product's going to be way more expensive.

You're asking for money upfront where they're giving them basically the whole kitchen sink to try to lock them in on this new platform.

I mean, we see that still today all the time and you just have to hold your value believe you've got a great story and a great product.

No, you're not going to win the whole market except that other people will pick up other customers and make sure that you're winning more and more and more and more of your share.

And that things like a customer advisory board really helped.

I mean, they just helped because they give people confidence.

Grant: Yeah and so how do you, I mean, you formalize it you have it once a quarter.

How do you pick who from the customers to be on the advisory board?

Shannon: You know, it's just like pretty easy.

The CSMs make recommendations the salespeople make recommendations, the support people talk about the bright people.

And we didn't set a hard limit. We kind of said, oh, let's go for 10 and then we ended up with 30.

We said like, oh, we'll start small and before you knew it was 30 people.

And we never were big enough to have like a Rancher fest or Rancher or con or whatever.

So we would do it at CubeCons.

So we'd be like, hey, why don't you come to CubeCon and come the day early come spend some time with us in a hotel next door and we'll really get into the weeds on our roadmap.

And we always were big sponsors of CubeCons so we'd have extra passes and we'd offer them passes.

So it was, you know, they still had to fly themselves out there, but they would get some value out of coming to a CubeCon and meeting us, going out to a great dinner or sitting and learning and talking to other people.

We do one in Europe and one in the US since we tied them to the CubeCons and they were great.

We haven't done one in person now we've been doing virtual ones and we made those even bigger where we've kind of expanded them even more.

So I don't know what we're going to do when COVID ends and we kind of bring it back together.

At this point though ASUS has ASUSCon, so we'll have our own conference that people are coming to that we'll probably start to drive these kinds of conversations too.

But I still think the place we want to be talking to them is during CubeCon when they're thinking about this stuff and they're really, you know, this is a top of mind for them.

They're able to get a lot of education and we can also put a lot of stuff into context for them that they usually appreciate.

Grant: But like what's the profile?

Do you look for the executive, the manager, the hands-on keyboard person, like who's the-

Shannon: It's usually the architect and the economic buyer. So often we'll bring two people from a customer. We'll invite them both.

Grant: Oh, interesting.

Shannon: If we're going with just one it might be somebody who kind of fits both.

Sometimes it's an economic buyer and an architect kind of character, but we never want it to be too restrictive.

I mean, again, they were usually-- The cost of this is not going to break the bank for a funded startup.

It's more important to make them really comfortable.

And so, yeah we would invite sometimes two people from the same company.

We try to keep it at that 'cause you start all of a sudden you'd have these big companies would want to bring seven people to your advisory board.

And you're like you're going to overwhelm the rest of everyone else.

So we sort of cap it at it two but we would also try to be flexible and let them bring different people at different times.

It wasn't meant to be exclusive, like someone some people would have one person attend in the US and a different person attend in Europe because they were global companies.

So we might have the same company in two different geos, but yeah we never really got it off the ground in Asia.

And we had customers from Asia who would come to the US one, but Asia we never got to the point of getting a customer advisory board.

We're just now starting to build one out in Asia.

Grant: Oh cool. So twice a year was the right cadence?

Shannon: For us it was, yeah. I mean, we would do a virtual one and then a person one.

So it was twice a year for each geo. So we do a virtual Europe, in person Europe. Virtual US, in-person US.

Grant: Okay. So really for a year then, I guess.

Shannon: Yeah.

Grant: Cool.

Shannon: But they were kind of geared so we try to do the in-person one 'cause the CubeCons were kind of split so they were really--

It was kind of like two a year in the sense that we would do the virtual one for Europe when we did the regular one in the US and vice versa.

Grant: Oh, okay. But it wouldn't be virtual and together It'd be like-

Shannon: Not at the same time, but just sort of the same content. So we weren't--

'Cause we wanted to tie it to our store. Like, hey, here's what's coming, here's--

We usually have a lot of questions we wanted to get feedback on.

And they were naturally about six months apart.

So it was of a good way to do it where we'd have a North America and a European version.

Grant: Yeah, okay. That makes a lot of sense.

And then like who owned that? Was that your like customer success leader Dave?

Shannon: Yeah it was Dave and our marketing team kind of helped a ton.

I mean, Pete, Smales, our VP marketing's fantastic. CMO, he did everything.

He's the kind of guy that just never said no and he would take it on, he would run anything any crazy idea we'd come up with.

He was all in and making sure they had hoodies and notebooks and all the likes, but yeah, it was some combination of Connie our amazing event manager and Pete and Dave would pull it off together.

Grant: Got it. Yeah, that's super helpful.

This is like, I always say I imagine these conversations is like us having coffee together and this is just something I've been thinking about recently.

So I'm like, oh, I want to dive deep on that.

But hopefully other folks are thinking about that as well.

I mean, any other like kind of insights or things that you think about a good customer advisory board like what it accomplishes or best ways to run it, any other tips?

Shannon: No, I think the big thing is just try to be consistent. It's hard.

The other priorities start to bubble up.

Don't be afraid to reach out to them on the fly, reach out to them with an email.

Reach out with a note just saying, hey, what's going on?

Don't think that your customer advisory board is sort of sufficient for communicating with all of your customers, right?

So your customer advisory board is one thing but that doesn't mean you don't also need customer webinars.

Like customer advisory board is a subset but there's, you know, usually 10 times as many customers who aren't on your advisory board make sure you're not under communicating to them and thinking you're doing a great job by talking to your advisory board.

So we have to run, you know, there we run Zooms and we run different content maybe a little bit more roadmap content.

That's a little closer and a little less discussion capable when you have 500 people on a Zoom versus 30 people in a room, but it's not sufficient to just run a customer advisory board.

The customer advisory board is more about getting into the weeds a little bit and also getting them talking.

Your job there is to present for no more than like one of the great things that a customer advisory board is to have a customer present.

So typically we'll present for a bit then you'll have one or two customers share their journey and talk about what their big challenges are.

Things they're worried about in the future how adoption is going.

And that gets people talking. So a little bit the less we talk the better in a customer advisory board that's not the case when you're talking one to many in a big customer update.

Those we would do in a more like a webinar.

I would say one of the big things we kind of uncovered on we used to go to webinars our tool in all the online meetups.

We call them online meetups. We never call them webinars.

We do these online meetups.

And the thing we realized was that we always had people on the team whose job it was to answer questions in real time. And so we would get...

And one of the biggest challenges you're out there presenting it's hard to kind of engage and can't really do Q&A sucks on Zooms and stuff but we found that the chat function or the Q&A function in there if you responded really fast and you publish the response out to the whole audience, you got incredibly more questions and then engagement went way up.

So I think I figured that out on like the first online meetup we did all the way back in 2015 was that I could hit reply to all anytime any question practically came in that was at all interesting.

And I would thank the person for the questions.

You know, Darren might be presenting and I'm just banging out responses and it became--

I mean, we would get 500 questions over the course of a two hours. It was insane.

People just like, well, what about this? What about this? I don't understand.

And then you got people like, almost like firing back and forth answers to other people's questions. I'm not sure that's quite right.

You know, and you're like, oh, really, click rephrase and it would go back and it would start more conversation.

And so it was almost like turning.

I was like, I always said I wished Zoom and Slack were one thing when you did a webinar because I want people like heavily engaged if they're going to come to this thing.

And that engagement was value that brought them back.

So they would come back.

It was even more so when you're talking about your customer thing, like, hey, we're showing some new feature.

Well, is that going to be for this? Does that work like this?

What if we're on this version? But we need to upgrade to this.

It's like those questions somebody else might be thinking them.

So you just by replying to all and you just get everybody sucked in.

And all of a sudden what was a kind of dull one directional presentation where someone else is probably on ESPN checking out a baseball score is now firing really fast, but you're not interrupting the flow of the information that you're trying to give out there because otherwise you open it up to real life questions and it just the whole thing grinds to a stop.

So that was hard one little how to make these things interactive was all about the reply to all feature in webinar.

Grant: I love that too, because it creates a reason to show up in real time and like be a part of the live event because generally there's not much incentive and if I can consume something an hour or two days later at 2X speed on YouTube, it's preferable, but if I know that I'm going to be able to really get questions answered and be part of like a broader conversation that's happening then I will show up like at 10:00 AM, PST on Tuesday for that virtual meetup that's really good.

Shannon: One of the things we did too was this was kind of I would say in the height of meetup like remember meetup.com was really popular at the time and it was sort of.

It's kind of waned a bit in the time but we had this great slide at the very beginning of our monthly online meetup where we said, hey, just so you know it's an online meetup.

This is not a webinar. It'd be not a webinar thing.

What that means is we only come when we're ready to talk about tech stuff.

So we come here to demo all live demos no canned demos.

We record, we know we'll record it but because of that crap breaks.

So just get used to stuff's going to break.

We won't leave until all your questions are answered you know, way less PowerPoint and way more demo.

We will have the technical experts will be the people here talking and was like, we made that commitment to the customer.

Then we did a hashtag where you would just hashtag Rancher meetup on Twitter and start posting.

And one of the things we got people to do is just post a picture of you and what you're doing as you watch the meetup.

And it was just the stupid type of thing, but it became viral and people were, you know, with people posting from their car.

I'm listening in my car in Sweden at two in the morning or something.

And we'd have people posting like their whole team getting pizza and eating pizza and watching it from their office.

And it was just like month after month just post a picture.

So we had and we'd always have a slide where we'd put the new ones that came in the previous month.

So we had a slide with maybe 1,500 tweets of people, how they participated but it was those little things that made it.

This is a community we can't do real-- Especially when you're small.

It's really hard to have like Docker could have global meetups all over the world and everybody would come and do this in person.

But we weren't that big. We were sort of a small company and our community was good size but only if you could virtualize.

Only if I could take them all and have them show up virtually especially in the early days.

And that worked so much better 'cause we had a number of people try to start like Rancher meetups in Paris and Rancher meetups in London and they always fizzled out there just weren't, you know, you couldn't bring 200 people or 150 people to an in-person event once every month or two and get enough good content especially if you were the London organizers meetup whereas you maybe could offer a Kubernetes meetup, right?

Like a Kubernetes meet, you could get enough content.

There were enough people who wanted to present and talk and enough vendors who wanted to talk and so being virtual helped us build that same sort of comradery with maybe a more smaller but very passionate group of people.

Grant: And honestly, probably better to consume after the fact too because it was presented virtually not presented in person.

So it's like, it's sort of made for later consumption.

Shannon: Yeah, exactly. One of the things we realized, we just put it all on YouTube.

We put everything up to YouTube, but we put in call to actions in the YouTube videos and those became really good lead generators. Later we started--

Grant: Like, add button in the video like at a certain timestamp and stuff?

Shannon: I personally was doing that figuring this stuff out on the fly, Grant was like, how do you add a button to a YouTube video to download the product?

Like, hey, download this thing. It's right here, get to the GitHub page for K3s or whatever it was we were pitching and promoting.

And yeah, it was just all that hacky stuff is what I don't know if you're a founder that's the stuff that's super fun.

At least for me, that's the memories I have.

They're so good about it is just, you know, and like we just kept adding in planks.

I kept thinking of marketing to me is this house you were building.

And it was like the online meetup would be like your floor and you kept that floor.

You didn't stop doing that, but it wasn't sufficient. Then you had to add walls.

So you'd start doing these weekly deep dive trainings for new users and then you'd have to add a ceiling.

So you'd start adding partner meetups.

So we started doing every month, a masterclass with some partner where it was like or some open-source project and we'd bring them in to pitch something so we could add more value to our community.

Then we start adding things like we had something called a rodeo which was like a two and a half hour deep, deep, deep technical process that was in person at first and then later became virtual as these Rancher rodeos.

We've now had probably, I don't know 20,000 people attend Rancher rodeos, which are half day deep dives on building your company's Kubernetes platform. And 40 people-

Grant: All during eight second presentations.

Shannon: Unfortunately, no. No, these are-

Grant: At rodeos eight seconds is like how long you're supposed to ride the bull for.

Shannon: No, no, I got you. I know. Unfortunately the rodeos were like we'd have to put two engineers on them because so many people would come and they'd be trying--

We had to build a product to make the rodeos work. We had to build this thing like a Hobby Farm.

We had to build an open-source product. You can Google it, GitHub, Rancher or hobby farm to do build like 30 people showing up in a room.

Okay, now I've got to give them all Rancher environments in the cloud working.

Grant: Oh, funny.

Shannon: And so we built a whole product to make this work. The are field with the best field engineering team.

They are so good. Chris Erwin just built a team of absolute, insane, amazing field engineers who just like they built products, they built code.

They would go out there and do things they're much more technical than any SE team I'd ever worked with.

Like, we didn't really hire. 'Cause again, it was Kubernetes in the earliest days we couldn't just hire somebody coming out of, you know, having been an SE at VMware, they wouldn't know Kubernetes.

So we hired people right out of the community.

People that knew this stuff code. And that was all really fun.

Grant: I love that.

It's also, you can tell like Rancher did marketing well because you care about it, but it's also like there's just so much bad marketing in enterprise software.

And so if you really care about it and you take some amount of like almost like a consumer marketing sort of perspective to some of these things you can stand out heads and shoulders above everybody else.

Shannon: It's so true.

And it's funny the little things you're so right because like when I think back at what we did well it's definitely a lot of the marketing, the model the product, but even things like the Shannon, I mean just being Rancher was sort of everything in our space was like ocean themed.

Everything was nautical.

And we were like this weirdly bizarre cow company but it was catchy and people could remember it and they always, you know, they were like I think I've heard of these guys who the hell are they into being just a little bit quirky and different sometimes goes a long way to breaking out of them.

I guess there's just so many companies.

You think about a KubeCon with 300 vendors trying to get your attention. It's hard, it's hard to break out.

And so for us being a little bit of a zig to everyone else's zag worked pretty well.

Grant: Yeah.

Shannon: It's a grind. You just work at it every day. You get it all right and it pays off.

Grant: The other funny thing is you've referenced how big Docker like is/was or throughout this you're like, oh, we weren't as big as Docker and it's like and obviously Rancher has had a much better outcome than had at Docker.

Obviously Docker is still kind of chugging along and they recapped, but like you became the bigger brand and bigger company than Docker did which is funny because you kind of think about how high flying that was and you're talking about it you're pragmatic and small and growing, but eventually it's like the tortoise and the hare kind of thing.

Shannon: Well, for them it was, I mean, they had such an innovative piece of technology.

I mean, Solomon and the teams was so genius that I guess for to me, I always think of what we did as small fries compared to the impact creating Docker.

Grant: Oh, okay sure.

Shannon: But I definitely would say that pragmatic sort of steady approach on the business side helped us in a market that was super dynamic because I mean, you know, but as well as anybody, this market is dynamic it changed a lot between 2014 and 2020.

We must have pivoted multiples. I think of--

I always think of us having pivoted twice like pivoted once to Kubernetes and really like fully all in on Kubernetes and then pivoting again to really embracing kind of Kubernetes without being a distro, right?

'Cause even our first-- You look at our first Kubernetes business was a lot of I want to run Kubernetes on premise.

I want to run Kubernetes on apprentice. Do you have a good distro?

And we were really good at breaking Rancher the product away from our distro.

So people could take our distro but that was a pretty big pivot.

I think that was a big moment when we said if we can't add value to EKS we have no longterm value in the market like that.

When you start with that sort of premise at a technical level, you're saying like, we can't add value to Amazon where we're hosed.

It really challenges your thinking. I remember talking to someone at Cores actually about one of the reasons they sold to Red Hat was they weren't convinced they could add value on top of Amazon that they could get there.

And I think that was a fair point that they had a distro and it wasn't clear without, you know, but we always believe we could do something that would sort of go above the distro level and build something there and build an open-source product that, you know, our story was always, hey, if Docker is open open-sourced and Kubernetes open-sourced then the management plan should be open-sourced.

And we wanted to distinctly play in that management plane business without getting sucked down into it.

But it was hard because the money was all in distros in the early days of selling this.

Like it was like, I need a really good reliable.

And even today when people buy often they're telling us, okay, I need you to support K3S here, and RKE here and EKS here and that's why we have so many nodes.

The size and the scale of our infrastructure.

So it's finding that value in a market where the cloud you know is going to be big, is really tough.

Grant: It's so interesting because we had to make such a similar pivot, right?

Like we had to extract the sort of admin console component of replicated away from our Kubernetes distro.

And it's funny 'cause sometimes people think that Rancher and Replicated are competitive but we do different things and I'm not sure how much you know about our business but like we don't operate Kubernetes clusters.

We like enable third-party applications to bring their software into all these different environments.

And so we had the same thought that we have to be able to install into existing clusters and bring value on top of that existing cluster and bring value to both the IT admin who's managing these third party applications.

And that's a bunch of different integrations and workflows.

But also add value to the vendor when they're distributing their application into an EKS cluster or an OpenShift cluster or a Rancher cluster.

You know, like we never really think about ourselves as like a Kubernetes distro company.

We think about ourselves as like the third party Kubernetes application company.

And so it's just this interesting sort of parallels there and eventually you're like, yeah, the whole point is to be compatible with the ecosystem and to work with Rancher and to work with EKS or OpenShift or whatever else is out there.

Shannon: It's so true. And Grant, I've been a fan of what you guys have done for a long time because in a lot of ways it's very similar to us in the pragmatic approach.

I was talking about back all the way back to Cloud.com where at the end of the day building a company is hard as hell.

And if you can find a niche that you can cross into then you have another chance, right?

Like you can keep going, you get to keep playing.

You're not out at the table.

The problem is sometimes people don't get that and they make these huge bets and they have to be game-changers.

Everybody wants to be the next OS or the next platform whatever it is.

And that's great.

And some, every once in a while people hit but that's like the vast majority of face plants in venture funding are like, yeah, it's going to be, oh, shiet, sorry--.

And I love the, you know, like you guys carved out a really smart niche, like, hey, a lot of these enterprise software vendors are going to need to distribute their software on Kubernetes.

Like we can help them.

We understand that we can learn from what we learned the first one and then learn from the second one the third one and become, you know, we don't have to beat OpenShift or Rancher or anyone.

We can be super differentiated in this group. And then who knows, right? What comes next?

What comes after that? Where do we go from there?

But it's all about getting that foothold that chasm cross especially when you're sitting in a position where you're competing with companies that are just so much more well-funded.

That's, you know, I always think of us in that position but you're in the same position.

Where you're looking and saying, these companies are raising a hundred million dollars.

How are we going to do that-

Grant: Or it's Google and Amazon or somebody like that.

Shannon: Then that's sort of where I'm looking at it always from like, oh, Docker, they raised $500 million Mesosphere was valued at 2 billion and was laughed at, you know, would never saw that we would have any chance against these types of companies.

And VCs told me, you guys have no chance. Dockers is going to own everything in that layer.

You're just absolutely going in the wrong direction.

And so you have to be comfortable saying, that's totally possible.

What you're saying is totally possible but we're going to go for it.

We were here and we think there's an opportunity.

And maybe we can execute really well because while executing companies that are pragmatic that focus on very clear midterm objectives tend to be successes.

They may not be the unicorn successes but they tend to be really good successes.

And I tend to have a lot of respect for companies that build good business, build actual pragmatic customer base.

They tend to do it again and again and they grow from there. So yeah, I'm a big fan.

I think you guys are right on the right spot. And I think you're going to keep making smart decisions like that.

Grant: Well, thank you very much. I definitely appreciate that.

And I think we have the same approach is just like you have to be very long-term oriented, right?

Like this idea you're talking about of like customers that don't choose you and you lose out multiple times but eventually you win it's because you're long-term oriented and you're saying, look, we're going to be here.

You can work with us whenever you figure out that approach isn't right and you want to come here, like we'll be here to work with you and we won't hold it against you.

Like, we will very happily take your money then and help you get successful and you'll be a, you know, we'll create a success story.

And it's both like this that approach from like a mentality.

Like our team, we always try to be very long-term oriented.

I think it's really important the relationships that you build, the way that you treat people and I want to look back in 20 years still running this company and say like, yeah, people love working with us because this whole time we've really created a lot of success and we've never been short term and tried to get the extra nickel or dime here so.

Shannon: It makes perfect sense man. And I think you're taking on the right approach.