Helping Companies Transform Their Networks with Jason Edelman, Founder & CTO of Network to Code

(Intro Narrator at 00:00:03) Hello, my friends. Today, we're talking to Jason, founder and CTO of Network to Code. And we discuss how Jason is using open source projects to drive innovation in their space, why being public about their work brought the company's success as a startup, and how the mindset of value-based engineering prevents over-analysis. All of this right here, right now, on the Modern CTO podcast.

(Joel Beasley at 00:00:36) This is the Modern CTO podcast. So what's your story? How did you get to where you are today?

(Jason at 00:00:48) For myself, I started in traditional IT, traditional network engineering. Most common company there is still Cisco Systems, you know, routers, switches, that sort of industry right out of college. And then I moved over from IT to work for Cisco for a couple years. Spent a lot of time doing technical sales. Again, looking back at it, I'd say traditional network design, routers, switches, firewalls, security, that type of thing. But I would say for me, the big point of transition to where I am now is going back to probably 2010, 2011, 2012. And similar to you, I feel like I had two jobs at the time. I had my day job doing what I would call traditional networking. I became obsessed with the future of networking and started a personal blog.

(Jason at 00:01:40) And at the time, it was sort of like blog at night, lab at night, sort of experiments. You know, keep learning. And that was all about network automation, right? When we look at the industry, it was very archaic, still is. A lot of manual operations, you know, thousands of devices in these larger organizations. And it was like, a lightbulb went off. It was like, look, DevOps is a thing. DevOps is really focused on apps and systems. Networking has the same problems. And so I mean, blog turned to speaking at conferences, and I just recognized the problem was massive and global.

(Jason at 00:02:17) And I would say for me, in 2014, I made the decision to leave where I was to start a business called Network to Code. And, you know, fast forward over the years, we've grown tremendously. But the focus and the mission hasn't changed. It's really just all about how to help our clients operationalize their network. My background, I often joke, you know, we've lived the pain of these manual networking changes and logging into devices. And now, you know, we're a company full of passionate folks just solving these problems with our clients.

(Joel Beasley at 00:02:49) So to that point of pain, who do you sell to? And then what's the pain that they're experiencing and they start seeking out a solution like yours?

(Jason at 00:02:58) Yeah. So for us day to day, there's probably four or five key verticals in terms of profiles. I would say common ones: financials and pharma, even higher ed, you know, universities, things like that, even retail organizations. I would say use cases are often horizontal in terms of trying to look at network automation. You know, some of the why might be a bit more unique, but around things like compliance and verifying, you know, devices and configurations are the same and, you know, according to standard.

(Jason at 00:03:33) It's some of these basic things, or do upgrades, right? We look at some of these organizations, there are, for one, a plethora of devices, a number of different vendors and technologies, and it's grown organically over the past twenty years. So the day to day, kind of going back from day one, these sort of new requirements came in, deploy more devices.

(Jason at 00:03:54) And at the time, a lot of these devices only had a CLI or a command line interface. And so hardcore network engineers from the nineties and two thousands even to today, they know their stuff, but all they were given were device-by-device management. And so I'll give the example in terms of making it more analogous to a wider scale, like the day to day of an individual like us at home. A lot of us at home right now, almost everybody has home routers. And to manage a home router, you put the IP address in your web browser, you log in, you make a change, and you're good.

(Jason at 00:04:31) You know, imagine doing that for your block or your city or your state. Manage it the same way. Like, you would literally go crazy. And then you look at organizations, if it's financial institutions that have thousands of sites, hundreds of sites, there's thousands of devices. And so their network engineers today are still, majority of the time, logging into each device to either make a change, maybe gather data, verify something.

(Jason at 00:04:57) But at the end of the day, it's a lot of manual interactions and also manual verification to think about what should be on the device, right? Thousands of devices. All they've had is what is running presently, but nothing to baseline it against, to compare to. So the focus is really around those areas and common use cases across those verticals. But it can be, you know, predictability, reliability is big, a lot of human error making changes, things like that. So it's really just trying to transform from that device-by-device manual touch point with infrastructure. And for us, it's really trying to embrace DevOps processes, tools, and tech, but applying it to the networking domain right now.

(Joel Beasley at 00:05:44) Well, that makes your logo make more sense to me now.

