Intro

Michael Schwartz: Hello and welcome to Open Source Underdogs. I’m your host Mike Schwartz, and this is episode 48 with Ev Kontsevoy, CEO of Gravitational.
This episode, it’s a little longer than most, clocking in closer to 45 minutes. That’s definitely because Ev has such a broad breadth of technical and business experience, we probably could have gone on another hour.
If you want to hear a little bit more about the tech stack, watch The FLOSS Weekly, episode 529. I’ll put in a link on the episode website.
Gravitational has two very interesting products, and they are somewhat related but also a little different. It must have been a tough marketing challenge to come up with a unified message, but apparently they did it, because the company’s been super successful by all measures.

So, without further ado, let’s cut to the tape. And after you listened to this podcast, I’m sure you’ll want to check out Gravitational’s website for more info.

Ev, thank you so much for joining today.

Ev Kontsevoy: Thank you for having me, Mike.

Story Of Mailgun

Michael Schwartz: Before we talk about Gravitational, can you talk a little bit about your previous startup called Mailgun and your experience at Rackspace, and how that led you to identify the business opportunity for a Gravitational?

Ev Kontsevoy: Mailgun was interesting, and for those who don’t know, Mailgun is an API platform to send and receive emails programmatically, so it’s email for developers. If you need to send a password recovery email, or if you need to send newsletters to your customers, you just use Mailgun API to send those messages and collect responses.

That company was interesting to me because of two things. First, it was founded in the middle of financial collapse. I moved to New York City around 2009, right when the economy was self-collapsing, I guess. And it’s also when AWS was beginning to happen, which is always interesting, like, which means that when everything is crushing around you, there is always some positives. And I thought, well, if Jeff Bezos can sell APIs to servers, I could probably sell APIs to emails.

And the reason for that is that if you’re moving to the cloud, you cannot really take your things with you, so whatever email delivery appliance you used to have, like you need to have a virtual replacement for it, that’s how Mailgun really got started. It was really tough, raising money back then for a project like this, because most investors didn’t understand what an API was. I would do a presentation, and then an investor will pull out a Blackberry. And he said, “All right. So, I got my Blackberry here out, so how do I use you API?” At that moment, you know that you lost, that this is not going anywhere.

But then, an interesting thing happened. A Twilio got funded. And everyone paid attention because Twilio said, “Oh, we are API for developers to do, like, SMS.” They started saying that Mailgun is simply a Twilio, like Twilio, but for email. And it helped tremendously.

So, we got accepted into Y Combinator, in 2011 actually, and went from there. I ran the company for a couple of years and eventually got acquired by Rackspace, by one of the cloud providers.
So, the interesting thing I learned from that experience – well, it was my first company, so you’ll obviously learn a ton if you do that – but as a technologist, I wasn’t prepared to be exposed to so much…let’s just say crime. That’s what it is really. Because email is a really dark world, so many shady things happen via email. You know, fishing, and viruses, and spam, and I would say that 80% of my attention was consumed by those problems, as we were running that company, which is unfortunate, because you actually want your real users, engineers, developers to enjoy, the product, you want their experience to be great, you want performance to be great, you want documentation to be amazing. And you constantly have to deal with spammers, fishers, and all parts of bad, bad internet.

So, that was my Mailgun experience. And the reason we, I guess, decided to sell that company to Rackspace, is because Rackspace at the time had very compelling vision, for using open source and open standards to free the world from AWS dominance.That was kind of resonating with me because I started my career as a software developer during Windows dominance. And I just remember how boring and bleak everything felt, just operating within constraints of what Microsoft thinks you should be doing. And, yeah, so that was the story of Mailgun.

Technical Origins Of Gravitational

Michael Schwartz: You know, it’s a totally different answer than I was expecting.

Ev Kontsevoy: What did you expect?

Michael Schwartz: I was listening to another episode, or another interview with you, and you spoke for some time about some of the interesting technical challenges around how complex Mailgun was, and how you were considering replicating it on a different cloud, and how completely, like just, it seemed like such a big challenge. And I was wondering if that sort of gave you some technical ideas that might have led to the development of the Gravitational, like, technology stack?

