Welcome to the first in our series on The New Stack Makers about technical founders, those engineers who have moved from engineering jobs to running a company of their own. What we want to know is what that's like for the founder. How is it to be an engineer turned entrepreneur? We interviewed Cycle.io Founder Jake Warner for the first episode in the series about how he went from downloading a virus on an inherited Windows 95 machine as a 10-year-old to leading a startup.
Welcome to the first in our series on The New Stack Makers about technical founders, those engineers who have moved from engineering jobs to running a company of their own. What we want to know is what that's like for the founder. How is it to be an engineer turned entrepreneur?
We like to ask technologists about their first computer or when they started programming. We always find a connection to what the engineer does today. It's these kinds of questions you will hear us ask in the series to get more insight into everything that happens when the engineer is responsible for the entire organization. We've listened to feedback about what people want from this series. Here are a few of the replies we received to my tweet asking for feedback about the new series.
If they have kids, how much work is taken on by their SO? Lots of technical founders are only able to do what they do because their partner is lifting a lot in the background — they hardly ever get the credits tho
— Anaïs Urlichs ☀️ (@urlichsanais) August 4, 2022
I host the first four interviews. The New Stack's Colleen Coll and Heather Joslyn will co-host the following shows we run in the series.
We interviewed Cycle.io Founder Jake Warner for the first episode in the series about how he went from downloading a virus on an inherited Windows 95 machine as a 10-year-old to leading a startup.
"You know, I had to apologize to my Dad for needing to do a full reinstall on the family computer," Warner said. "But it was the fact that someone through just the use of a file could cause that much damage that started making me wonder, wow, there's a lot more to this than I thought."
Warner was never much of a gamer. He preferred the chat rooms and conversation more so than playing Starcraft, the game he liked to talk about more than play. Warner met people in those chat rooms who preferred to talk about the game instead of playing it. He became friends with a group that liked playing games over the network hosted by Starcraft. Games that kids play all the time. They were learning about firewalls to attack each other virtually, between chat rooms, for example.
"And because of that, that got me interested in all kinds of firewalls and security things, which led to getting into programming," Warner said. "And so it was, I guess, the point the to get back to your question, it started with a game, but very quickly went from a lot more than that.
And now Warner is leading Cycle, which he and his colleagues have built from the ground up. For a long time, they marketed Cycle as a container orchestrator. Now they call Cycle a platform for building platforms – ironically similar to the story of a kid playing a game in a game.
Warner has been leading a company that he described as a container orchestrator for some time. There is one orchestrator that enterprise engineers know well. And that's Kubernetes. Warner and his team realized that Cycle is different than a container orchestrator. So how to change the message?
Knowing what to do is the challenge of any founder. And that's a big aspect of what we will explore in our series on technical founders. We hope you enjoy the interviews. Please provide feedback and your questions. They are always invaluable and serve as a way to draw thoughtful perspectives from the founders we interview.
Alex Williams 0:00
Hey everyone, Alex here. Hey, listen, we have a new series starting on the new stack. Baker's is called the tech founder Odyssey. It's about technical founders. So as people who are engineers who are starting their own companies, we've had the best feedback from people already on Twitter. The questions are awesome. And it's really going to be guiding us. As we develop this series. We want to know about these people why they got started, what motivated them? What were the lessons that they learned along the way? What is it that they've learned about themselves, about their backgrounds, about the people who they've hired to work with them? How have they grown this venture into something that will last it's a big deal for these people. And I think it's a big deal for a lot of us who thought about doing these kinds of things, and are part of the companies that these engineers have started, we hope you enjoy it. Again, it's the tech founder Odyssey on the new stack bankers.
Alex Williams 0:59
You're listening to the new stack makers, a podcast made for people who develop, deploy and manage at scale software. For more conversations and articles, go to the new stack dot I O. All right now on with the show.
Alex Williams 1:24
Okay, here today with Jake Warner, founder of cycle. First in our founders series, we're going to interview founders who have a technical background. And seeing that we're talking about technical backgrounds. Jake. I interviewed somebody once, who was a technical founder, and they got their first computer out of a dumpster. i You're going to be the second person that I interview who got their first computer out of a dumpster?
Jake Warner 2:03
No, no. The first computer I got, let's see, it was 1999. My grandfather, he had a Windows 95 machine. And he was upgrading to Windows 98 machine. And so I inherited his windows 95 machine. And so that's where it all started.
Alex Williams 2:20
So you started on Windows, what did you start programming? And did you start programming after us found all the games on the computer or tell me about that story about getting that Windows 95 machine.
Jake Warner 2:34
So when I received that first machine, computers that always kind of interested me at that point. But that was really my kind of first experience into them. Any video games I had played at that time were on, I think it was like the Nintendo 64 or something at that time, right. So I wasn't really ever too much of a gamer. But it was around, I'd say probably 2001 2002, where I was introduced to a video game called Starcraft. And that was the first game that I started playing where, to me, it was actually less of the game. And more of the fact that I had chat rooms, like you know, there's a lot of people their first introduction to chat rooms were AOL and things like that, for me, it was StarCraft, I log into the game, not to play the game, but to chat with people. And throughout that process of being in those chat rooms and talking to people, there was one time where, let's see, that was 2001 2002, I would have been 1011 at the time. So this was Windows XP at the time, and someone had sent me you know, a file, and I had opened it like I wasn't security conscious at the time. And you know, ended up being a virus. You know, I had to apologize to my dad for needing to do a full reinstall on the the Family Computer. But it was the fact that someone through just the use of a file could cause that much damage that started making me like wonder like, wow, there's a lot more to this than I thought. And it's kind of a weird introduction. But that was the initial start of it. One of the things that came of that was, within this game, you used a network called Battlenet by Blizzard right, as a way of communicating. But there was groups of people on Battlenet, who would do the same thing as me, they'd be logging in, but not to play the game. But they would be it was almost groups of developers and engineers, things like that, that would figure out how to attack each other. Right? So it's almost like like, we logged into a game to play a different game. So because of that, that got me interested in all the kinds of firewalls and security things which led to getting into programming and so to get back to your question, it started with a game but very quickly went from a lot more than that.
Alex Williams 4:52
Gosh, you know, that's a different take. It's like going to play basketball or this Gate Park and just chillin with your friends. Really? It was same kind of thing. Yeah,
Jake Warner 5:04
it was different. It's kind of weird because a lot of the people that I met back then, you know, my family had a I mean, I was again 10 or 11. Right? My parents had a rule that I couldn't tell anyone how old I was, right? So, you know, for years, I was just hanging out with all these people, no one had any idea how old I was. And now fast forward to now, what 2021 years later, and I'm still friends with a lot of those people didn't really know how old I am. And you know, they're eight, nine years older than I am. But it's interesting, because so many of them are still doing like really technical things now, and we all kind of had that seem weird beginning of you know, just being in these chat rooms trying to attack people in the chat rooms. Of course, you know, me being a 10 year life, it was never like any necessarily. We were doing it for fun. We weren't doing it for reasons of trying to cause damage. It was a game between us, it was interesting.
Alex Williams 5:56
How's it influenced you today, you're now the founder of cycle. Tell us a little bit about cycle and tell us about what you learned since then that led you to where you are.
Jake Warner 6:05
So cycle is a we used to refer to it as a container orchestration platform recently, thanks to a number of conversations with people in the space, including people like Darren Shepherd, many people watching this podcast probably are familiar with from rancher. But we used to call cycle a container orchestration platform into we've had a number of these people come back and say like cycle, there's so much more like you manage infrastructure, there's load balancing built into it, there's all these things beyond just containers. If you call cycle a container orchestration platform, you're diluting some of the real value that's that cycle can provide, right. So now we have started to transition into calling cycle, a low ops platform for building platforms. It's new messaging that we're experimenting with, and I can break it down a little. So the last part obviously, is you shouldn't need to be like a super talented DevOps engineer, with all this experience of different cloud infrastructures and deployment paradigms and things like that, to build the unicycle. Whether you are an experienced DevOps engineer, or whether you're a developer that might be deploying a server for the first time cycle should be able to fit what you're needing to do for both. But the second part of that, where we say, platform for building platforms is something that we've really started to stumble on recently, most of the products and services and things like that being built on top of cycle these days, our platforms, and when I say a platform, I'm not necessarily saying like, Oh, it's another container platform, or a DevOps platform, it can be like a fin tech platform or a real estate platform. But the word platform is kind of a generic word these days within the industry. But the word platform kind of implies a certain level of sophistication to it, right. And so when we say platform for building platforms, we're talking about companies that are building the services and products that have many moving pieces, there's front ends, back end API's, there's a whole bunch of different components that make up those offerings. And we found that that's really where cycle shines. So that's what cycle is, it's a platform for building platforms. The idea is that you upload any OCI container, whether it was built with Docker, or any of the other containers technologies. As you upload those containers, you can choose what servers you want to run them on. So you can choose which provider if you want bare metal, if you want virtual machines. The idea is that cycles giving users the convenience of a pass, but on their own infrastructure focused around containers. So we're still trying to figure out the fully proper definition there.
Alex Williams 8:28
This leads me to some questions, because I think one thing we're trying to get to in this series is what is it like to be a founder? And what are kind of these experiences that you go through? And how does it affect how you change your vision, I can speak from the founder myself, because I'm a founder of a tech media company. And what you talk about kind of relates back to things that I can recall in our earlier days where we were talking about, well, what part of the stack do we really want to cover? Right? Do you want to cover the front end, we want to cover the back end. So we focus on the back end architectures, because that was just a much more of kind of finite place where we could focus and it related to Container architectures, there was just lots more there that we felt comfortable with and covering as well. The whole front end space is pretty vast, right? And so we're now moving into that space where we're focusing more on front end to some extent, but it relates to the back end through the full stack. So you had this idea initially, as container orchestration platform, what did you learn as you kind of started building it out? And then deciding to change your messaging? And how did it affect your perspectives? How did it affect the work that your engineering team did? How did it affect kind of your relationship with other people on the team? Because these are all the things that founders go through. They had to think about all those different parties.
Jake Warner 9:57
There's a number of different ways to I'm sure that I think the biggest thing that makes me who I am, as a technical founder is I like to place long term bets. I don't want to generalize too much. But I think that we've through the ways that VCs have funded startups these days, we've kind of been forced into a model, where it's get something out the door as fast as you can. And even if there's not a ton of innovation in it, when everything you see is in terms of revenue, and you know, getting users on board and things like that, you end up in many cases, not really being too innovative, right? And then I'm generalizing a little there. But what cycle one of the things that we tried to do is we figured, okay, if we're going to spend the time building cycle, we want to make sure that we have the actual ability to innovate, right. And so this is where we went back. And as we were looking at Docker, and Kubernetes, and some of these other companies in the space, we were like, alright, if we want to build something innovative, we need to do it, where we are building it from the ground up ourselves, right? Because there's so much engineering that happens these days, where people are kind of puzzle piecing things together. But I think there's a certain point where if you keep puzzle piecing things together, that you end up with a product or service, that is you just end up with too much complexity within those different layers, right? And so a cycle, we've made the decision, okay, if if we want to innovate, we have to build it from the ground up. And we're going to spend more time doing it right, and be opinionated about what we're doing. Right? There's, I think, a lot of projects these days, where organizations and developers try to solve every single use case. And within taking that approach, you end up I don't know, it's the whole cliche of if you try to sell to everyone, you're selling to no one, right? Yeah. And so it was like, we were like, Okay, we want to be opinionated enough that we're making people's lives easier, but also opinionated enough in our own development, that we can innovate quickly, I guess, is really what it all comes down to, but innovate quickly, in a way that we are not just piecing different puzzle pieces and things like that together. So from a founder perspective, getting to the question that you had asked, this is kind of going full circle. Now, if we go back to the conversations about the chat rooms on Battlenet, so I was probably 13 or 14 at the time. And there was a guy named Alex, he went by the username of shadow, right? This was back when like, people were just really starting to get into MySQL, and building like PHP applications and things, right. This developer, Alex, who had met in the showroom, he was building a CMS, but using a flat file system to do it. So it had no database. Technically, it was still a database, but it wasn't like MySQL, or anything. It was literally just writing text files and things for user accounts and, and things like that. And it sounds weird to talk about that now as being something super exciting. But back as a 1314 year old, that was learning kind of figuring out what path I wanted to take as a developer, it was really interesting to have someone to step out and say, Well, I'm going to just do this own way. And question Why did matter why he just wanted to do new things. Right. And I think that it was kind of right around that moment that I started to experiment with, like, okay, maybe there is value in trying new ways to do things. I mean, sure, sometimes those will fail. But it was I think, at that time, that was a pretty big influence on on who I became as developer, because I had an extreme amount of respect for the sky, because he was just building really complex things on his own. And, you know, just some part of me wanted to be that as well. Hmm. Actually, coincidentally, last year, he found me on LinkedIn. For the first time, like 15 years, we we've since had conversations, but it's just
Alex Williams 13:42
funny. Yeah. So one thing again, going back to my own experiences, as a founder is like, you are what you do, really, we focus on explanation analysis at scale development, deployment and management for software engineers and developers pretty basic. And then we try to live up to that in our stories and the work that we do. And when I think of what you do, we've had a few conversations, I can get that complexity that you're talking about, because what you've built is no DevOps really, really trying to minimize the DevOps roles. Yeah, there's no Kubernetes involved. Really, it's all it's all bare metal,
Jake Warner 14:23
right? Yeah. So it's like it was built with the idea of running on mainly bare metal today, you can also extend cycle to virtual machines. And but yeah, it was that approach, like most of my life, before building cycle was in bare metal. And so I think it was kind of that natural kind of stepping stone for me. And to the point that you just made it the general idea was, how can we eliminate a lot of the DevOps needs, but use just any commodity infrastructure to do it, right. Like you shouldn't have to be on a specific cloud provider that has features a, b and c to be able to use cycle. So it was very simple like as long as you have a server that's connected the internet should be all you need. Alright,
Alex Williams 15:00
So you've built a TCP protocol as well. Yes, actually, yeah. So you didn't put the pieces together, like you say, a lot of startups you see doing, which it makes it a little bit more complex. I think for them, you're saying to develop because now you're building and all these layers. So these puzzle pieces fit together? Who do you look for then, in terms of people to work with? And I'm thinking of it in terms of the engineering term first, but then I'd like to get into the how a technical founder thinks about positioning and pricing. But maybe you could talk to me about who you started looking for, for engineers, and who is able to grasp these kinds of concepts? Yeah.
Jake Warner 15:40
So the general idea was that if we build everything within cycle the same way, using the same stack using the custom TCP protocol that we had built, the the general idea was that everything could have native communication between each other because one of the common issues that you have when you're building those puzzle pieces is you have that translation layer that has to happen, right? If you're going from one service to another service, at some point, you have to translate between those two things. And there's complexity that can happen in that process. Or there's, there's bugs, because I suppose one of those puzzle pieces needs replaced later, how many things is that going to break, maybe a call that we're using got deprecated. So what engineers, the way that we built this stack of having all the cycle services built the exact same way, using the exact same languages all built on house, it's really nice, because as we go out and look for developers, at least for our back end, and our middle stack, we really just need good goaling developers, right? Because everything is built in goaling. And all of the TCP protocol that we implemented was on top of regular network calls and things like that. It allows us to have that extreme flexibility in terms of we don't have much legacy code, we don't have to deprecate much. It allows us to just keep moving really quickly. But at the same time, instead of having to go out and find engineers, that it's like, okay, we need you to know this technology, this technology, this technology, you have to learn Prometheus and all these Kubernetes things, or all these just weird different technologies, G RPC, and all this stuff is really nice to be able to say, hey, we need people who are really good Googling, and have like good foundational knowledge of networking and infrastructure. Well, it required more time to build, it allows us to move a lot faster. I've heard this quote as Miss attributed, but I'm not 100% sure if that. But it was told to me one time, it was an Abraham Lincoln quote, and it was, if I have eight hours to cut down a tree, I spend seven hours sharpening my axe, right. And that was the cycle approach will really define and get opinionated about our approach so that we can keep moving really fast as time goes on. And that allows, that's the same thing with the engineers that we're able to bring on board. Once they understand those fundamentals of how we built everything, they can just start running in terms of getting up to speed very quickly.
Alex Williams 17:51
So when you change the messaging from like going from container orchestration to P a platform of platforms, what do you say to your engineering team does it really matter to them at all, really, at that point, you're just thinking about the positioning of the company. And you can then talk about that with other people on your team
Jake Warner 18:09
was changing our messaging, it really hasn't changed much of our development roadmap, or our timeline or processes around that. Most of it has been around the fact that we've gotten into a number of really good conversations recently, with companies that have said, Oh, I've tried Heroku or or I've tried some other platform as a service. But the problem that I had with those, the onramp was really easy, it was very easy to get started. But the problem that I keep encountering with these paths offerings is that they have a low ceiling, that there's a certain point where I where I'm almost forced to go find a new way of hosting and running my application. And so throughout these conversations with with customers, that was hey, it was cycle, I really liked that ceiling is much higher, I can choose the provider I want to use, I can choose the infrastructure I want. If I want to have a small virtual machine, great. If I want to run a rack of bare metal servers, I can do that as well. With being the platform for building platforms, our goal is to be opinionated enough to make it easy, but still flexible enough that that ceiling is still sky high. So by changing the messaging, the saying, you know, the little ops platform for building platforms, we've actually had a significant uptick in conversions recently from from marketing funnels. I think the message is resonating, because it immediately shows people who are looking for that sort of offering that we lined with them right like that, you know, if you're if you're trying to build something of substance, the cycle is a great place for you to build that. So the tagline is low ops. Yeah, the low ops platform for building platforms,
Alex Williams 19:41
when you're a technical founder, right is different than myself who I'm a journalist, right. I have a different expertise that comes into it. You bring in your technical expertise. I mean, as a first time founder, I had to learn how to manage people and I had to learn, you know a lot about how to like think about pricing and Things like product fit. And like I think you're talking about with like kind of changing your marketing message a little bit. How have you approached things like learning pricing and, you know, in talking to customers and things that when you're younger, you're not really thinking about because you're spending a lot of time just learning to code.
Jake Warner 20:20
It's difficult. I think one of the hardest things about being a founder is you can be a good developer. But that doesn't mean that you're good at pricing strategy, right? You can be you know, a good developer and not good at marketing or things like that. There's so many more people in the world that are so much more articulate than I am, I always seem to have an issue of expressing things in a very clean way. But in terms of pricing strategy, I think it's just one of those things that like, you just have to be open to constantly trying new things until you start finding something that works. We've recently actually changed our pricing model, we released it two weeks ago, something like that. The previous model worked well for the company. And it worked well, because it was a model that scaled with usage directly. Right. But the problem with the previous model is that there's two things. Number one, it was hard to explain. And number two, it almost discouraged people from scaling. Right. And our entire concept is the platform for building platforms, we definitely shouldn't be discouraging people from growing in terms of pricing. We were noodling on it for a month or so like, how can we simplify this pricing model, still do what we need to do still, you know, obviously, cover costs, but position things in a way that is much more friendly towards potential customers. And I wish we had made this change earlier. But again, to your point, everyone has different strengths and weaknesses. So I think in terms of pricing strategy, and things like that, you just have to get it out there, test it, see if it works. And if it doesn't, you know, try a different approach until you find something that works really well.
Alex Williams 21:59
That's pretty cool. So you're mostly on bare metal. It's interesting, you talk about Prometheus and G RPC and things like that. Those sound like puzzle pieces to me. I guess just my final question for you is, how do you like it? How do you like being a founder? Like what would you say to people who are starting this journey themselves? Let's start with that. And then maybe the next question is, what would you ask the people who've been in technical founders before? Or more experienced than you?
Jake Warner 22:31
To the first question? How do I like it, I would say like, you're probably 80% of the time, I've been at this for about six, six and a half years now. The pros are that, you know, you can, you can really set out on on solving some some big problems, and I love solving problems. The con is that the stress never ends. And you know, sometimes the stress, it's something that a lot of, I think a lot of founders don't want to publicly talk about stress, just because like it's a sign of weakness, or whatever it is. I think that's part of it. And then the other part is, I've, I've lost a number of good friends over the years, you know, just as the company grows, the needs of the company change. I'm sure it's something that you know, that you've gone through as well that, you know, there was people that were your great people, but they just didn't make sense for the company anymore, or whatever the reason was, and it always is always unfortunate to lose friends. Because of things like that. No one, no one likes being fired. Right? No one likes having to have difficult conversations when something's not going well. That's the most difficult part. But obviously, you know, seven years, six and a half, seven years in and I'm still doing it, I still enjoy most of it. Right?
Alex Williams 23:49
He percents pretty good.
Jake Warner 23:50
80%. Yeah, it's still pretty good. to your second question. What questions would I ask other founders who have more experience? I think the most challenging thing for me today are the items around proper team building. And actually, relative to my response to the first question is proper team building and you're making sure that everyone is incentivized, but also balancing that with the changing requirements of a company that can be demotivating to a team to have to change up that team from time to time as the company's demand changes, but at the same time, you don't want to demotivate people who are still on that team. So So I think that's the hard part is like most I think most of the questions I would have would come down to to team building it. I mean, it sounds weird, but I read a post one time it was a few months ago. I don't remember where I got it. I think it was on I think it was either Reddit or LinkedIn, but it was something along the lines of four years instead of four years. To really get a company going, because after those four years, most people who were there that started with you are not going to be there anymore, or something along lines of that. A really good hire who's really incentivized, you can expect to be around for about four years. After that, they're going to be on to do something else, right? I kind of get it. People always want to have new experiences, they always want to try new things, etc, etc. But when your goal is to build a company over a decade, and not just over a couple years, that four year window really hurts. And it's something that we keep seeing and seeing and seeing and seeing is that even great people will come to the company, you'll enjoy it for a few years, and then there'll be on to something else. And that's always a challenge.
Alex Williams 25:43
Jake, thanks so much for taking some time to talk with me. I appreciate your, your your candidness. For anyone who is unfamiliar with cycle, they've really have a unique take. And their whole bare metal story is an interesting one. And so I would urge people who are curious about Jake's perspectives on bare metal to reach out to him, because he's got a really interesting take on it. And like how you think about it in comparison to fully virtualized and container platforms such as Kubernetes. And the differences there and the complexities that come with Kubernetes is something that Jake really can speak to. So Jake, thank you very much for your time, and I look forward to talking to you soon.
Jake Warner 26:25
Thanks, Alex. It was a blast.
Alex Williams 26:29
Thanks for listening. If you liked the show, please rate and review us on Apple podcast, Spotify, or wherever you get your podcasts. That's one of the best ways you can help us grow this community and we really appreciate your feedback. You can find the full video version of this episode on YouTube. Search for the new stack and don't forget to subscribe so you never miss any new videos. Thanks for joining us and see you soon.
Transcribed by https://otter.ai