(Jason at 00:05:48) Yeah. Yeah. It's funny. Yeah. Looking at the company name of Network to Code, it's very Pythonic in terms of the greater than signs. For those who aren't aware, greater than sign, greater than sign, greater than sign, it might look at Python shell interactive shell environment, Network to Code. You know, that's one of the things that I'm proud of, to have a pretty slick logo like that.

(Joel Beasley at 00:06:07) Absolutely. There's no arguments in there, though. I want to know what's going to go in there.

(Jason at 00:06:11) Yeah. Yeah. Yeah. Exactly.

(Joel Beasley at 00:06:13) So I'm going to tell you my basic understanding of it, and you tell me how I'm wrong. So it sounds like you take all these devices and you sort of build a network out of them so you can make a change and it deploys across all the devices versus having to go into each device?

(Jason at 00:06:28) Yeah. So similar. I would say, basically, I would encourage you to think about it as, we definitely want to simplify the way changes are made, but automation in general. And I point that out because change management is the most commonly talked about one. If you want to verify your devices are operating as expected or they're configured as expected, it's really about going to the device, getting the data, parsing through it, and getting a report, as an example. But in general, our overall philosophy that we work with our clients on a daily basis is really having, first of all, a data-first approach. In terms of what I was saying earlier, the only thing engineers have had over the years is what's running currently. But when you think about what should it be, our approach is to first, let's define, call it the intent, the desired state, for it into a database, call it source of truth in our domain, and have that data be modeled agnostically, right? So if you are using a multi-vendor environment, routers, firewalls, clouds, doesn't matter, AWS, doesn't matter sort of what you're using, but start thinking about it in a more agnostic manner.

(Jason at 00:07:34) Really, decoupling the data from maybe syntax, right? Just the intent in this database. And then based on requirements, customers use a tool or set of tools to fetch that data and generate API calls or configuration commands to go down to the device. So it's sort of like the collection of these systems together to create an architecture that is used to manage the network more like a system.

(Jason at 00:08:01) And then even doing that, if you get a one-off change, great. But it allows users to think about services. They want to apply a change maybe to Asia-Pac or maybe to US. And it really allows the flexibility to do that. But I would say one of the biggest changes that we're seeing now is that idea of source of truth and intent first. Really think through the data, agnostic from the vendors. Because in this industry, in the networking world, a lot of engineers first think about what commands they're going to configure on the device. Really low level versus let's think about the design and the data. Then it becomes like a byproduct to figure out how to generate the right commands or API calls to implement, you know, whatever is needed on the network.

(Joel Beasley at 00:08:50) That's pretty cool. It reminds me a lot of the infrastructure as code movement. That's what's going off in my head when you're describing it. That's, I think, the closest thing I'm connecting it with.

(Jason at 00:09:01) Yeah. No. Exactly. That's what it is. It's funny, you bring up the logo earlier. You know, my first choice for the company name was actually Network as Code and reached out. I really wanted the domain to match, and Network as Code was already purchased by somebody else. I tried to get it. They wouldn't give it up.

(Jason at 00:09:19) So Network to Code was secondary, but similar philosophies, right? It could be even when you're storing your data, it could be YAML files, right? It's the most common thing when you look at IaC, even NaC. And then if it gets to a certain point in scale, you need more structured models and things like that. Source of truth for certain pieces of data, but it could be YAML files, JSON files, and things like that, stored in repositories, pipelines. It's really bringing that overall approach that has really been probably tried, true, and proven, right, in other technology domains into the network space, which has been amazing to see. Because the one part that's really unique is over the past, I would say five to eight years, the idea of code, pipelines, development, all these things are brand new to the network space. So there's now new certifications, new training classes across the industry. And it's really cool to see that a lot of engineers are transforming their careers, right? Going from network engineer to automation engineer. You know?

(Jason at 00:10:28) It's just great to see. Another parallel: I was fortunate to be a co-author of a book a couple years ago that really was trying to drive home these concepts, right, to empower the engineer of the future. It was an O'Reilly book called Network Reliability and Automation. You know, second edition's coming out next year. A coworker's taking the reins from myself in that book. But it's really just trying to leverage concepts and principles in the DevOps space or IaC space in the networking domain. And, again, you can call that NetDevOps, sort of our little spin on things in the industry.

