Adam Jacob grew up in Vancouver, but now lives North of San Francisco. He's married with a teenage daughter, and grew up in the era of the internet that was bulletin based. He likes music, specifically heavy metal. He was raised on 80's hair metal, but also enjoys modern and Swedish metal, of which your host is very familiar. He also loves cats, and at one point, had a bengal, which is a cross between a tiger and a domestic cat.Previously, Adam was the creator of Chef, and has spent many years building a successful platform, extending DevOops value with automated security and compliance. He and his now cofounder reached the limits of what could be achieved using conventional approaches in the space - and decided build a new tool, to enable engineers to tackle complex infra and app management without compromising control.This is the creation story of System Initiative.SponsorsCacheFlyClearQueryKiteworksLinkshttps://www.systeminit.com/https://www.linkedin.com/in/adamjacob/Our Sponsors:* Check out Vanta and use my code CODESTORY for a great deal: https://www.vanta.comSupport this podcast at — https://redcircle.com/code-story/donationsAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy
It's taken us five years to build it, and there's a couple of reasons for that period of time. What we wanted was an order of magnitude better experience than what you could have doing it with the existing tooling. And the existing tooling is pretty good. If you think about trying to be an order of magnitude better, there's just a lot you have to account for.
I like to think about software development a little more like art than like science. Like it's a thing that we're creating because that's what we want to see. And then we're observing how other people react to it. And it's in that conversation that the art shapes itself.
And so the first MVPs of System Initiative started with trying to build systems where we could infer as much about the infrastructure as possible. My name is Adam Jacob. I'm the CEO and co-founder of System Initiative.
This is Code Story, a podcast bringing you interviews with tech visionaries who share what it takes to change an industry, who built the teams that have their back, keeping scalability top of mind. The stories you don't read in the headlines. To ride the ups and downs of the startup life. It's not just about technology. All this and more on CodeStory. I'm your host, Noah Labpart.
And today, how Adam Jacob is building a collaborative power tool for DevOps to remove the paper cuts and automate intelligently. This episode is sponsored by KiteWorks. Legacy managed file transfer tools lack proper security, putting sensitive data at risk. With KiteWorks MFT, companies can send automated or ad hoc files in a fully integrated, highly secure manner.
The solution is FedRAMP moderate authorized by the Department of Defense and has been so since 2017. Step into the future of secure managed file transfer with KiteWorks. Visit KiteWorks.com to get started. This episode is sponsored by ClearQuery. ClearQuery is the analytics for humans platform. With their full suite of features, you can go from data ingestion to automated insights seamlessly.
With Ask ClearQuery, you can find valuable insights into your data using plain English. Don't miss the opportunity to simplify your data analytics with ClearQuery. Get started today at clearquery.io slash code story. Adam Jacob grew up in Vancouver, but now lives north of San Francisco. He's married with a teenage daughter and grew up in the era of the internet that was bulletin-based.
He likes music, specifically heavy metal. He was raised on 80s hair metal, but also enjoys modern and Swedish metal, of which your host is very familiar. He also loves cats and at one point had a bangle, which is a cross between a tiger and a domestic cat.
Previously, Adam was a key contributor at Chef and has spent many years building a successful platform, extending DevOps value with automated security and compliance.
He and his now co-founder reached the limits of what could be achieved using conventional approaches in the space and decided to build a new tool to enable engineers to tackle complex infra and app management without compromising control. This is the creation story of System Initiative.
What System Initiative is, it's our attempt to rebuild the way that we do DevOps work. Part of my background in technology is once upon a time I wrote a thing called Chef, which did configuration management. Tools like Chef and Puppet and Ansible created a lot of the modern automation that we all use now. So they were like the precursors to things like Terraform and that sort of thing, Kubernetes.
My title is CEO, but in reality, I love building infrastructure and I love building tools for people who build infrastructure. System Initiative is our attempt to think about what would be a truly massive leap forward in the user experience of building and maintaining these complex infrastructure and application platforms.
We started about five years ago, and the big difference is basically rather than thinking about all of the software, that the way that we do it now is we have a bunch of different tools that get glued together across the stack, right? So you've got source control and you've got a little bit of automation. Maybe you use Terraform, maybe you use Ansible, maybe you use Chef.
Maybe you use GitHub and then you use maybe GitHub Actions and GitLab and CI and all this stuff. And you cobble together your pipelines, put together some shape of stuff, and you try to automate all of this work. In truth, though, doing that is pretty not only hard, but the experience of doing it isn't very good.
So if you ask people who are great at it, like how they feel about their tools, they're proud of them because they work. But the experience of doing it is let's just call it suboptimal. And so what System Initiative does is basically transforms all that stuff up into data rather than code and then takes all of that information and tries to model the world as it is one to one.
So we build these digital twins of all your digital assets. And then we use that data and we stick it on this big hypergraph of functions. So think of each property of each thing you need to configure or each thing you want to manage or each application you want to describe or whatever it is you need to model.
And each of those properties is the result of a reactive function that takes other properties as inputs. If I say that this load balancer is configured because it's going to load balance your application and your application exposes itself on a port number, I can use that port number as an input to setting the load balancer's pool up.
And then if I change the application's port number, it would automatically reconfigure the pool. And then you can fork that into multiple dimensions and do all that stuff. And then we use all of that information in this big hypergraph of functions to deliver a user experience that's much more multiplayer and interactive in real time.
So we basically allow you to compose your infrastructure in a way that kind of feels like building an architecture diagram. But what it's really doing is driving this huge graph of all these complex functions and then letting you program those functions if you need to. So it's a little more like thinking about infrastructure
the way that people who build video games think about stuff like unreal right so it's more like an engine that sits on top of all the data and then we use that data to then drive change into the world tell me about the mvp this will be interesting to hear where you start in this how long did it take to build what sort of tools were you using to bring it to life you know that first version right of system initiative
It's taken us five years to build it. As we're talking to each other, we're onboarding the very first production users. And there's a couple of reasons for that period of time. The big one is just that what we wanted was an order of magnitude better experience than what you could have doing it with the existing tooling. And the existing tooling is pretty good.
If you think about trying to be an order of magnitude better, there's just a lot you have to account for. I like to think about software development a little more like art than like science. Like it's a thing that we're creating because that's what we want to see. And then we're observing how other people react to it. And it's in that conversation that the art shapes itself.
And so the first MVPs of System Initiative started with trying to build systems where we could infer as much about the infrastructure as possible. A little like how a lot of people are trying to think about using LLMs now to try to like automate infrastructure.
We basically built these really high fidelity models with all these tunable parameters and constraints, and then would let you specify the smallest number of constraints. And then we would infer all the rest. So you could say, I need a server that can run Postgres. And we would infer from those statements that you probably meant you wanted to run it in AWS.
You probably wanted it to be of a particular size, right? We could infer all that behavior. And that initial MVP was pretty cool. The bummer was that in infrastructure, something works or it doesn't, usually because it's quite specific. It's not like you can just swap one thing for another most of the time.
Usually what makes any individual application work is some specific set of infrastructure choices and configuration. And so you wind up kind of playing whack-a-mole with the constraints. You'd be like, which constraints do I need to specify in order to get the thing I already know that I want?
And then from there, I think we've probably evolved and rebuilt and redesigned the fundamental technology probably half a dozen times.
In making some of those decisions and how you went about building it and then rebuilding it, you know, a few times, tell me about maybe a hard trade-off you had to make, you know, and how you coped with the decision. You know, it could have been around approach, positioning, you know, acceptance of any sort of debt maybe or anything like that.
But tell me about some of those you had to work through.
With venture-backed startups in general, there's a question always of which game really are you playing? For me, the game I want to play and what this company is designed to do, like I want to win. I want to build a product that transforms the whole industry. System Initiative has the potential to do that. Obviously, you can't say you've done it until you have.
So time will tell if we actually did or do. But some of the hard trade-offs you make are when your ambition is really high and you believe that something should be possible, but no one's ever built a system that works this way or had to think of it this way before.
You're constantly making trade-offs about how powerful the underlying system will be versus what you can get in front of someone immediately. We had working versions of System Initiative that could generate like Kubernetes configurations and in a pretty delightful way, but it wasn't very programmable, right?
You could use it to put together things that we put together for you, but you couldn't really make it do things that were bespoke. You have to make a decision, which is, do you bring the first thing to market where it's not very programmable, the use case is a little more constrained, and what do you learn by bringing that thing into the market?
For us, the decision was, what we want is to build a transformative product that we believe people could use across the spectrum from giant banks to small companies, and that they could use this technology to really run the entirety of their infrastructure automation, but eventually the whole of the DevOps stack. So we had to make trade-offs on how much time are you willing to spend?
How much effort are you willing to expend? How difficult is it in order to get that vision to come into fruition? Where at each stage, there's an off-ramp where you could build a less powerful thing. You could decide to bring a version of it that is less functional, a version of it that maybe does a little less or is a little less valuable. And you have to decide, is that what you want to do?
Or do you want to keep building the more powerful thing that you really believe is transformative in the end? There's tons of smaller technical trade-offs. For example, we started out by modeling Kubernetes. We then learned that while there were plenty of people who had complaints about Kubernetes, overall, the market kind of still was a little in love with it.
People would be like, yeah, that bothers me, but it's fine. And there were other tools that we could focus on modeling more like the experience of putting together your infrastructure for AWS, for example, where people hated it. When you ask them, how do you feel about the tools that help you manage all your AWS infrastructure? It was like grudging respect was like a pretty good answer.
And so it made more sense to think about moving the product in that direction because A, it was easier to focus in on, but B, there was a little more discontent with the shape of the tooling that they already had.
This episode is sponsored by KiteWorks. Legacy managed file transfer tools are dated and lack the security that today's remote workforce demands. Companies that continue relying on outdated technology put their sensitive data at risk. And that's where KiteWorks comes in. KiteWorks MFT is absolutely the most secure MFT on the market today.
It has been FedRAMP moderate authorized by the Department of Defense since 2017. Through FedRAMP, KiteWorks level of security compliance provides a fast route to CMMC compliance, saving customers time, effort, and money. KiteWorks MFT makes it easy for users to send automated or ad hoc files via fully integrated shared folders and email.
administrators can manage policies in a unified console and create custom integrations using their API. Did we mention it's secure? The level of security with KiteWorks solution is rare to find. Step into the future of secure managed file transfer with KiteWorks. Visit KiteWorks.com to get started. That's K-I-T-E-W-O-R-K-S dot com. This episode is sponsored by CashFly.
The web is a competitive place, and if your site delivers its content pixelated, slow, or not at all, well, then you lose. But that's where CashFly comes in. CashFly delivers rich media content up to 159% faster than other major CDNs. Through ultra-low latency streaming, lightning-fast gaming, and optimized mobile content, the company offers a variety of benefits.
For over 20 years, CashFly has held a track record for high-performing, ultra-reliable content delivery. While competitors call themselves fast or use cute animal names, only CashFly holds the record of being the fastest and serves customers like Adobe, the NFL, or Roblox, where content is created by users and must be delivered in real time.
For the first time ever, CodeStory listeners can get a 5TB CDN for free. Yep, you heard that right. Free. Learn more at cashfly.com slash codestory. That's C-A-C-H-E-F-L-Y dot com slash codestory. You're at the point now where you're bringing people onto the platform... How are you planning to progress and mature it? I think the best backbone for that question is around roadmap.
How do you go about deciding what's the next most important thing to build or to address with system initiative?
Roadmaps are tricky, right? There's a comedian who had a quote. I wish I remember their name because I'm going to quote them now. I'm sorry that I don't. But when somebody comes to you with a problem, they're usually right about the problem and they're totally wrong about the solution. Conceptually, this is very true in products.
Like people will tell you if somebody comes, if you have a customer come and tell you what's wrong with your product, they probably come with an answer to what they think you should do. And that answer is usually the wrong thing because there's usually no delight to be found in it, right?
If your customer knows the product as well as you do, understands all the details, maybe they're going to give you like a really delightful solution, but usually they don't. You have to think about how do you build a roadmap that allows you to talk about the general direction that the technology and the platform is going to head while leaving the space to allow the specifics to evolve?
Because on any given day, I know less today than I'll know tomorrow about what would actually make my customers happy, what would actually make the product better, what would actually make those things happen. So you have to give yourself the space to be able to embrace that truth and move through it. I look at a year out, and what you do is think about themes.
And inside there, you've got stuff that you vaguely believe is important to do, and you have reasons why you believe it. And so you tell those stories to each other and to your people who ask you about the roadmap by saying, look, in System Initiative's case, we need to increase the number of assets that you can use. So we need more coverage of various cloud providers.
And we also need to do some improvements to the authoring experience. And we need to add some security RBOX stuff to it. And maybe we have to do SOC 2 compliance or whatever.
You can take those things and you put them roughly on a map according to time and you talk about them not in terms of the specific features you're going to build, but of the thematic through line that is important to the evolution of the product. That allows you to get feedback on whether those themes resonate, right? Because people can listen to the story of the theme and say, yeah, that's right.
I do care about that. That generalized problem domain is the thing that that that resonates with me as a user or me as a customer. And then it also leaves you the flexibility to discover what's the exact right thing to build, right? And how do you evolve that in the right way? And it allows you to move things around a little bit in space and time, right?
Because as the landscape changes, as your experience of actually writing the code, the truth of the system, plus the the exterior landscape of what's happening in the world, those things will always manipulate your roadmap in some way or another.
And so by keeping the focus on these high-level themes and the broad strokes of what you think needs to happen in there, it also gives you the space to move those things around without really changing strategic direction.
John Lewis Gaddis, who is a professor, wrote a book called On Grand Strategy, and he defines strategy as how you connect your limited resources to your unlimited aspirations across time, space, and scale. And that is what roadmaps do, right? So you want to keep the high-level scale and scope in the roadmap to be high and flexible.
And then when it gets down to the ground truth, engineers typing on keyboards, you want to be pretty specific about how what they're doing attaches to that higher-level concept.
Obviously to do something of this caliber, you have to have the right team in place. And I'm curious about how you have gone about and how you're going about building your team. And what do you look for in those people to indicate that they're the winning horses to join you?
A lot of the metaphors we use to describe businesses and describe software engineering come from the idea of a factory. So they tend to come from factory optimization. So lean, agile, a lot of that stuff was very steeped in Deming. And Deming was doing factory optimization. And so when we talk about it, the metaphors we use very frequently are similar to the ideas we use in factory optimization.
That metaphor and the way it causes us to think about building companies and teams is bad. It doesn't fit very well to the truth. The truth is people also don't love sports metaphors, but sports, professional sports in particular, are a much better analogy for what it's like to build great software engineering teams.
These are highly trained teams of experts who work autonomously to achieve an objective, and you have to keep them operating at that high level over a long period of time. You can't observe a team in isolation, so you can't look at a single day's effort from an engineer and predict anything about the outcomes of that engineer's work, right?
It just takes time to understand what the actual outcomes of any individual engineering choice or any individual product feature would be. We have to figure out how to teach people to be the best athlete that they can be. In the case of a software engineer, if you think about them the same way you would think about someone on a basketball team, like you gotta train them. I have to drill them.
I have to give them feedback all the time. I have to be present and talk about their career growth and talk about what makes them a great engineer and what makes them unique as an engineer. And then you gotta figure out how that plays with the other people that they work with in the team. And how do we keep their ability to play the game
and keep the context coming to them that they need about how the tactical work that you're asking them to do attaches to that strategic work that's on that roadmap. And so that's how I think about building teams. I think about them literally like I'm assembling a team of professional experts. And what I'm going to do is train them to be the best possible version of themselves they can be.
And then I'm going to put them on teams where I'm situating people by looking at their strengths and weaknesses and trying to figure out how do I build the strongest possible team to attack these problems.
Hello. Welcome to the Data Analytics Club. Do you know the password? No, didn't know there was one. Do you know how to code? Uh, no. Do you know how to query data? Like, ask a question? I guess not. Hmm, I see. Then you can't be in this club. Sorry. Goodbye. Don't be left out of the analytics club. ClearQuery is the analytics for humans platform.
With their full suite of features, you can go from data ingestion to automated insights seamlessly. ClearQuery provides you with the information you need without requiring you to do the heavy lifting. Their Ask ClearQuery feature allows you to ask questions in plain English, helping you find relationships and connections in your data that may have previously gone unnoticed.
You can even visualize your data with presentation mode, taking your data storytelling to the next level. Pricing is based on storage, not licenses, and that ensures that you get the most bang for your buck. Don't miss the opportunity to simplify data analytics, your data analytics, with ClearQuery. Get started today at clearquery.io slash codestory. This episode is sponsored by Cashfly.
The web is a competitive place, and if your site delivers its content pixelated, slow, or not at all, well, then you lose. But that's where Cashfly comes in. Cashfly delivers rich media content up to 159% faster than other major CDNs. Through ultra-low latency streaming, lightning-fast gaming, and optimized mobile content, the company offers a variety of benefits.
For over 20 years, CashFly has held a track record for high-performing, ultra-reliable content delivery. While competitors call themselves fast or use cute animal names, only CashFly holds the record of being the fastest and serves customers like Adobe, the NFL, or Roblox, where content is created by users and must be delivered in real time.
For the first time ever, CodeStory listeners can get a 5TB CDN for free. Yep, you heard that right. Free. Learn more at cashfly.com slash codestory. That's C-A-C-H-E-F-L-Y dot com slash codestory. So this will be super fun. Given, you know, your experience and building all kinds of great stuff, building Chef and what you're diving into with System Initiative, I'm curious about scalability.
And, you know, I'm sure that everything was built to scale from day one and with scale in mind, all those sorts of things. But I'm curious if there's any pinch points that were really hard or interesting around scale that you had to fight through.
Look, there's always pinch points around scale. It doesn't matter who you are or how good you are at the job. You'll just scale will always be painful because there's no real substitute for production load when it comes time to tell you how complex distributed system will work under pressure.
One of the things that we've had to do in order to make this work is we built that big hypergraph of functions that I mentioned at the top. That thing is literally like a big in-memory graph and the speed of the operations that you can do on that graph and the speed with which we can then recalculate those functions.
So if you imagine I change a property that then could change hundreds or thousands of other things. How do you calculate what's going to change? Then you need to execute all the functions in the right order. And then you need to apply all of those things back to this big graph so that when I display it to the user, that happens.
And it all has to happen fast enough that it feels basically like real time. That was a very difficult scaling challenge, right? Because when you look at traditional database technologies, they're all fantastic on some different angle. but they're not quite the right fit.
And so to get that interactivity and to get the shape of the system correct, we had to do a lot of work basically designing our own in-memory database. And it's super cool. I'm very proud of it. And also, whoa. Those have been a lot of the big sort of scale challenges. You mentioned sort of building for scale.
And I think in general, the way you build for scale is to try to think about how those distributed systems will work under pressure, and more importantly, how they fail under pressure. If the system's going to break, does it break in predictable ways? And how do you know what they are?
If you can understand what those boundaries are between the different components of the system, then you can start to understand predictably, here's the couple of different ways that the system could possibly fail. And then you can look at any individual failure and start to assess what you're going to do about it. There's a great story. I don't know if it's apocryphal or not.
I think it was Brian Kernaghan and Ken Thompson were pair programming in the early days of Unix and they were trying to fix a bug. And I think Kernaghan was at the keyboard and he was like attaching, attacking this bug. Ken Thompson was standing behind him and he was getting all frustrated.
And then Thompson had his like eyes closed for a couple of minutes and then opened his eyes and was like, maybe open this file and go to this line number. And there was the bug.
As I've gotten older and my career's gotten longer, I really have learned to understand what I think he was doing in that moment, which is he was thinking through the boundaries of how the software worked, of the different ways that the different pieces of software interacted with each other, and how could those things possibly interact in order to create the outcome that you're seeing that's wrong.
And that ability to do that, I think, is the critical thing to figuring out how to help systems scale in the face of failure.
So as you step out on the balcony, you look across all that you've built with System Initiative, what are you most proud of?
I'm most proud of the raw ambition of it, which I know sounds ridiculous, but there's just very few moments in your life where you have the permission to just make the best possible thing you can imagine building. And that's what I have been given the permission to do in Building System Initiative. And it's such a gift to be able to do it.
And I think that I hope people love it as much as I love it. But even if they don't, it doesn't matter because it's the best possible thing I could have done. Do you know what I mean? Like I just there's I couldn't have built better art. If it turns out that you don't like my art, so be it. But it's not because it wasn't the best thing I could build.
A lot of my life, I feel like I was trying to prove to myself that I was a person who could build products or a person who could build technology or could make things that were useful for other people. And at this stage in my life, I know that's true. I know I'm a person who can do that. And now the question is, what can I do that's the most fun?
What can I do that's the most interesting, that's the most impactful, that if it worked would be the greatest thing I could spend my time doing?
Let's flip the script a little bit. Tell me about a mistake you made and how you and your team responded to it.
one of the like core tenants of the company is that we're just wrong all the time and you should just like you just need to accept that you're wrong by default because it makes it a lot easier to make a decision if i don't need you to be right i just need you to choose that's a lot easier bar than being like oh you got to be right all the time i don't need to be right all the time i just need you to adjust
Very big one was we were trying to discover how to build this reactive engine that would be able to scale to really large, to conceptually scale to really large graphs and really large infrastructures and applications. And so we built that engine a couple of different times.
And one of the passes of it, the most recent, not the most recent pass, but the pass right before, used a lot of very old techniques. It looked a lot like an Oracle application from the 90s. A lot of stored procedures and a lot of like smart activity in the database because we're basically building a custom database engine.
So we embraced that and built a custom database engine inside of Postgres, which on some levels was magnificent. But in the end, it got overwhelmed by the things that always overwhelmed those systems, which is it's a little complicated to deal with. The table structure gets complicated. More complicated performance becomes a problem, not that those are unfixable.
And so then you had to back up and try again with a completely different architecture, with a very different approach to how everything would work. The important piece of that was we had a moment where we believed that that old engine was going to be good enough to get a couple of customers to experience the product while we were working on this newer engine that we knew would scale better.
So I split the baby in terms of having the team work on both. So there was a set of people who were... optimizing the old engine, just trying to get it good enough. And another team that was working on what was obviously going to be much better long term and even near term, but was going to take a little longer to build.
And while I'm glad that we did it because it did allow us to get a little more directed customer feedback, the customer feedback we learned was that it was too slow. We had to just come back to the team and be like, hey, we onboarded this customer. It quickly became too slow to use. So we're not doing that anymore. And it's all hands on deck. Everybody go work on the new engine.
And that's the way it is. As much as it's about the story of sort of the technical mistake or the failure, I think a lot of those stories really need to be about, like, how quickly did you learn that it was a failure? And then how quickly did you adjust? And how much time did you spend crying over the metaphorical spilled milk?
This will be fun to ask. What does the future look like for System Initiative, for the product and for your team?
We're just in an exciting minute where the product's basically ready and we're onboarding a first couple of customers to our SaaS platform right now and learning from those customers, like what they need and, and finding new bugs because there's no substitute for real users when it comes to finding bugs. As soon as possible, we're going to just open it up to the whole world.
Not that long from now, you'll be able to go to the system initiative website and click a button and then you'll have a workspace and you can just start managing infrastructure right away. Those moments are fun and it's fun to ship, but it's also fun because we build a product for operations people and it's all open source.
And so we can talk about the journey we're on in a really honest way with the people that are coming to use it because they are also people who love to do that kind of thing. I'm looking forward to when we break the platform and we have to like all hop on Discord and fix it in public because those are the people that I love anyway.
And I know I don't know about you might not be this kind of person, but I'm totally the kind of person who if I could come sit in a Discord channel while the team is troubleshooting a production outage in their production SaaS platform, I would totally hang out.
And so I'm really looking forward to those interactions and those moments where they finally get to come and play with this platform we've built that we think is really amazing and help us build it into the future and have that experience together of what it's like to bring it into the world. So that's what's next for us. And it's I'm very stoked about it.
OK, Adam, let's switch to you. Who influences the way that you work? Name a person or many persons or something you look up to and why.
In terms of product, I would say you have people like Marty Kagan, who wrote a book called Inspired. You have Jeff Patton, who has done more for me personally than anybody else has.
I feel like Jeff gave me my instincts and the things that I intuitively believed about how to build great products, like both the vocabulary and some more technique, like story mapping and those sorts of things that I could use to really bring those things into the world. When I worked at Chef and was the CTO, I got to work with a lot of different CEOs.
Jesse Robbins, who was the founding CEO of Chef. Mitch Hill, who succeeded Jesse. Barry Crist, who succeeded Mitch. All three of those people taught me so much about building businesses and being in venture capital businesses and building teams. I continue to learn a ton. I have a very well-educated... My wife is Katie Bethel. She's a very impressive human being who does a lot of like...
political advocacy and management of large organizations, which is the kind of person who can like look at the power structures in the universe and think about ways to manipulate those power structures to create the outcomes you want to see in the world. And I continue to learn a ton from her and from the sort of people around her.
Sammy Hagar, who was the second lead singer of Van Halen and himself like a solo star for a long time. I feel like he's really figured out how to be maximum Sammy Hagar all the time in a way that I really appreciate and would like to be.
Okay, you're getting on a plane and you're sitting next to a young entrepreneur who's built the next big thing. They're jazzed about it. They can't wait to show it off to the world and can't wait to show it off to you right there on the plane. What advice do you give that person having gone down this road a bit?
As quickly as possible, you need to move from this being your calling and a question of like your identity. Like when you first start in this journey, there's a lot of questions for yourself and from other people about whether you can do it and whether you're good enough or whether you're qualified or whether or not you have enough technique or any of those sorts of questions.
And then there's that question about who you are as a person, right? Am I a person who can do this? Am I a person who can be an entrepreneur? Am I a person who can do all of that stuff? All of that's very incredibly heavy, right? It's just it's really very emotional and takes a toll on everyone who decides that this is the work that they want to do.
It took me a long time to realize that this was my profession. And I think the sooner you can turn this into your job and a thing that you can get good at, it's very difficult to decide to be good at becoming the person you hope you could be. That's a it's a pretty big ask.
But if I ask you to become good at a skill, if I ask you to become good at the skill of managing people or to become good at the skill of thinking about strategy in a company or to become reasonably facile with finance or with any of the hundreds of things you have to do in order to run a startup, those are jobs you can learn how to do enough of and become good enough at that they can become your vocation.
and the sooner you can figure out how to turn it turn yourself into a professional doing a job instead of a person reaching for an identity the better off you'll be both in the things you can create in the world and also in how it feels to you as you move through the world because you can take that confidence in your skills and in your training and in your capacity to grow and use that as the fuel that moves you through all this difficult journey that sits ahead of you as an entrepreneur
Whereas if the fuel you're burning is, am I good enough? Am I smart enough? Will people like me? What happens to my family if I fail? What about my investor? You know, like all of that other stuff is very difficult, but you can put it all aside if this just becomes your vocation.
That's fantastic advice. Well, Adam, thank you for being on the show today. Thank you for telling the creation story of System Initiative.
Yeah, thank you for having me. So fun.
And this concludes another chapter of Code Story. Code Story is hosted and produced by Noah Laphart. Be sure to subscribe on Apple Podcasts, Spotify, or the podcasting app of your choice. And when you get a chance, leave us a review. Both things help us out tremendously. And thanks again for listening.