Ev Kontsevoy: Oh, so, that’s more interesting question – how did I go from being an email person to effectively ending up almost in the security space. So, what do you think happens right after an acquisition, when one technical company acquires another technical company? It happened with us, and maybe, like, when Facebook acquired Instagram, there was probably something similar there, the first thing they ask you to do is, start planning to migrate all your stuff into their own infrastructure.

Especially for Rackspace. Rackspace’s a cloud provider. It would be really strange for them to have an email service that’s not using their own cloud. And at the time, we were using SoftLayer, which is now part of IBM – old-school, bare-metal servers, and migrating to a public cloud on Rackspace, which was virtualized and had all these fancy infrastructures as code capabilities. It took us a long time, I don’t remember exactly how long it took, but let’s just say if I say 6 months, it’s not going to be an exaggeration.

And I remember having a conversation with someone in my family, maybe it was even my wife, where someone asked me like, “So, what are you doing – like, now, post-acquisition – like what are you building?” And I said, “We’re not building anything, we’re just moving from SoftLayer data center to Rackspace data center.” And that person wasn’t technical, and she said, “Isn’t that, like, copying files over the internet??” “Why is it taking six months?” Like, “You have that many files??”

And I laughed. But at the same time, it was kind of illuminating. Like, normal people think that copying software from one data center to another, it’s something that happens within few seconds.
Wouldn’t you probably feel the same, like, what is software, is it just some files, you have software on your laptop, I have software on my laptop, like, it’s just copying things around, but apparently, when it comes to data center software, to what we call cloud software today, everything takes months.

And, at the time, I just kind of took this for granted, like you’re sure it’s a complex problem.
We have completely different security here, we’re going to have that over there, over here we are using this kind of load balancing, over there is going to be different kind of load balancing, and the code needs to be updated, and so on and so forth.

But then, when I became a “racker” – that’s how Rackspace employees called themselves, I was a proud Racker by the way, I love that culture – so, once I became a racker, I got exposed to vast representation of cloud users out there, companies who use cloud computing. And I was talking to them usually trying to understand how can we improve, how we can make our cloud offering better.

And I was amazed how frequently they will bring this problem that I had with Mailgun. It’s like, “Hey, we’ve built this application, and it’s running on AWS, and now we’re trying to run it on Rackspace, and it’s really challenging. Can you help us?”

Or they would say, “We want to use Rackspace, or AWS, or Azure, some kind of cloud provider to build applications, the development environment, but for whatever reason, we need to actually run it in Luxembourg, like in the data center that is supposedly compliant with whatever regulations there are under.

So, how do we have staging environment in one place and identical production in a completely different place? And they kept coming to us looking for advice. And sometimes, we would be able to sell them something, you know, like DevOps as a service, or security as a service. But generally, I just saw this trend is that people feel like they’re chained to their cloud environment.
It doesn’t even matter how amazing that environment is.

But not being able to just take your production and have like, I don’t know, a hundred copies of it running all over the world – it’s extremely frustrating. And it’s limiting to a lot of use cases. You know, latency is important. Because the laws of physics, they don’t really change. So, you have to be able to run your code, close to where your data sets are. Data sets are distributed, which means that code needs to be distributed.

And that’s what I became deeply dissatisfied with SaaS model, in general. I don’t think there is anything wrong with Software-as-a-Service, but there is definitely something wrong with software-as-a-service running in a single place.

And as I was talking to more and more companies, I realized that some of them – check this out – they can’t even recreate their production environment in a different Amazon account. Those are companies based in Silicon Valley by the way.

So, let me just kind of zoom into this use case: you have an application running in an AWS account that you have – you control that. Go ahead and create another AWS account from scratch, also yours, so you have full, you know, God permissions for both accounts. And then, have a full replica of what you have in one account and another. And a surprising amount of companies don’t know how to do that.