(Joel Beasley at 00:11:06) What animal did you have sketched on the front of your O'Reilly book?

(Jason at 00:11:10) Alligator. Yeah. I mean, yeah. It was, I'm 99.99% sure it was the alligator. A blue alligator. Yeah.

(Joel Beasley at 00:11:22) If you could have had any animal, which would it be?

(Jason at 00:11:25) Man, that is a tough one. I probably would say, I think about what we're doing with transformation of careers in the industry and going fast. You know, what we are going, we are going slow, but I would say to really emphasize that change is needed. I don't know, probably say maybe the cheetah or a leopard to be able to go fast.

(Joel Beasley at 00:11:50) There you go. Yeah. I like it. I like that. Or you could go speed, right? Cheetah, leopard. Or you could go transformation, like chameleon, right?

(Jason at 00:12:01) I was going to say it, but I didn't want to revert back to where you were.

(Joel Beasley at 00:12:07) Yeah.

(Jason at 00:12:07) Because—

(Joel Beasley at 00:12:08) All right. So how are you growing this company? Is it network engineers that are using an open source tool and then they find your company and you solve some problem with them? Or are you selling in to the executive team? Like, what's happening? How are people getting involved with your product?

(Jason at 00:12:24) Yeah. So, yeah, good question. And so I would say it's interesting. As a business, this is what makes us really, really unique: we are a services-based business. And I always love emphasizing that because, you know, we're consultative, right? Trying to go in there and consult, look at problems, requirements, and build solutions. But we do also have open source software that we build and maintain and contribute back to other projects that aren't companies. And it's important because the largest project that we have maintained publicly is called Nautobot. It's a source of truth, a data platform I was mentioning earlier. And, you know, it's becoming really a foundation to really drive automation.

(Jason at 00:13:06) But the great thing is it's open source. It's free. So it's not a product that we sell. But at the same time, we look at the acceleration of what we can do for customers. And I would say even for me personally going back in terms of the company, we're very rooted in community, open source.

(Jason at 00:13:28) And really, you know, at the end of the day, I think back to the early days of recognizing the gaps in the industry. So for us, we at this point, we probably have a couple dozen open source projects that are really kind of driving the way across the industry. That's sort of the core of who we are. And a lot of these pieces of software, we are using in our projects to really drive customer adoption and engagement. The great thing is, the software itself is free.

(Jason at 00:13:59) So customers, or I should say, users don't have to engage with us at all, right? If they have the skills and the experience to go download and use, great. And give us the feedback, open the pull requests on GitHub, drive the direction of the community, and it makes it a win-win. It makes it a win-win for, I would say, those who have smaller teams, they have the skills. But larger organizations, you know, in general, there needs to be help around the adoption of technology or the rollout of global, global scale. And the great thing, again, great thing you just mentioned, the community in terms of our team. You know, we've hired a lot of people who have been very passionate about community before they even joined. And even a lot of customers have found us, right? Just doing open source software, speaking engagements at conferences, and things like that. It really does make us unique, bringing it back to the point of, we see ourselves as sort of this tech-enabled services company where, you know, software and tech is free, but it really does power a lot of architectures that we employ and deploy on a daily basis.

(Joel Beasley at 00:15:13) Well, that's cool. So this, I don't know how to say it. Is it, I'm going to try. Nautobot? What is this?

(Jason at 00:15:20) Nautobot. It's almost like, the way I think about it, and we don't even emphasize this a lot, but Nautobot, you can think about it as a network automation bot. So it's just Nautobot, Transformers with Autobot, put the N in front, and it's Nautobot.

(Joel Beasley at 00:15:35) Network Autobot.

(Jason at 00:15:37) Right. Yeah.

(Joel Beasley at 00:15:38) Now that you say that, it makes sense. And that's the tool.

(Jason at 00:15:41) Yeah. Yeah. It's a whole project that at its core is a source of truth, data platform. So it's the intended state. And the nice thing is we built this ecosystem of apps around it.

(Jason at 00:15:54) And I just do the smartphone analogy in the sense that, hey, our smartphone is a smartphone at its core. It's a phone, but you also have these high productivity apps on top of it that are arguably more valuable than the phone itself, quote unquote. And so for us, the core is the data itself. Right?

