Avery (00:00):
The internet is no longer living up to the expectations that we had of it in the 1990s.
Sara (00:04):
Welcome to Spotlight on a podcast about how companies are built from the people doing the building. One messy, exhilarating decision at a time. Welcome to Spotlight On. I'm your host. I'm Kumar, and I'm here with Avery Pen Run, the founder and CEO of tail scale. Thanks, Avery for joining us.
Avery (00:20):
Hey, nice to be here.
Amit(00:21):
Before we get into tail scale and the founding story and what led you to this, maybe you could walk us through a little bit about your background. Who are you? And you have a pretty remarkable background and lots of different things that you worked on. You came from Google, maybe you could walk me through that a little bit.
Avery (00:36):
In high school, I worked at the first internet provider in my hometown of Thunder Bay, running the systems there. First there was the nonprofit version, the Freenet, and then I moved from there to the first commercial internet company where I set up their servers. I went from there off to University of Waterloo where we did co-op programs. I worked at six different companies. One of those companies was one that I started like, well, we should learn what it's like to start a startup. That one got a little out of control and ended up getting acquired by IBM in 2008. After that, I went and worked for a brief period in the banking industry, which was very educational, but turned out not to be my thing really. Then I went off to Google. I worked on Google Fiber primarily and some other side projects while I was there, and I came out of Google and wasn't sure exactly what I wanted to do, but I decided I wanted to be back in the startup world. The big companies were not exactly my thing.
Amit(01:24):
And what'd you do at Google?
Avery (01:25):
I started off in the Google Wallet team, so if you ever noticed a little attachment button at the end at bottom of an email that lets you attach money, that was the team that I was working. It's your
Amit(01:33):
Fault.
Avery (01:34):
Yeah, well, I, yeah, and I wouldn't say that feature was spectacularly successful, but it actually, it launched and people use it. It was pretty interesting. Cool. It required, it used my banking industry experience, which is the reason they put me on that team in the first place. And it was exciting because people had been trying to launch that feature for I think five years and just failing over and over again. And then one way or another I showed up and either got lucky or pushed it over the finish line, which was pretty fun. After that, I went and worked in Google Fiber, which of course is internet service going back to my high school days, but maybe a thousand times faster in terms of bandwidth. And there we were building wifi routes. So that was my team building the home wifi routers that go come with your internet service.
Amit(02:16):
And then once you were out of Google and you were sort of exploring ideas, you had a friend at VersaBank who kind of pulled you in to solve a problem for them. So this wasn't even you ideating, this was just you trying to help out a buddy.
Avery (02:28):
Yeah, he was stalking on LinkedIn and found out that I was no longer employed and the day after, which is also what he did my previous two jobs, the day after he found out I was unemployed, he was like, Hey Avery, I've got a problem. You want to help me fix this problem? And I'm like, well, I'm thinking of starting a startup, but we don't have any ideas yet, so sure, why don't we go and try that? So yeah, we went and visited him and looked into his problem and was like, oh, this is interesting. I bet we can solve this in a weekend. And we built the project in a weekend and that project that we built turned into tail scale.
Amit(02:58):
What was the problem that they had that you needed to solve?
Avery (03:01):
So the problem they had was they have banking software and banking software is sort of famously not leading edge technology most of the time, but this banking software didn't have two-factor authentication. And they had had a security company come in, do an audit and say like, Hey, someone who can get the password from someone on your team could log into this banking software. And if you do a phishing test, which I don't really recommend, there's no point doing a phishing test because somebody at your company always fails the phishing test. But if you do a phishing test, you'll get maybe 20% of your team will accidentally give up their password, which meant it was definitely possible to break into the core banking system and start transferring money around and they're like, look, we have to fix this problem. How do we get two-factor authentication into this legacy banking software?
Avery (03:44):
And so we brainstormed for a while until eventually I said, Hey, what if instead of putting two-factor authentication into the software, why don't we move the server onto a network and then VPN to the network and put two-factor authentication in the VPN? And they said, don't know what you're talking about, but seems like a good idea. And we're like, alright, all I need to do is find A VPN that's going to be good. If you leave it on all the time and you put it in the office and it uses two-factor authentication and it integrates with your Azure ad, surely I can just go buy that off the shelf and we'll be done and I'll go back to what I was doing and I could not find a product that was going to be good enough to solve that problem. So I'm like, alright, fine.
Avery (04:19):
This new thing called wire guard just came out. It's a really good VPN, it's super reliable. We can leave it on all the time. It's not going to break. I just need to make it work with two-factor authentication. How hard can it be? So we slapped something together, plugged it into Azure ad, which I think was, was it still called Azure AD at the time? Maybe it was. I can't remember. Whatever Azure AD used to be called. We plugged it into that and it was basically a key generator for wire guard that we built in a weekend and it worked and he was really excited. And one thing that was interesting about it, this was pre covid, this was back in 2019, shortly afterward, COVID hit and because of the way the system worked, it was always VPNing into the network that ran the banking server as he could send all of his employees home on their laptops and nothing changed. They didn't have to reconfigure anything and still their banking software worked, which is weird side benefit that we hadn't even been planning for. And when that happened, we sort of realized we actually had something on our hands. It's like, wait a minute, this is way more powerful than we intended.
Amit(05:18):
That was the moment when you thought that lots of companies need to be using this.
Avery (05:21):
Yeah, we originally thought we were going to do a bootstrap software company and why don't we just slap some stuff together? We can pay three or four people, no problem with a relatively small product, who cares? And we just realized this thing is like, whoa, we can fix so much stuff. This deserves to be a bigger project that we can't just self-fund.
Amit(05:41):
Maybe walking back a little bit, how did you form the early team to go after this and then what was the process about going after and scaling out from one customer to an early set? And one thing I think all our listeners know is that has done an incredible job of building the most special community of folks and developers that love tail scale. I mean there's this unique product love in the community. How did you go from zero to one when it comes to that?
Avery (06:07):
Well, this is where, and I know people don't always believe me when I say this because I'm Canadian and people accuse me of being too modest, but I am telling the truth here, we didn't know what we were doing and we're like, well look, our costs are really low. Let's try some stuff and see what happens. So the first thing we did is we took this package we had made for this bank and we're like, well, I don't actually want to be an enterprise software company. And it's a long story, but a previous startup that I did accidentally turned into an enterprise software company. I did not enjoy it very much. What I want to do is build software for people that I can talk to that are more like me. So engineers and nowadays and maybe even at the time, but I was a little out of the loop.
Avery (06:42):
Nowadays this is considered a normal thing. I build a startup for engineers because engineers are going to buy stuff bottom up, but I never heard of any of this. I've been in Google for seven years and before that I built software in the pre SaaS days. So it turned out the path that we took is very standard, but I didn't know that. I'm just like, I don't want it to build enterprise software where we built this cool thing, why don't we see if we can make something that people can just install on their own and then play with at small companies like what our company is? And so we fine tuned it a little bit and slapped in our website and it was really not very good, but we wrote a blog post about it and for whatever reason, when I read blog posts, they frequently end up on Hacker News front page.
Avery (07:19):
This one ended up on the Hacker News front page and we got zillions of people coming to our website saying, Hey, this looks neat. And the problem is we didn't have a signup system or a registration system or a user activation system. We actually had all of the users in the system hardcoded in the source code of the server. And so the way you connected was you fill in your name and push this button and it puts you in the so-called waiting list. And the waiting list is a CSV file, which I would read every few minutes and then go through the emails and send them an email saying how to activate after I inserted their email address into our source code and activated their account. And I did that several hundred times in one night. So I was up for 24 hours straight just activating people.
Avery (07:57):
We had to build the signup system. Now I forgot what the question was. Oh yeah. And so that was the clue that maybe something cool was happening because the feedback we started getting, the nice thing about this method, I expected five people on the waiting list and then I could have a conversation with five people. Instead, I was having a conversation with hundreds of people that I had to email personally to tell 'em they've been activated and this is an amazing way to get feedback on your product because they know the CEO of this company, he's talking to them right now. And so we got tons of feedback on what the product could do and ideas for what the product should do, but also a lot of positive like, oh my God, this thing is amazing. I can't believe how great this is. You're already so much better than anything else I've seen in this category.
Amit(08:39):
Well, you sort of joked, and I know it's not entirely a joke that you didn't know what you were doing, but your intuitions have always been right. And I think one of the things the community has really appreciated about you and tail scale and all the folks who work there is you guys sort of try to do things the right way. You guys are very transparent, honest with customers in the community. I think people have responded to that. I also think you benefit from selling to developers and building for developers. Your intuition is probably better for that than for enterprise SaaS, but it's just easier and better to communicate with those people directly.
Avery (09:08):
Even that, I don't want to give it too much credit. My intuition is listen to people actually and then give them what they want. And I know a lot of people believe is, I think there's, what is the Ford saying if you just listen to customers, we would've built a faster horse or whatever it is. And it's like, look, people really like faster horses. But the trick is sometimes you can listen and the important thing is to understand the problem they're trying to
Amit(09:31):
Solve.
Avery (09:32):
And if you understand the problem you're trying to solve, then maybe you can come up with a more clever way to solve the problem. You don't have to implement it just like they said, but you have to give them the thing that they said they want. If they said they wanted to be able to connect to their banking software using two-factor authentication, you have to find a way to let them connect to their banking software using two-factor authentication. You can't just tell them no two-factor authentication is
Amit(09:52):
Not good, is the solution.
Avery (09:53):
And so when these people try to tail scale, they said like, wow, this is really amazing, but I wish it could do this and this and this. Then you can listen to them and actually give them what they want. And so I guess my addition to that, maybe the part that makes tail scale unusual come from the name tail scale, which was sort of the founding principle. We didn't know what we were going to build, but we knew how we were going to build it, which is everybody in the world makes everything too complicated now it's all based on this Google advanced super scaling stuff from the early two thousands back when computers were literally a thousand times slower than they are today. It is like I want to make a giant distributed system because it's cool to make giant distributed systems, but to do that, everything has to be hard. And so you get to the point where people are like, to launch my website, I created a Kubernetes cluster and then made it auto scaling and blah, blah, blah, blah, blah. And you know what? My website runs on the minimum cost line, node node using a little python script that I start by hand from the command line and whenever I want to change the Python script, I edit the one file that's the Python script and then I kill it and restart
Amit(10:54):
It.
Avery (10:55):
And that's Avery's website, which can handle as much load as anyone will ever throw at Avery's website. Not that good. But every now and then it gets a popular blog post
Avery (11:02):
And almost every project in the world is that scale of difficulty or maybe 10 times or a hundred times as hard as that, which is still not very hard. Google levels of difficulty is millions of requests per second that have to be served in a hundred milliseconds and they're searching the entire internet. To do that, you need a monster size system, but virtually guaranteed your problem is not that hard. And so tail scale is like, look, if you have a problem that hard, we're not going to try to fix it for you. If you have a problem that's easier than that, we can do it a totally different way and we'll just go straight to solving your problem and not just get lost in all of the complexity.
Amit(11:37):
I think it's an incredible insight and it's also just gives me PTSD, I started a series of very unsuccessful companies, but of course you build these companies thinking that millions of people are going to come and billions of requests are going to happen at the same time. And you sort of prematurely scale all these systems and to the point, there are a few very special and lucky companies that have to hit those scale metrics and numbers, but most everybody else is solving for something much smaller or different.
Avery (12:02):
I mean the biggest risk when you're small is that you're not going to build something useful. And so you need to build something useful as fast as you possibly can once it turns out to be useful, then first of all, it's easier to get funding, but secondly, you've got revenue coming in. You can pick the revenue, you can invest it in engineering, you can fix the stuff you didn't fix later. There's this principle that I learned a long time ago comes from the so-called extreme programming people that evolved into agile and it's called agony. You aren't going to need it. And the principle is if you're not sure you need it right now, just assume you're not going to need it because most of the time building that stuff is not going to be any harder later than it is right now, which means you should always push off that investment as long as you possibly can in case you don't need to spend it. And this is an amazingly useful principle. You can apply to almost everything and even if it's a little more expensive later than it's right now, you're going to have a lot more money later than you have right now. So you should always do the things you do need to do right now because an unlimited list of those anyway. So don't imagine things that you might need to do and then do them right now. You can
Amit(13:04):
Wait. I know we talked about this at the last company offsite, but I, I'm still amazed a how great it's been to work together, but we come from such different backgrounds and yet I think we actually did make the right choice and ended up working together. It's been awesome.
Avery (13:19):
Yeah, so I have to say one of the things I liked about Excel was they were an investor in net a long, long time ago. UU net was the link that my first job in Thunder Bay when we had this first internet service, that's how they got to the internet. And so I'm like, oh, these people have good taste in internet providers, or at least they did like 30 years ago, and probably you didn't have much to do with that. Thank
Amit(13:41):
God for Arthur.
Avery (13:42):
Yeah, but you're the sort of successor in a long line of people with good judgment is sort of what I was thinking.
Amit(13:49):
Yeah. Well, let's hope that that lineage has continued with tail scale. So we made the investment in July or August of 2020 and everything has been rosy ever since. Things have gone extremely well and nothing has ever gone wrong at the company.
Avery (14:06):
Yes, that's exactly right. It's actually very unusual. Nothing ever goes wrong. No, that's not true.
Amit(14:15):
It's obviously been a journey and there've been challenges. There's been obstacles the companies had to do a lot of growing up. What were one or two crucible moments for you as you think about critical junctures? Things that you got right, hard decisions that you to make that you look back on and you're like, you know what? In the fog of war, that felt like a really critical moment. But now on the other side of it, we made a really great decision. Maybe we made a really hard decision.
Avery (14:40):
My philosophy generally around doing a startup is make your mistakes as cheap as possible so that you can just recover quickly and don't go into denial about the truth about things. So most things that we've done wrong and there's been uncountable numbers of them have just not turned into some big spiral that anybody would point at and say, oh my God, biggest mistake of my life. We was like, Ooh, that didn't work. And then we turned it around in a month or a few weeks and it's gone. We've gone in directions with the tail scale product for example. We've put out features that have not really taken off, or even if they did take off, we realized they pulled in the kind of users who are not the most profitable users. And it's like, this is a great feature, but it's not the one that is going to move the business forward right now.
Avery (15:23):
An example is tail drop, which everybody loves tail drop once they hear about it. It's sort of airdrop on your Apple devices, but it doesn't require an Apple device and it doesn't require them to be side by side, but it lets you send a file between any device and any other device point to point encrypted without sending it up through a server and for free. It's like, well, that sounds great. That could be a whole product. It's like it could, but it's kind of consumery and we didn't need to go right now in the consumer redirection because we have all these engineers. And the way tail scale works is all these engineers, most of 'em have jobs, some of 'em bring it to work, some of the people who bring it to work end up using it at work and paying us,
Avery (15:59):
And that's great, and we're going to eventually invest more in the consumer redirection. But there's so much opportunity in this direction with just engineers that I'll say we should have instead put the energy into more engineering stuff. But it's not like we wasted a lot of energy. Tail drop was like a three month project for our 10 person team, and it created a whole bunch of buzz, and that whole bunch of buzz caused the word of mouth to go up. So was it a mistake? It's like there's probably something we could have done that would've been better. There
Amit(16:24):
Might've been a more efficient
Avery (16:25):
Path, but it was not a very expensive mistake. Our most expensive mistakes have been in the direction of we didn't really figure out marketing for a really long time. And it's funny to say that because when I say that to investors, and when I said it to investors and a series A and or series B, they're like, what are you talking about? You're so good at marketing. I'm like, you have no idea. Tail scale marketing.
Amit(16:45):
He's not kidding. We're not good at marketing.
Avery (16:47):
We might be now though. We are suddenly getting much better at marketing. And that completely relates to our new VP of marketing Sydney, who really gets it. But before that, all of our success was through word of mouth. Literally our website didn't matter. We did an AB test at one point and we just replaced the front page with a giant button that said Download tail scale. And that actually increased our signup rate because the only people who went to our website were the ones whose friends had been clubbing over the heads saying, you need to go download tail.
Avery (17:17):
So they would Google for the word tail scale, which is still the number one reason anyone shows up on our website. Somebody told 'em to Google for the word tail scale, then they click on tail scale and then they dig around trying to find the download button. And that's great. That means your word of mouth multiplier is really high. But that means we weren't doing marketing properly and the reason we weren't doing marketing properly had to do with how do you hire people? How do you find the right person who's really good at the stuff that you're not good at, right? Because I'm pretty good at hiring people to do the things that I am good at. Many engineers can spot another good engineer. So we hired a bunch of great engineers, but anything I'm not good at, how do I know? And even if they're good at it, maybe they're not the right person for your company.
Avery (18:00):
Marketing has a hundred different variations of how you should do it. Somebody who's really good at one of the variations, that variation might not be the right one for your company. And so eventually we've tried many different iterations, but to get to our current VP of marketing, for example, I had to interview dozens and dozens and dozens of people and find out how they did it and ask for people's advice and ask for their advice. And what do you think about this? Until I finally found somebody who explained it to, explained to me how my company should work.
Amit(18:27):
Avery, what's been surprising when you build a really powerful tool? I mean, of course there are obvious ways to use it. What have been some surprising use cases that have emerged as tail scale has become more and more popular?
Avery (18:38):
People use tail scale for really unexpected use cases. One of the most recent ones, as we were grinding through our data about who's using tail scale, we found that five of the five top or AI companies were using tail scale. And then we found that hundreds of not the top five AI companies were also using tail scale. And we're like, oh, why? I don't know any of these people. They all just signed up through self-serve and never contacted us. So we had to dig around and find out, okay, what about tail scale makes us popular with AI companies? And the answer is basically they're all stuck with multi-cloud. They all have to deal with some GPUs. They're probably all using Kubernetes, and they all have all of these. They have connectivity problems, but they don't want to invest in a networking team. There are a bunch of really smart engineers who are AI engineers and networking is just getting in their way and they just want to spend some money to make networking problems go away.
Avery (19:32):
And they had all heard of us because they're early adopters and they're all mostly living in San Francisco. And everybody in San Francisco now knows about tail scale. And so just AI companies just across the board started adopting tail scale for everything. This is, again, it's great. It was a surprise, but if we'd been on top of our game, we would've seen that coming and maybe put some work into it. At the time, you could search for AI tail scale and not find anything on our website. There was not a single mention of the word AI anywhere or machine learning or LLM or GPU. There was nothing. Our website was not serving it at all. Other people were telling other people, oh, you work at in ai, you should do this. And they go to an AI conference and people were like, oh, how do I connect to my GPU?
Avery (20:13):
It sucks. And like, oh, I have tail scale. You should try it. It's free trial. And just took off. More recently, we found out retroactively that tail scale is a service mesh. And I'm like, I don't even know what a service mesh is, but I'm talking to customers and we have customers who are like, oh, well, we threw out our old service mesh and now we're using tail scale as a service mesh towards tail scales as a service mesh. And I'm like, I am going to have to go Google some stuff. Let me come back. And so now I know what a service mesh is. A service mesh is a combination of connectivity, identity and service discovery and scale obviously does productivity and identity, which is the thing that it does. I never thought of it as a service discovery system, but it turns out the architecture of tail scale is that it keeps a list of all the devices in your network.
Avery (20:58):
It had to generate encryption keys and track them and distribute them. And then it tells each node about each other node, and then each node has a list of nodes and you can query it and say, who's the list of nodes that match this criteria? And that turns out to be a service discovery mechanism. And some of our customers realized that we did these three things and are out with the old service match thing and put in tail scale. And again, it's like there's not a single mention of the word service mesh anywhere on the tail scale website. Actually, that might still be true today. People are actively working on it. They're going to be launching web pages that say service mesh sometime soon. That's awesome. But it's like these kinds of things where it's like you just have to, at this point, we have to keep our eyes out for what people are already doing and then listen to them and then tell the story back and improve the experience that they're having.
Amit(21:39):
It wouldn't be a tail scale podcast if I didn't at least give you the layup of telling you about crossing the chasm. And I think this AI pervasiveness allowed you to keep resurrecting crossing the chasm in board meetings for at least another two years. So could you maybe just talk about that, because I know it's one of your guiding principles as you think about the company and in particular for the motion that you have of getting ubiquity within developers. Can you just tell us the audience about that and then how that's guided some of your decision making?
Avery (22:10):
I guess the history of this, I was introduced to the book Crossing the Chasm by one of my investors at my very first startup toward the end of the cycle of that startup. When we were struggling, we had growing revenues, but it was really hard to grow the revenues. And in retrospect, what happened was we were stuck with basically early adopter customers, and there were lots of early adopter customers and we were pushing really hard. We had a sales team searching as hard as they could to find early adopter customers, but every single thing was just push, push, push, push. And they're like, well, Avery, you should read this book. It kind of explains what's happening. I'm like, ah, how can a book explain what's happening? We have a unique situation. Nobody's ever done this before, blah, blah, blah. I read the book and the format of the book, every chapter is like, here's what people usually think you should do.
Avery (22:57):
Here's what happens when you do that, and here's what you should do instead. And so I opened up chapter one. It's like, oh, that's what I did. Oh, that is what happened. Oh, that's what I should have done instead. And then you go to the next chapter and the same and the same, and it's like the story of our entire startup from beginning to where we were and a recipe for what to do to fix it. And so I decided to follow the recipe and then within six months, the business turned around. But by then it was too late. We'd been doing it for eight years. We were running out of money. Investor didn't want to put in more money. The first investors were getting inpatient. And so we exited IBM. But if I hadn't had that same exact advice four or five years sooner, it could have been a completely, completely different company because we had the product that we needed. We didn't know how to cross this chasm.
Amit(23:43):
And
Avery (23:43):
The secret of crossing the chasm is just to figure out how to become the default product that everybody uses for some use case. And the thing that nobody realizes, the super counterintuitive part is that use case, that group of people has to be tiny because you're not going to win. You're not going to be the default solution that's more than 50% is how you be the winning default solution.
Avery (24:05):
You're not going to be bigger than 50% of anything big when you're tiny. So everybody wants to go after this thing with a giant total addressable market. They want to find some market that's humongous and tell their investors, don't worry, there's 10 billion of possibility here, a trillion dollars. It's like that's not how you succeed when you're tiny, the way you succeed is you find something really small and you win that really small thing by telling everybody, look, nope. Maybe you don't have to say this out loud to the customer, but this is too tiny for anybody to care about, but I care because I'm also tiny. So we're going to give you the best possible service and go out of our way to make the best possible thing. And then when you win that, then you can win something adjacent and something adjacent to that and something adjacent to that, and it just gets bigger and bigger and bigger. So the secret strategy of tail scale, and again, it feeds into the name, we accept the idea of doing small things.
Avery (24:56):
And so tail scale is always going after what is the small thing that we can do next that we're going to win easily. And AI was one of the things where, okay, we actually were kind of late. We already won it before we noticed that we had won it. AI networking I should say. And then the service mesh thing again is like, oh, we're not winning. But it's actually, I looked it up the other day. The service mesh market is not that big in terms of dollars right now. It's actually achievable to make it a splash in the service mesh market. And so we'll keep doing things like that and growing and growing incrementally. But it is such a good book. It explains why this works in a, I'm a systems design kind of person, but it explains it in a systems design sort of way. This is why systems like this always happen. And when you do the obvious thing, this is why it always doesn't work.
Amit(25:45):
Avery, how do you think about monetizing or charging for what you've built at tail scale? You started off with this amazing community, it's very bottoms up. You have individual developers. You talked about this motion of developers at home using it and then bringing it to work. How do you think about charging and kind of growing up into a business over time?
Avery (26:05):
Sure. So I said earlier that I didn't want to build an enterprise software company, which is true, but maybe I should qualify that because obviously our first customer was a bank tail scale is suitable for enterprise, but I want to make the internet a better place. And if you're going to fix the internet, if you're going to fix this low level protocol of T ccp IP and get it out to everybody, then it has to be literally everybody includes enterprises, but it includes everybody else. And so tail scale, my other favorite business book is called the Innovator's Dilemma. And if I was to summarize it in one line, it's like nobody ever goes down market. They only ever go up market. And so if you start up market, you're never going to go back down. So tail scale, our policy is like we are going to make sure that the $0 part of the market is ours, and we're going to do that by a giving away the product to people who want to use it for free, and B, making sure that it's cost effective to give away the product, to have people for free.
Avery (26:58):
Because what I can't have is just I'm going to raise a bunch of money from investors and then spend all that money giving away AWS credits or something like that so that people can have the product for free. So I have this blog post called How Tail Scale remains Free, and it explains the architecture of tail scale and why it doesn't cost us anything for you to have your free account. And if it doesn't cost us anything for you to have your free account, we can keep giving it out to lots of people. And in fact, in the early days of tail scale, because I talked about how in the very early days we didn't even have a signup system that was not Avery sending you an email, but later we're like, okay, well we have lots of work to do. Why should we implement restrictions on what customers can do?
Avery (27:34):
So there was no actual limits if you bought a 10 user account or if you didn't buy anything, there was nothing stopping you from signing up another a hundred or few hundred users. And that's what we actually got. And so when we hired our first few salespeople, the first few salespeople job was just like, Hey, we've got some customers with hundreds of seats. They never actually emailed us. We should probably tell them that they're actually supposed to pay for the product. And if you dug around, if you actually went to the billing page, it would tell you whether you were over your subscription, but it was very Canadian. It said like, Hey, it was great that you're trying this thing. Probably you should pay us sometime. I can't remember the exact wording, but it was kind of like that.
Amit(28:12):
I was told the people at Excel that you are, the company is Capital C Canadian and lower C Capitalists. It's stories like that.
Avery (28:21):
But as a Canadian, I want to point out that despite all of that, the amount of revenue that we could capture by going out and collecting all the money from people who were underpaying us was only about 20% extra. That means 80% of the people in the world were paying us, even though there was absolutely positively nothing making them do that. Most people in the world are honest, and that is a fundamental belief of Canadians of course. But also that extra 20%, I could afford to have that 20% for the huge amount of word of mouth that it produced. But anyway, so as tail scale has been getting bigger, we have a more structured sales team. Now, I actually got complaints from various people that I knew when they signed up for tail scale and started using it. They're like, Avery, you're doing something wrong.
Avery (29:02):
I'm not going to pay you until somebody reaches out to me and tells me to pay. My own friends are telling me this. It's like, Avery, fix your company. It doesn't make sense. Nobody's going to be mad because they've got 50 seats that they're really enjoying. And somebody emails 'em saying like, oh, we should have a discussion about dollars now. And so we started doing that. We have a real professional sales team. We still don't actually enforce too many limits, but the sales team will catch you sooner and invite a conversation. And so we've been getting bigger and bigger now, and we're starting to actually do our first million dollar plus deals. And so when I said I don't want to do enterprise sales, it's like somebody now we have employees, there are people who are going to do the enterprise sales, but I have to remember where we came from and where we came from as individual engineers who love the product, they use it at home, they bring it to work, they use it in small teams, and eventually it turns into a system where people buy it top down and roll it out to the whole company. And so that's where tail scale, the whole vision of the new internet, it can scale all the way down from zero to maximum, and that's how you get the new T-C-B-I-P rolled out to everybody.
Amit(30:06):
You talked about transferring files between devices. You talked about two-factor authentication. You talked about VPNs, you talked about connecting devices, and now you're talking about service mesh and you're talking about, Hey, AI networking. How do you think about defining the vision for the company? I mean, when you stand up at an all hands in front of the whole company, how do you describe to them what the future looks like and what does that mean to you in terms of the mission of the business and what the implications are on the world that we're headed towards?
Avery (30:36):
Well, kind of workshopping this one the way we have been saying it.
Amit(30:41):
We'll do it live.
Avery (30:42):
Let's go. Okay.
Amit(30:43):
Okay. Yeah.
Avery (30:44):
So what we say is tail skill is the new internet. And I like it because it's funny because there's a TV show, Silicon Valley, where the main characters made this thing that was called the new internet. It was just like a series of laughs, but actually the internet needs to be fixed. And what I mean by that is as an engineer, T-C-P-I-P is the problem, and we've known this since the 1990s. IPV four is not good enough. They tried to launch IPV six. IPV six should have solved a whole bunch of our networking problems. Have your networking problems been solved by IPV six? No. Right, and why not? Large part of it is the thing has not fully rolled out. And why didn't the thing fully roll out? It didn't roll out because it didn't follow crossing the chasm. They didn't have a rollout plan that was going to win, and it still hasn't won and it doesn't look like it's going to win.
Avery (31:30):
If you look at the trend line, it looks like maybe in the next 40 or 50 years, maybe they'll get to 80 or 90% adoption. It's like, I might be dead by then, right? I've been waiting for IPV six my entire life and it's not solving the problem. IPV six was the chosen one. It didn't work out. The new internet didn't happen. It was the new internet. So what are you going to do about it? Tail scale is actually, and again, it was kind of by accident. I just wanted to fix some problems. Tail scale is this thing you insert at the IP layer that makes the internet work the way the internet was supposed to work. And when the internet works the way it was supposed to work, any device can talk to any device. You've got safety, you've got security, you've got encryption, you've got identity, you've got easy to set up.
Avery (32:11):
You don't think about it anymore. It just works properly. And when things work properly, one of the things that's hard to explain about the vision is when people were inventing T-C-P-I-P, they didn't really think that big. They were like, you know what? I want to be able to access the supercomputer at my university from another university is like, that sounds neat, but it doesn't sound like the internet we have today. The internet we have today is used for everything all the time. I have internet on my watch. If I bought a watch and it didn't have internet, I'd be like, why am I paying for this? It is broken, right? Nobody thought about that.
Amit(32:44):
We used to call them smart watches. Now we just call them watches.
Avery (32:47):
Exactly. Or smart phones. When was the last time you phoned somebody on your phone?
Avery (32:53):
So what is the vision for tail scale? The vision for tail scale fundamentally on an engineering level is like, look, we just need to fix the thing that we call the internet and replace it with this new thing. And the layers on top can be actually the same, but a whole bunch of stuff is going to work better. And then how do you explain what's the business value of that? What are people going to do with it? It's like it's a little hard to explain because most of the uses for tail scale haven't been imagined yet. And I think the only way I can explain that is through that analogy. And so even though it's a joke, the new internet analogy is actually the right analogy. The internet is no longer living up to the expectations that we had of it in the 1990s because IPV six didn't work. And even if IPV six did roll out, now it's been 25 years since it was designed, it's missing some stuff that we would've put into it if we designed it today. But it's just been stuck. And if you unstuck something that's 25 years old in the tech world, you're going to get a whole bunch of benefits.
Amit(33:49):
So that was incredible, by the way. That was pretty good. Pretty good for a workshop. If you could go back and give any feedback or advice or wisdom to Avery outside of Reed crossing the chasm four years earlier, what would you tell 'em?
Avery (34:05):
I think tail scale. We did a really good job building the company through the first several phases. I think what we didn't do a fantastic job of is as we're switching from what I would call a early stage startup to a growth stage startup, you really have to restructure the way the company works to make it more scalable. And that means building an executive team in the right structure so that you can help people get their work done when not everybody is going to be able to know what everybody else is doing all the time. And so I didn't do a super great job of creating the structure inside the company that I probably shouldn't. The organization of the executive team is really important. You don't need to be super innovative. Again, you're not the first person to build a company. And so there's lots of advice you can find on like, okay, what's the good structure of an executive team?
Avery (34:56):
How do you choose what roles should go here? There's only a few structures that reliably work, and so you don't want to innovate on everything in your company. It's great to be innovative on the technology side, but you don't need to invent everything. You don't need to invent your own accounting systems, finance systems and so on. The most important thing for me when building an executive team that I learned is actually executive search companies are amazing and they're worth their weight in gold much more than I realized because the main thing they do is they introduce you to lots and lots of great candidates, some of whom you won't even be able to land, some of whom you don't even want to land. But you get such a wide array of information about what's possible in a particular role that after you've talked to 25 or 30 of these people, then you can understand what perfect looks like for you.
Avery (35:41):
And when you're a tiny little company and you're only hiring one executive, it doesn't matter if there's not a hundred different people who can fit that exact role that you've invented. If there's just one person who can do that exact combination of things that you want, you can just find that one person and that one person is really going to want to work there because it's the job that's absolutely perfect for them. And we've found that kind of executives. But I didn't realize before that it was possible to do that. I didn't connect to the fact, ironically, given the tail scale is all about small things, I didn't really connect to the fact that you only need one perfect person for this job and that person is there somewhere and you can just go find them. But it's going to be a lot of work, and an executive search firm will help do
Amit(36:19):
That. That's awesome. Yeah, I think you've done a really good job in those situations. One thing I've grown to really appreciate about you is you definitely take time to get all the data, but once you have the data, I really trust your decision making and it's worked out pretty well for us.
Avery (36:34):
My comment on data is I love data, but in fact, most of the most useful data in my life turns out to be panic data or building an intuition for something. So maybe I'll stare at the data for a long time and it's like, okay, I think I understand what the pattern is now, and then close down the dashboard. And with the idea about the pattern,
Amit(36:51):
You
Avery (36:51):
Talk to people, you get advice. What's the pattern of advice? What's the standard way to do things? Are we really special enough to be breaking this pattern or should we just do the standard way to do things and then just look, there's a little bit of just following your intuition, but to make your intuition smart enough requires a lot of studying, which is how I do it.
Amit(37:09):
That's awesome. Avery. Thanks for joining us. You're a great dude.