They just overtime kind of lose institutional knowledge of what would it take to recreate everything from scratch. And as an engineer, you probably understand why that is happening, because you know, when you start building your application, like in the early days, not a single line of code is written, but you’d know that you need some environment.

You’re going to go and click some buttons in that AWS panel, maybe you’ll write some terraform, or cloud formation, but not always, maybe use Ansible, so, you kind of start manually creating first layer of your future environment. Then you start adding things on top, then you start deploying your code, maybe manually at first, maybe SCP. And then, you move to something, I don’t know, maybe like Ansible, or Chef, or Puppet.

So, things happen over time, and not everything is documented. Some scripts, they run daily, maybe they are part of your CICD pipeline. Other scripts you ran three years ago, and maybe the person who did it is no longer with the company. So, the point is, almost any cloud environment today, it’s built with many layers that are created over time by different people.

And that’s the reason why they’re not reproducible. And a company needs to have, you know, we need to have seven regions all over the world instead of one. Or we need to run our software inside of someone else’s AWS account. Or we need to deploy into GovCloud because government wants to use our software. They run into all these issues that they’re chained to one specific environment. And that’s why Gravitational was born. That’s the company that a bunch of ex Mailgunners started. So, that’s maybe a different answer to your original question.

Products

Michael Schwartz: So, let me drill down a little bit more, Gravitational has two products, Teleport and Gravity. Which was the first product? Or were they both coming at the same time?

Ev Kontsevoy: It’s basically a packaging question. We initially built a solution, so if you want to run your software in many different places, you have to solve many different issues for that. You need to separate your application dependencies from infrastructure. You need to solve remote access problem, you need to solve compliance problem – because a lot of these companies, like the reason they needed to be in the different place is because of compliance requirements.

And we had – what I would just call a code base, a bunch of GitHub repositories. We have this culture internally that we create GitHub repository per library. So, we break everything we built into these libraries. Each library has its own repository, and then we compile the software, and then, we produce solution.

So, originally, everything we built was just a collection of these repositories. And we started to sell the solution called Gravity, and Gravity includes everything we do. Gravity is a complete platform. With Gravity, you can take your AWS account – technically, it’s a Kubernetes cluster, but let’s put that aside for now – and you could save it all into a single file. That’s your image, we call it “cluster image”.

Think about like doing a snapshot – it’s not a snapshot, but I think it’s a helpful analogy – and then you can move that file somewhere else, and you can create exact replica. So, you take this image that contains the full copy of your production environment, and you can copy/paste it all over the world, and you can have thousands of identical environments created from that image.

So, the question then becomes, how do you keep them up-to-date, how do you push software updates, how do you fix the vulnerabilities, how do you troubleshoot problems that happen remotely. So, you do need to have some kind of remote access to those environments. Interesting analogy that I like is software updates built into operating systems.

If you have a Mac, it somehow updates itself, it downloads things from Apple, it applies these updates at reboots, and all of this kind of is just working automatically. So, think about it, from Apple’s perspective, how is that different from running a massive software deployment to hundreds of millions of servers running on untrusted network all over the world, with unreliable internet connectivity. For a typical data center person, that is a Star Wars level tech. And that is what Gravity tries to do with data centers, with your cloud account.

And this component that allows you to securely download and apply updates, that is what Teleport is. It is basically a part of Gravity that enables this world-class security into this restricted, regulated, remote environments, where Gravity is usually running.

And at some point, we thought, why don’t we make open source available for people to use as their own software update mechanism in their own kind of applications. And we open-source that, we put documentation in a separate place. And what we discovered very quickly is that people realize that it’s a much better way to do SSH than open SSH oftentimes is. Which was completely unintentional, but it was kind of nice for us because suddenly people started to discover Teleport, and download, and use it more. And basically, it’s a really good way to access infrastructure right now.

So, whatever you’re using to SSH into your servers, or to access your Kubernetes cluster, you’re probably using something worse, so I highly encourage everyone to check Teleport out. It’s free, open-source, Apache license. So, that’s how it happened – everything was built at the same time, but Teleport, just by accident, developed its own fan base, so to speak.