(Jason at 00:16:14) And once this data is stored, you can do interesting things around driving automation. And so there's a lot of apps that are being built around all of that to do things like upgrades, compliance, and firewall automation, and things like that. Again, it really makes it more unique because for us, every customer is different. And we have customers, and I should say, community adopters and users that only use it for the data platform itself, source of truth. But we also have a lot of customers and adopters that like the platform approach to really doing your compliance and upgrades and things like that in an all-in-one platform.

(Jason at 00:16:55) So it kind of has the best of both worlds where look, really, choose what's best for your environment, and it has flexibility, again, based on size and scale and skills and all these things that make a lot of enterprises drive their requirements. Right?

(Joel Beasley at 00:17:11) Got it. I'm actually kind of curious because I was talking with this company called permit.io, and they allowed developers to just insert permissions infrastructure into their work. It saves time and whatnot. But does your product at all cross with password or identity systems, or is it just after authentication and then it's just running commands?

(Jason at 00:17:32) Yeah, it's a good question. There is some integrations with platforms like HashiCorp Vault for secrets management, things like that. Number of others too, I think AWS Secrets Manager. And what's interesting is Nautobot itself as a source of truth that we really want to kind of be out of the game of storing secrets and that sort of thing because of all the requirements for enterprises, and a lot of them already have standards tools that are deployed.

(Jason at 00:18:04) And so we always look to, to be honest, have a flexible approach with creating providers and adapters. And so in our space, in the networking domain, if you were automating devices, then the inventory and things like that is stored in Nautobot, the source of truth, but it allows users to be able to fetch the credentials and the secrets from the systems dynamically to be able to store in a secure manner without duplicating efforts and having customers have yet another place to store secrets. So there are secret integrations and things like that. There's integrations for single sign-on to the app itself. And then within the app, yeah, there's lots of permissions to be able to slice and dice you on level one, two, three, four people to only see certain things.

(Jason at 00:18:56) So, yeah, definitely a lot that can be done from a security perspective within the platform itself.

(Joel Beasley at 00:19:03) What's one thing that you can't automate but you wish you could? Can't be revenue generation.

(Jason at 00:19:09) Oh, yeah. I'll take something that exists today. It's possible, but there really wish there was more standards around it for in a multi-vendor fashion. It's just zero-touch provisioning. Meaning you're deploying a new site or, you know, I would say a new data center. I would say a new site that has a couple of firewalls, couple of routers, couple of switches, couple of wireless devices. And it is a little bit rare to have everything come from the same vendor. And even if it does, to have all those devices integrate to the same zero-touch platform. And there's been some stabs at some open source work to be able to say, hey, this is a zero-touch multi-vendor server.

(Jason at 00:19:52) So it's possible, but it's not as possible per se as it could be if the industry had a little bit more standards and working together, looking at boot processes and fetching IP addresses and so forth. Because I know a lot of the work that we do, even in brownfield automation, they're already booted and so forth. But when you're looking at single vendor automation, ZTP, if you will, zero-touch, a bit easier. But when you kind of go to this three or four vendors in a single site being able to bootstrap from ground zero, that would be a great thing if that were to fall asleep from unboxing it to racking and stacking it and having everything come up okay.

(Joel Beasley at 00:20:40) That makes sense. Right? There's always rough spots that need to be smoothed out, and it likely will. If you're having this pain point in the future, it will. Is that a problem you're looking to solve, or are you focused in another area? What's next for you?

(Jason at 00:20:52) Yeah. That's a good question. I would say we have ways around that right now that we've implemented, and it could be through third-party devices, out-of-band servers and things like that to be able to get them plugged in. So there are ways around it. You know, it's more or less the ideal way not to have dependencies. You know, I would say for us, as we continue to grow, you know, continuously—if I say two things, right? What makes us unique is we have services offerings, and then we have lots of open source software that we continue to build and maintain.

(Jason at 00:21:26) And we're building both out. Right? Mention the services arm. We think about whatever we can do to streamline adoption. Right? Turnkey services, annual checkups, monthly checkups, quarterly reviews with our clients, making sure we're in lockstep with their journey architecturally, technically, all the above. And I would say with a lot of the software, yeah, we're continuously investing in the open source space around Nautobot, this platform. As a source of truth, the goal is to model the network. And right now, you can model things like devices and interfaces and VLANs.