Revenues By Product

Michael Schwartz: In terms of revenues, which product is more important?

Ev Kontsevoy: It’s hard to say. I think both of them are doing really well, and Teleport is definitely not as expensive as Gravity is because it’s not as foundational to company’s business. Because we have Gravity customers who basically run massive, they sell a lot of software into these remote locations and deliver it with Gravity. So, Teleport, it’s usually part of a platform, it’s not the whole platform. So, it’s cheaper per deal, but we do close a lot more Teleport deals.

Marketing Message

Michael Schwartz: Have there been some challenges around finding the right marketing message for this platform?

Ev Kontsevoy: Absolutely, absolutely. I do think we’re still searching for the right way to describe what we do to the world. There are people out there who believe that Gravitational is a company that helps you take your SaaS application and sell it as a kind of on-premise environment. And it’s fine. Yes, we can do that, and we can do it better than anyone else.

But to me, that’s not really the reason why I decided to spend significant, you know, invest a portion of my life into this company. We want to enable a completely different software distribution model. Think about it like push versus pull.

We believe that the reliance of DevOps team needs to be reduced. The fact that most companies today have to set up and maintain these complex environments, with so many moving parts, and have these massive DevOps teams that constantly struggle with this ever-increasing complexity of this environment – it just feels temporary to me. It’s got to be simpler.

The typical DevOps picture at a company, like average company today, reminds me of what you would read in a history book about early computing.

Remember those stories about old electromechanical computers that would take up the whole room in the building, and you had cockroaches and bugs crawling in, and you had special people called debuggers kicking them out with broomsticks and replacing vacuum tubes and relays, computing was like a manual job, you had to have people walk around and constantly do that.

That reminds me a little bit about like a typical cloud environment today. I think it should be sealed, fully automated with zero human presence. So, if you walk into a data center today, you’re actually not going to see that many people, probably you’re not going to see anybody at all. There’s going to be some security at the entrance, but inside, it’s going to be quiet, no people.

So, I want that to be true for virtual access as well. Even though there are no physical people in that data center, but you could be assured that there are probably hundreds, if not thousands of DevOps engineers, maintaining those machines basically manually. And the purpose of like the goal for Gravitational is to make it not so. We want this all to be completely automated, similar to how millions of Apple laptops download software from Apple, apply patches, and keep running. I see no reason why a typical cloud environment for a typical company should be very different from a MacBook.

Value Prop

Michael Schwartz: How do you convert that into like business peak? You know, because it’s sort of, like, what you’re saying is almost like a kind of “sale to the guy with the hands on the keyboard”. Is there a way to convert that into like actual value proposition for the business customers?

Ev Kontsevoy: Well, first of all, let’s be honest with ourselves – can we do this today? Let’s just take a random company that have nothing to do with, let’s say –

Michael Schwartz: – eBay.

Ev Kontsevoy:  eBay. Can they make all of eBay run similar to a MacBook, with no DevOps team or server today? No, I can’t. There’s so many problems. Like, it’s a complex challenge. So, it’s going to take us many years to actually solve all of these challenges. But what you can do, you can start looking into where DevOps teams are overloaded today and start pushing that needle.

So, for example, if you try to run the same application, let’s say in a hundred different places, you will quickly realize that secure access is a huge problem. Because all these different cloud environments, they have their own tools for accessing infrastructure. And then, you have this like open-source ecosystem that all these components need to be integrated and everything used to be secure. And it begins with SSH, and it ends with Kubernetes access, and then you have, like, internal things, like Jenkins, maybe how do you secure access to Jenkins – all of these problems, they become extremely complex if you try to run more than one production environment.

So,okay, now we have a security problem, we have this access problem – that’s what Teleport solves. So, maybe I cannot promise you that your DevOps team will have nothing to do, but I can promise you that your secure access will be taken care of. You no longer need to have a competent team of infrastructure security people.

Or, if you have one, from now on, they can focus on other things, we will take your security problem away. And it doesn’t matter if you have a single cloud environment or 56,000. So, think about any like retail business, like McDonald’s or Taco Bell, they have tens of thousands of restaurants all over the world, each of those is actually a small data center. They have computers in the back, but can you dream about updating software and those locations, using like regular open SSH and let’s say Ansible? That would be quite, let’s say, inconvenient.

So, here’s the problem that we already solved for them. I do think that our strategy will be to just declare that going from 0, which is where we are today into this bright future, where all software runs by itself magically everywhere, we need to solve 57 problems.

Alright. So, let’s outline what those problems are. I think it actually helps because maybe some other startups will help us. Maybe they will solve disaster recovery or backup problems, but we will concentrate on security first. So, that’s how Gravitational is executing today.

Both Teleport and Gravity, they are very much security and compliance oriented. Because, if you want your code to run globally, you have to take care of that first as basically problem zero. That’s why we focus on it for now.

Free V. Commercial Offering

Michael Schwartz: So, a lot of open-source companies, they open-source a funnel for customers who might want to engage commercially. What does the sales motion look like at Gravitational? Is it try by fly, and what’s the effort to bring on these large customer accounts who probably pay the bills?

Ev Kontsevoy: Look, I’m going to be honest with you. We don’t really have a clearly defined strategy that’s documented for example internally, like how do we upsell open-source users. We simply try to — I think we have a following approach, we want to make sure that if you are an individual, like a developer who is curious about where technology is going, someone who has a home lab in their apartment, or a couple of Raspberry Pi’s that they’re running a little toys on – we want to have something for you.

We want you to get access to Gravitational vision, we want you to find our projects interesting. So, we’re going to have something for you. Yes, it’s going to be free, yes it’s going to be open source. We’re not going to sell you anything because you don’t really have problems that we solve at commercial level.
So, then if you are a small team, let’s say about three, two, 20 people, and you are working on some young project, let’s say your startup, we want to have something for you as well.

Then finally, if you’re a large enterprise, let’s say you’re IBM, and you have some problem, we are going to have something for you as well. Every time, we look at the capability that we are introducing into one of our products, we will always have one of those three use cases in mind, simply the size of the team. One-person small team, and then giant team. And it just so happens naturally that things that giant teams want, they are willing to pay for them.

And things that hobbyist would want, I think trying to charge money for it – it is just ridiculous. At least for us. And that’s how we naturally end up in the split, what is a commercial offering and what is free and open-source offering.

Is Gravitational Open Core?

Michael Schwartz: Would you say that Gravitational is open core?

Ev Kontsevoy: I would say no, we are open source, like we are open-product company. Everything we make is open source. We have a tiny bit of proprietary magic dust that we apply to our open-source products, but that dust just happens to be critical for large companies. In other words – let’s talk about a simple use case – you want your engineers to SSH into their machines, in the most convenient way possible. You don’t want to like annoy anybody with additional stuff.

But you also want this to work across all kinds of cloud environments, you want this to work with, you know, IoT devices out there in the field, you want this to be compliant with all these different regulations that your customers want you to be compliant with.

You basically want the best in-class security and compliance, but you don’t want developers to be inconvenience.

Okay, which means you have to use identity-based system. In other words, if a developer, who wants to access something, they need to go through some SSO process, once a day, nothing crazy.
And, usually, if you look at small teams, what do they use, everyone uses like Google Apps and maybe GitHub, which is naturally what are open-source products for. But if you look into what giant enterprises use, you will start discovering products you’ve never heard of. Like, I think SalePoint, and you obviously want Teleport to support those things. And that’s what we’re going to charge you for.

Another thing too is, if you are a giant enterprise, you are going to have all these different teams and different groups, you might have infrastructure developers, or like NetSec team, or you’re going to have like some auditors. So, in other words, the composition of your teams is complicated. And you need highly granular role-based access control.

So, this extra granularity that only large companies require, that’s another proprietary thing, like from our perspective. So, we basically try to attach – we try to draw the line between open source and enterprise offering, basically based on a company size. Because large companies, they need things that are not even obvious to startups.