(Jason at 00:22:09) We're actually—you can model a lot. But as we look forward, we want to continue to expand those types of models. And if we get deeper into the weeds in the networking space, we have routing protocols, right, things like that, VPNs, and wireless topologies, cloud networks. And so, really, the goal is to continue to build out those models. So that way, no matter the cloud, no matter the networking architecture you're chosen, clients and, again, open source community could continue to store their data in this vendor-agnostic way. And then it's up to them to deploy the automation around it to really fetch that data and drive their networks.

(Joel Beasley at 00:22:48) Are you hiring currently?

(Jason at 00:22:50) Yeah. Always up into the right. That's the only way. We have a few open recs now. And, yeah, we've hired a lot this past—look, the past eight years has been like a rocket ship. But, yeah, we continue to grow in this still early market. Everyone from leaders, consultants, engineers, developers, really anybody listening. If they're in the IT space, looking at the intersection of networking and DevOps, then check us out.

(Joel Beasley at 00:23:23) You have a careers page, I'm assuming?

(Jason at 00:23:24) Yep. Yep. networktocode.com. And then you'll see in the top right sort of About Us and go to Careers. From there, you kind of see the open job works.

(Joel Beasley at 00:23:34) So I want to talk a little bit about leadership. From what I understood about your story, you worked at some companies, you did a couple different things, and then you started a company. Ninety-nine percent of businesses fail. This was your first company you started. Why did it succeed?

(Jason at 00:23:49) Yeah. It's a great question. You know, I think, looking back at it, there's a lot of good things that went our way. And I can't say there wasn't a little bit of luck along the way. But I'll say, I think what really helped is really being public about the work that I started even before starting the company, during the start, and even through. And that's when we always talk about our roots being in the community and the open source space. And that was really true for the business. And I think just being transparent with who we are and what we're doing, it's really helped because it's allowed us to continue to spread the word about automation. And for us, it's really all about that industry transformation from organizations, and individual people changing their careers, and that's always been so top of mind. And so had a lot of great conversations over the years with people in organizations.

(Jason at 00:24:55) I think we continue to just give back to the industry. And I feel like indirectly, that's helped a tremendous amount. And, you know, I would say find great partners. Yeah. I would say in the beginning, there was time where it was just me. But fortunate enough to find great partners. I believe in the mission. And that sort of continued to snowball to continue to find even more passionate people, great people, talented people. And, you know, looking, we have—we're selling services. We have open source software, but I would say that's our business.

(Jason at 00:25:30) Most of our people are second to none. I would say in our space, really, I don't think there's any other company in the world that's a customer-facing organization that has more talent than we do in our domain. I think the same companies on the road, the Facebooks and Amazons and the Googles, I think, yeah, sure. They have lots of network automation engineers and developers. But when you look at, and a lot of those companies are closed in terms of they can't really talk about what they're working on. And you've seen people sort of be open source advocates, join one of those companies, and they go quiet. I would say for us, the people really have—folks that we have hired have no doubt really shaped who we are and where we're going in the future.

(Joel Beasley at 00:26:19) As a founder, you know, things go up and down as it goes up. Right? And there's always points where you want to give up or there's doubt, and that just happens to everybody, it's a human thing. But how do you manage that? When that happens to you and you've got obstacles around you, how do you respond to that?

(Jason at 00:26:38) Yeah. It's remember what's important. Yeah. It's remembering why we're here and just always bring it back to the sort of mission that we're on to transform the industry, especially internal. Yeah. There's no doubt there's ups and downs. But when we look at, really, as a smaller business, the impact that we've had across the industry, it's energizing. Right? To really think about that as a smaller business, the smaller teams within the business and the company and the individuals, having big impacts across the world. And I think it's always good to take a step back, reflect on that, emphasize it.

(Jason at 00:27:17) And we don't probably don't do it enough. But I think that's sort of what we're thinking about day-to-day to help get through those hurdles and the bottlenecks. I would say also throw in there, when we look at internal conversations, projects, some of these things is reminding people not to overanalyze things. It's driving the ball forward. Right? Making a decision is better than not making a decision. And really, I would say what also helps is sort of customer—I love thinking about what is the customer thinking and talk to them about it. Because it's just at the end of the day, that's what is so important is to understand that we're not building software and services for us. Right? It truly is for other people in the open source space, the community and our customers. Yeah. Just remembering that just really helps remember that we are delivering a service, technology for people literally all around the world.