SaaS Gravitational?

Michael Schwartz: A lot of open-source entrepreneurs, they love the SaaS business model. I’m sure you’ve kicked around some SaaS ideas. Is there a SaaS Gravitational offering, or are you thinking about one?

Ev Kontsevoy: It definitely makes sense. Yes, we do run into accounts every once in a while who simply say, like, “We love your tools, this is unbelievable, but believe it or not, we right now have zero engineers available to set everything up, to get up and running. “Can you just do it for us, can you run it for us?” And we listen, and we, let’s just say we’re considering it.

Pricing

Michael Schwartz: Most of the companies in this space are using a per-user metric for gating. I’m wondering if you’re using that strategy, has it worked for you, is it a good proxy for value and a good way to land and expand?

Ev Kontsevoy: I just told you what our internal motivation is, what we’re actually building – completely autonomous unmanned, operational model. So, it would be strange for us to charge you based per on number of users if we believe that software needs to run without humans standing around.

Difficulty here comes from the fact that we’re not there yet, so yes, you do need DevOps engineers SSHing into boxes every once in a while. But I believe, if we succeed over time, like the need for that will disappear. So, if we, for example, adopt a business model that we’re going to charge you based on how many SSH users are manually accessing servers, that pricing model will not be compatible with our long-term vision.

Even today, I would argue, without even Gravitational technology, if you have a well-running operations, but you are a Cloud environment, you should not be giving SSH access to your production environment, to all of your engineering team.

Ideally, very few people should be able to do that, and ideally, there should be no need. Especially if you’re running on a modern cloud, you can simply like kill things that misbehave and recreate them from scratch very quickly.

Michael Schwartz: So, what gates do you use?

Ev Kontsevoy: It’s based on your footprint. If you’re running large applications, you’re processing tons of data, you’re present in many data centers all over the world, you have tens of thousands of services based on that, we will charge you more for our solutions.

How To Gauge Deployment Size?

Michael Schwartz: In the Kubernetes world, servers are so ephemeral. You get a lot of servers when there’s a big demand and less servers when there’s less demand. It seems like all those per server, per CPU models are so challenged in the new Cloud Native world – how do you gauge the size of a deployment today?

Ev Kontsevoy: Well, I would argue that per server, per CPU, per RAM pricing, it’s not getting obsolete. If anything, it’s getting more and more popular with – like, look, AWS themselves. That’s what they charge you for. Yes, it is more challenging to accurately meter usage, but generally I would say that usage-based billing is the future for almost everything we use in a data center today.
So, for Teleport SSH access specifically, we look at how many servers we’re using. And for different companies, we offer different options there because there are different business models, and that’s the reason why we do custom quotes for every account.
For Gravity though, I do believe that the value we provide is based on how many environments you’re going to be running. Let’s say, if today, you have a single-production environment, then tomorrow, you’re going to be in a hundred production environment – it’s the environment. Like, the number of environments, that’s the value that we give you. So, then we’re going to charge you based on how many environments you have. We don’t really care about how many servers you have in each.
And environments, they rarely jump too quickly. So, it’s kind of slower moving targets. And that’s how our pricing is built on for Gravity site.

Does Open Source Help The Business?

Michael Schwartz: Has open-sourcing the software really materially helped the business?

Ev Kontsevoy: Absolutely. Because it’s the best form of marketing you can do in our market. We are all dreamers. I believe the technical founders and companies that are started by engineers, they almost always have this dream component attached to it.

And you want to find people who agree with you that future is going to look different, the future is going to be moving this direction and not that direction. And that person is probably also technical. And the best way to communicate with that person – and it has always been like this – is to show me the code, let me play with it. Because that’s how we collectively dream together, by downloading each other code, installing it, playing it, and then communicating, and sending each other pull requests and criticism. That’s just the best way for, I think, mankind just collaborate and move the progress forward.

And if you don’t do that, if you use proprietary kind of code in the cave mode, then you’re basically guessing. You’re saying, “Hey, I’m going to go and work on this problem for a year.”, and then I present you with the solution. If solution works for you, you’re going to buy it. And if solution doesn’t work for you, you’re just going to ignore me. And that’s just a much slower way, to get to this optimal state of offering something that the world truly needs.

So, it’s really hard for me to even think differently right now. You see, with Mailgun, it was different because the problem was so obvious. The problem was basically this: the world needs to send and receive email. And there are solutions for it already, and you have them in your data center.

And now, you’re going to go be in the cloud, so you cannot take your solutions with you. So, you need to have a cloud version of it. All right, sure, here’s one. But Gravitational is much more visionary company that we just want to change the way how cloud software runs. And if you’re going to start working on that problem, doing it in the open, it’s the only way I see how it could even be accomplished.

Portability Of Startup Experience?

Michael Schwartz: This is an unusual question that I haven’t asked before, but you sort of backed the question a little bit. You know, I’ve actually started more than one business – Gluu’s my fourth business – and one of the challenges I found in starting the second business was I applied a lot of the lessons from the first business to the second business. And it turned out that the second business was so completely different that actually like I shouldn’t have.

And I’m wondering, are there any cases where – I mean, certainly you learned a lot in the first business, that helps – but was there any like things that you feel like maybe the first experience led you to something to take longer to figure out?

Ev Kontsevoy: Actually, the Gravitational in many ways is anti-Mailgun. So, Mailgun was proprietary code-based SaaS. Gravitational is open-source software that you can download and run. So, from the beginning we knew that our ability to borrow from Mailgun experience is going to be limited.

So, that allowed us to bypass a lot of these potential problems that you’re referring to. However, what was helpful and applicable is just the mechanics of starting and running the company. You know, raising money, incorporating, setting up like basic processes. So, a lot of that you could just fly without even thinking and do exact same things, simply because a lot of early-stage startups are surprisingly similar. So, copy/pasting that experience into your present, I think it’s totally applicable.

Why Leverage An Incubator For A Second Company?

Michael Schwartz: You chose to go to Y Combinator and raise seed funding and go a pretty traditional startup route. But you didn’t have to go that way, you could have probably bootstrapped it. I’m wondering, why did you think going the traditional route made sense, given that you probably had some capital and some experience and maybe could have done without it?

Ev Kontsevoy: Because it worked previous time. You see, I’m a technologist, I’m not a professional entrepreneur. Like, incorporating, raising money, doing all these things – it’s boring stuff. So, it worked wonderfully for us at MailGun, going through this traditional sequence, through Y Combinator seed stage, and so on and so forth. We just did the exact same thing, we would concentrate and spend my time on actually building interesting products and solving problems, because that’s really the reason you’re doing it. Everything else feels almost like distraction.

Yes, you have to do these things, but at the end of the day, they’re not differentiating, they’re not going to define if you’re going to be successful or not – it’s simply getting resources, and office space, and processes, and 401k plan, whatever, just getting it done as soon as possible and moving forward – that was the goal. And look, Y Combinator, they’re very incredibly efficient at getting all of their startups through this early stage, so I highly recommend it.

Team

Michael Schwartz: So, you’re currently in the Bay Area, are you planning to recruit most of the team in the Bay Area? Maybe you’ve already, like, diversified quite a bit – what are your thoughts about building the team in the next couple of years?

Ev Kontsevoy: If you’re asking me, like, what I recommend – I don’t recommend anything. I think it always depends on founders and company culture. There is always this popular question, like, “Shall I go 100% remote, or should I have an office?” I don’t know the answer to that question, there are pros and cons, but what we’ve decided to do is that we want – there are smart people all over the world –we don’t want to discriminate based on either they are in Bay area or not. We want them to be involved, we want them to join the company. And we quickly realized that Seattle actually is the capital of cloud computing of the world. It’s not Bay area.