(Joel Beasley at 00:28:22) When I read your bio, something stood out to me. You had this quote in there that said, "Obstacles are what you see when you take your eyes off the goal." And for me, when I read that, I copied and pasted that. I'm saving this. You know? That's a beautiful little nugget, and I have never heard it before. And so you get the award for bringing that into my life. So thank you.

(Jason at 00:28:43) Yeah. No. I love that one. I think it might have been in high school, I started to really think about it frequently. I'll never forget when in high school to college, I used to use that quote on my AIM profile on AOL Instant Messenger. Oh, yeah. And that was sort of my go-to quote. So twenty-plus years in the making, no doubt. Right? I would say everyone's got to be thinking about that goal. Really, it is so easy to get caught up in the leaves and the trees and the forest, but yeah, keep your eyes set on the bigger picture, and I think it helps tremendously.

(Joel Beasley at 00:29:14) I got to ask. What was your AIM handle?

(Jason at 00:29:18) Oh, you know, for a second, I was going to say it was my current handle on things, but it wasn't. My current AIM handle was jrerock.

(Joel Beasley at 00:29:27) Okay.

(Jason at 00:29:28) So my initials, JRE, and rock. Don't know why I chose rock. But I created it in seventh grade.

(Joel Beasley at 00:29:34) There you go. Yeah. I love that too. If you're checking out someplace, you'll often hear people give an email that's the email they created in middle school. It's cheerleader97 or whatever. That's a beautiful part of life, hearing people's past usernames or their old, their first emails and things like that.

(Jason at 00:29:52) Totally. Executive analyst email? Oh, it was [email protected]. Yeah.

(Joel Beasley at 00:29:58) Dude, that's great. That's great. Thank you for sharing that. So I'm always looking on how to bring advice to the audience. And one thing that we've gotten a couple times is people asking when you're interviewing someone for a position, in the limited time that you have available with them, how do you determine if they're a good fit or not?

(Jason at 00:30:19) Yeah. It's a great question. And I know on our side, everyone has their own angle. And we're a technology organization, so technology is a part of it. We'll do technical challenges, hands-on challenges. But I would say as we continue to grow, I would say what we're looking for at the end of the day, and for me personally, it's sort of it really is an attitude and thought process around solution building. Right? So it's less about what you can do maybe today. But I would say it really is questions around aptitude and attitude. Yeah.

(Jason at 00:31:00) I think that it's good being a good person, being able to, everything from having a sense of urgency, some of these soft skills type things that really differentiate people. Yeah. That's some of the things that we look for. I'll say an example of some of the things that come up in unique ways is, you know, when I mentioned sort of even solution building and, you know, as a client-facing organization. Because, hey, you can have stellar engineers that want to build, build, build, but at the same time, it could be more than a customer needs. And I think for us, as a services business, you have to have the fine line of recognizing that fact. And even this morning, actually, how it came to process, I think it was on maybe LinkedIn. But I literally just watched it this morning. But it was have you ever seen somebody draw a Spider-Man in three different time intervals? Yeah.

(Joel Beasley at 00:31:54) I have seen that one.

(Jason at 00:31:56) Yeah, the one that I saw today was ten seconds, one minute, and ten minutes. And so, you know, as an engineer at heart, oftentimes you want to really do your, you know, sort of the best engineering of it. So it's like the ten minute drawing. And I would say ten second, sloppy. Obviously, we shouldn't be doing, sorry, like ten second engineering. The one for Spider-Man wasn't terrible. I feel like if there would have been, in this example, literally a two to four minute version of Spider-Man, that would have met all requirements: color schemes, style. Like, it would hit at home. So I would say interviewing for us is really thinking through that mindset, sort of where consulting and technology merge to be able to understand, does this meet requirements, provide scale, provide flexibility, without having to over-engineer potentially and build everything into one dot O, or what should be the MVP. And, you know, a lot of these, again, soft skills are sort of what we're all looking for as we hire.