If you want to recruit engineers who understand what kernel variables are, who understand differences between file systems, who can troubleshoot lost packets in the network, you will have a much better time finding that talent in Seattle because every single public cloud provider is there. You know, Azure, AWS, GCP, it’s all sale companies, even smaller clouds, like former CenturyLink Cloud, in the Oracle Cloud, original team was based there.

So, Seattle, it’s the highest concentration of cloud computing experts. And for that reason, our engineering is actually based in Seattle, even though the company is headquartered in Oakland Bay Area. But we’re also open to hiring people all over the world. We have a small office in Toronto, we have remote people on the east coast, and Germany and Italy. So, we’re constantly evolving in our views on what kind of culture we want to have. It is challenging, it’s not easy.

How To Scale Beyond Startup Phase?

Michael Schwartz: So, you’re in an interesting stage in the company’s development, where you’ve had quite a bit of success, and you’re sort of scaling to the next level. Any advice for entrepreneurs who find themselves in that situation, in terms of, like, how to adjust to this new sort of focus on sales and marketing, especially for technical founders.

Ev Kontsevoy: You just gave them advice – do not ignore sales and marketing. Think seriously about sales and marketing. Something that I learned in my journey, going from engineer to entrepreneur, was that building a sales team, building a marketing team, is absolutely similar to building a product.

So, just like you have an engineering team with your processes, you know, for example, no one can commit to master directly, you have to do your own branch, and a pull request with a code review. And all good engineering teams, they have processes, and then the coding style, and like which programming languages we allow, which ones we do not allow – building this takes experience, building this takes a lot of brains, and doing it well requires a lot of energy and discipline. It’s really tough. So, this is why top technologists are so expensive. And that is absolutely true to yourselves and marketing teams.

Doing marketing and having a marketing machine that’s operating properly also takes a lot of brains. No, it’s not obvious, no, you can’t just read a couple of Golden Books and go do it yourself. And then, the same thing with sales.

So, underestimating the effort and sophistication of sales and marketing activities I think is quite common amongst engineers. So, simply building and expecting that the users will come – it rarely happens. You have to just approach those problems with, I would say, seriousness, and everything else will come from there. Because if you’re not stupid, if you do have engineering approach to everything, simply putting yourself into that frame of kind of mind, will help you solve sales and marketing challenges.

Advice For Entrepreneurs

Michael Schwartz: Last question, any advice for new entrepreneurs launching a business around an open-source software project or product?

Ev Kontsevoy: Yes. I would just say, forget about that word, don’t call yourself entrepreneur – that’s a distraction. Think of yourself as a product person who tries to solve someone’s problem, and just focus on that until you have overwhelming evidence that it is indeed happening. Because at the end of the day, company is just like a vehicle for allocating and distributing resources. This is what it is. It’s deeply secondary to what you actually trying to do. So, if you want to change the way how backups are done, just focus on that and just forget about incorporation, what kind of company you want, what kind of investors you want – all of that, it’s not primary to your success.

You have to understand what your solution is going to be, how it’s going to be different, how it’s going to be better, who is going to like it, who’s going to not like it – solving all of these problems and just focusing on that before you even begin to think about entrepreneurship is probably key.
Because one common thing I see in “entrepreneurial circles” is that people basically start with this, “I want to have a company.”, and then, they start looking for problems to solve. It just feels very unnatural to me.

Closing

Michael Schwartz: Ev, thank you so much for going over a little bit on time and for sharing all your experience, and best of luck with Gravitational.

Ev Kontsevoy: Thank you very much! Thanks for having me, Mike.

Michael Schwartz: Great job by Ev, isn’t it? Editing by Ines Cetenji. Transcription by Marina Andjelkovic. Cool graphics from Kamal Bhattacharjee.

Music from Broke For Free, Chris Zabriskie and Lee Rosevere. The podcast Twitter handle is @fosspodcast. Follow us. Retweet the episodes, help us get the word out.

Next episode German-British-Kiwi, Martin Buhr from Tyk, one of the coolest open-source API Management companies around.

Stay safe everyone. Until next time, thanks for listening.