(Joel Beasley at 00:33:04) It's almost a trap you can't avoid. Right? So for me, when you start building stuff, it's addictive. And it's like I feel like a caveman that just made fire. It's like, whoa, I did that. I affected the world. And then you want to build something, and then you think it's cool, and then you want to build it more complicated. But you have to sort of fall out of love with it in one sense and then make sure that you're checking that whoever's paying you to do this, or whatever value you're bringing to the marketplace, that you have to sort of put them in front of it and then just figure out how to serve them. And for me, you know, going through that process of building something cool and then figuring out how to make money with it and then realizing where focus needs to be seems to be—I haven't met people that are so great they skip all of that. Right? That tends to be a path people go through. And so coaching them through that is something that I've found to be a part of the job.

(Jason at 00:33:57) Yeah. So there was an exercise that I did years ago in a different job, and it was actually non-development related, but it's still very similar. There's value-based engineering. And, you know, this is where as a small business owner, you know, from where you are, where I was, and if I were to continue to grow, this mindset can't leave us because you have to be able to understand how you maximize value for your customers and for your clients. And it's not by over-engineering, but it really is understanding the feature developments, what customers are really looking for and asking for, and meeting those requirements. And I would say internally, it's sort of like how it's built—the internals and how the guts of the application are—it's a different animal. And I've read a lot around how larger organizations like Google do code reviews. It's okay to be put in there to allow a newer employee to issue a pull request to improve that part of the code base. It doesn't have to be pristine. It doesn't have to be perfect. But we have to be able to deliver value to the adopters of the technology or the application. That's super exciting, obviously, whenever you build something and do a demo for a user, anything from enterprise app to smartphone app, whatever it is. When you see those users using it, you know, it makes you feel pretty good that they're consuming the value out of whatever's been built.

(Joel Beasley at 00:35:24) What is the coolest customer that you've had? And you don't have to say their name. What was personally cool for you? Like, I've had customers that are big logos and it was kind of cool. Like, oh, I got to work with them. What's one of the areas? Like, was it a cybersecurity company, government-type stuff? What was the cool one for you?

(Jason at 00:35:43) Yeah. I would say I'll pick two. It's always hard for me to pick the one. One, we have—we've had and have had very large projects with some of the biggest financials in the world. So I think seeing that grow has been rewarding, personally and for the business. And I look at it from the different angle of cool tech, interesting use cases, good environment, snazzy office space, things like that. There was one that was a sports league, a larger national-based sports league. And we were at a conference, at a bar in California after we did the deployments. And a lot of what we do, we'll always talk about simplifying the consumption of the network. And one thing we do often is ChatOps, implementing chat. So you can use Slack, Teams, doesn't matter what it is, to perform a network function and just to really bring it to life. And we're at the bar, and the customer was demoing it back to us and what we helped them with. And so that was probably the coolest thing. It was a cool customer, great team, and just saying, hey, you know what? Didn't have to go back to the hotel, get the laptop open, connect to VPN while I make the change. It's literally—we're at the bar to kind of do the demo, and you can be on a subway, it could be anywhere. So I feel like that was one of the great moments when we're at a bar. So, you know, cheers. Had a drink, and that was just a great time.

(Joel Beasley at 00:37:20) Nice. Nice. I got one last leadership question for you. You're leaving that bar. You're sober. You're driving. Right? You're at a stoplight, and Elon Musk's hovercraft comes down next to you because he's got that new car, that new Tesla 2020 that's still not out. But that one's a hovercraft now. And he's like, hey, buddy, come on over. I want to show you something. So you follow him. You're like, it's Elon Musk, of course. And he takes you to his house, and he's got a time machine. Now in this time machine, you can go back to the moment you were deciding to start this business and give yourself one piece of advice. That's it. Just one. Just walk up to yourself. Boom. You get to say one thing. What would that be?

(Jason at 00:38:05) That is a really good one. Yeah. Look, I think I'd probably go with: go with your gut. You know, stay true to yourself and stay on track for the mission. Right? In very, maybe Elon Musk fashion, you've got to be able to stay on that mission. And I think as businesses grow, decisions get harder. Problems obviously and issues can escalate fast. And I think it's, you know, don't forget sort of why you started this, why you started. And, you know, think about it often, even more than I have. And take a step back and maybe even celebrate more. I would say personally, I don't—I'm very focused around problem-solving and pointing out what can be better. And, you know, looking back, maybe I would have made a more conscious effort earlier on to celebrate more wins along the way.

(Joel Beasley at 00:39:04) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you would like to hear discussed on the podcast, either add me on LinkedIn or send me an email: [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.