Cloud Security Today

Innovating at the Speed of Relevance

October 18, 2021 Matthew Chiodi Season 1 Episode 8
Cloud Security Today
Innovating at the Speed of Relevance
Show Notes Transcript

When thinking of innovation, the first things that usually come to mind are tech startups. It’s not often you think of examples from the US Government or, more specifically, the Department of Defense. Our guest today has unprecedented insight, not only into what it takes to build a startup but how to create a startup-like culture in massive organizations like the US Department of Defense.

Nic Chaillan, has had tremendous success as an entrepreneur and, in 2016, decided to pursue public service when he took a job with the US government. Over the past 20 years, Nic has built hundreds of products that were sold to dozens of Fortune 500 companies. After taking a break from entrepreneurship, Nicolas served as the Chief Software Officer for the US Air Force and Space Force and introduced game-changing innovations to the government’s software operations.

In our conversation with Nic, we discuss agile practices and how he used DevSecOps to elevate the Department of Defense’s software security. We unpack how his experience as an entrepreneur motivated him and why it was a commonsense decision to apply those lessons when he started in government.

Tweetables:
“When you look at the desired outcomes, you realize pretty quickly that DevSecOps is the main enabler to get all of these things done fast while not creating more risk. In fact, I would argue, it reduces both cyber and operational testing risk as well.” — @NicolasChaillan [0:06:30]

“That’s also something to think about: what kind of access control do you want to have in place when it comes to these kinds of tools and how do you mitigate the blast radius?” — @NicolasChaillan [0:16:39]

“I am also a big believer that education and continuous learning has to drastically change and improve.” — @NicolasChaillan [0:33:59]

Nicolas M. Chaillan on LinkedIn


**NOTE: Generated via ML. Expect crazy stuff to be translated that may have never actually been said by the host or guest :-) ***

[0:00:34.6] MC: One of the things that I often think about when innovation comes to mind are tech startups, the usual suspects, the Googles, the Facebooks, the Netflix’s. I don’t often think of the US Government or specifically the Department of Defense. Today’s guest is Nick Chaillan. He is the former chief software officer of the United States Air Force. This is just a really interesting interview and as you’ll hear, Nick has a background in startups, creating up his own companies and what he talks about and you’ll hear this over the next couple of minutes is how he uses Agile development practices and DevSecOps to bring innovation and how he was able to do that successfully.


I hope you enjoy today’s episode.


[INTERVIEW]


[0:01:26.1] MC: Thank you for joining us on the podcast today.


[0:01:28.0] NC: Yeah, thanks for having me.


[0:01:29.2] MC: Before we jump in, tell us a little bit about your current role and then we’ll delve a little bit more into some other areas as well.


[0:01:38.6] NC: Yes, I was the – I guess, the first chief software officer for the Air Force and Space Force. We created this office to remove impediments to the adoption of DevSecOps and agile and really build enterprise service around DevSecOps so we can move at the pace of relevance and really adopt the best of breed DevSecOps practices with Kubernetes and containers and service meshes and all the good stuff.


[0:02:01.4] MC: You have a really interesting background, right? You are not the typical govvy who has spent 20, 30 years with the Department of Defense or even with some other area of government. I mean, if we look at your LinkedIn profile, you are an entrepreneur at heart. You’ve started multiple businesses and are very successful.


I guess, my question is, I know that you’ve recently made a decision to leave public service but rather than focus on why you left, I’m curious, what interested you as an entrepreneur in getting into public service first at DHS and then later, in the US Air Force.


[0:02:39.8] NC: No, absolutely. I guess it’s a very surprising story. I’m a little disappointed or sad that you use the past tense to describe me as an entrepreneur.


[0:02:49.0] MC: Well, you’re still an entrepreneur. Usually, the two don’t go together.


[0:02:51.5] NC: That tells you a lot. I know, I’m just kidding. It’s true in a way, right? That’s also what is scaring me is when you become still and behind. I think it’s important to have this rotation of talent and what led me to really join to the parliament first at DHS and then the DOD was after I sold one of my companies, it was a time where about five years ago, when the terrorist attacks were happening all over, including in Paris where I’m from.


Although, I was born in [Mose 0:03:21.6] but I guess France is where I’m from. I think I wanted to make a difference and not do another stupid mobile application again. I started DHS, I was the chief architect and special advisor for cyber security and kind of pushed zero trust at the time, which was a little bit too early for the government, although now, as you can see, the president is pushing all the government agency to jump on the zero trust wagon.


I guess I was only five year too early. Then you know, I got a call to say, “Hey, how about you come and help us with zero transformation and DevSecOps in DOD” and that’s where I studied first at OSD, the Office of the Secretary of Defense and the acquisitions, the statement team and then, because of the success of the DOD enterprise DevSecOps initiative, we created a new office, the chief software office inside of the Air Force and that’s where they move me as the first chief software officer.


[0:04:16.0] MC: Prior to going on with US Air Force and DHS. What was your involvement with DevOps and DevSecOps, what was that like before?


[0:04:24.7] NC: Yeah, I guess I’ve been, of course, using all the common sent Agile practices for the last 22 years then you’ve maybe at the very beginning also of the adoption of DevOps and then DevSecOps for my own companies, right? I was really focused on building innovation and rapid transition to exit and so I had 180 products I built over the last 20 years that were sold to dozens of Fortune 500 or 100 and that led to very fast pace.


You realize pretty quickly that to bring to life a quality product and baked-in security and testing, you need to adopt the principle of Agile of course and DevOps and DevSecOps to have that baked in security. I guess my own experience as an entrepreneur is what really pushed me to implement those concepts and of course it was common sense to bring them with me when we started to do innovation in the government.


[0:05:22.7] MC: Why did you decide to focus on DevSecOps? I’d imagine there was probably a lot of other areas you could have focused on that probably would have been easier. Why DevSecOps, why did you start there?


[0:05:37.5] NC: Well, I think it’s a biggest return on investment, right? You have so many facets of the benefits of using DevSecOps. First is the ability to compete and move at a pace of relevance with automation of testing and security checks but also, injecting that baked in security so we can reuse containers and Lego blocks across teams. Really, when you start, you take a step back and you look at the impediments that teams are facing today when it comes to the adoption of DevSecOps and the ability to compete against other nations. 


It’s really driven by the issues around accreditation with ATO, authority to operate but also with the ability to have a fast feedback loop between the war fighter and the development teams so you’re not building things in vacuums and so really, at the end of the day, when you look at the desired outcomes, you realize pretty quickly that DevSecOps is the main enabler to get all of these things done fast while not creating more risk. In fact I would argue, it reduces both cyber and operational testing risk as well.


[0:06:52.4] MC: Anytime you try to bring something as, I’ll call it revolutionary as DevSecOps into a large organization, be it public sector or private sector, there’s always going to be some type of resistance, right? Just because it’s new, maybe they don’t – they’re not aware of it but a lot of the folks listening to the podcast are probably going to be mostly private sector and they’re trying to do the same thing that you did in a massive organization. Where would you recommend they start? What are one or two things that you just found obviously, you know, nothing – no projects every 100% perfect but what are maybe one or two areas that they can start to focus on just to start to get that momentum and in the organization?


[0:07:37.7] NC: Yeah, what’s interesting is, I guess if we can do it in the idea, which is really the largest organization on the planet, you can probably do it anywhere else, that’s good news for people trying to do this themselves. That’s the first thing is don’t’ let people tell you that you can’t do it, that’s always a good first step. The second big advice is really investing, streamlining the adoption of enterprise services. When we started with DevSecOps in DOD, we created two offices, right? The cloud one and platform one team. 


Could one is our call office and platform one is a DevSecOps platform that can run on any cloud on premise of the engine on weapon systems, base systems and so on. Really, that was a massive enabler to ensure that each team is not reinventing the wheel. When you have a limited set of talents and you do, regardless if you’re a big company or not, these concepts are still very fresh and new and so by definition, you’re not going to see a lot of your technical talents even know what a survey smash is.


In which case, you want to obviously be efficient. You don’t want to create a one size fits all in a bottleneck because that’s where you fail as well but they are days away to create a platform capability that brings diversity of options while ensuring that the right cyber stack is in place at the right onboarding and common services are defined. 


There are many things where you want to have options, maybe dozens of options, we have over 23 at the bases on platform one but then you have all the things like zero trust where you want to have one implementation of a police enforcement point and then probably a single eye cam single sign on stack so you don’t have issues in terms of authentication of person entity and nonperson entities as well. When you start looking at things, you need to find the right balance between too many options, not enough, one to single mandated capability, which sometimes you have to have the will to push because people are always against any kind of mandates.


At the end of the day when it comes to cyber, when it comes to different capability that need to be enforced across the enterprise, that’s the most efficient way to get there. We keep talking about federation or compatibility or ability to integrate between different products, it is just never the same when you have options just for the sake of egos.


I think it’s also important to define why do you need it? Is it just for personal preference or is it really because of a mission need or gap that you cannot solve with something else and by moving and adopting Kubernetes and containers, what’s also very important is the fact that everything becomes modular and Lego blocks.


Even if a team does not like a piece of the puzzle, it’s fairly simple to replace that one piece and design a customized implementation of that platform in a streamline fashion while enabling the customization. What’s also important to realize is that one size fits all obviously is terrible. You don’t want to start pushing the wrong mandates. You need to try and see what sticks but you want to be agile and move fast and learn fast and don’t fall twice for the same reason as well.


[0:10:43.1] MC: How did you find that balance between obviously like you said, there’s certain things in cyber security that they have to mandate but the same time, you want to be careful what you’re mandating, right? How did you attempt to find that balance between mandate, versus, let’s give the teams the flexibility they need to be able to execute their mission? Did you have a framework for that? How did you approach that? 


[0:11:08.0] NC: Well, I think you look at the customer demand and then you start comparing the desired options, if they are pretty similar and they don’t really bring different values, that’s one thing to take into account. The second piece also that’s very important to me is okay, when it comes to cyber security and the ease of consumptions of the service, if you look at things like single sign on, why would you want to have two single sign on stack, it just makes no sense.


There are common sense things when it comes to centralized logging in telemetry when it comes to zero trust police the enforcement point where even if you think in terms of the technology today, you’re not really able to federate truly a police enforcement point. You have a technical barrier there that if you let people implement their own zero trust stack in a vacuum, you’re going to have effectively as a cohesive outcome, a stack that is not a zero trust stack because by the finish, you’re going to need to trust other PEPs without ability to truly understand what’s going on.


There are things that you want to have centrally pushed and you just common sense. When it comes to different tools, Jenkins versus GitLab CI or whatever, right? Often, you have feature gaps and it’s fine to bring options, what I also realize is at first, I wanted to bring many options but then I realized, wait a minute, when you start improving in maturity, you need to start doing more things with those tools.


For example, we started to do multiparty signing with tough and in Toto, each phase of the pipeline will get signed. Well, now, you integrate tightly into GitLab or into Jenkins. If you have to support two products now, you have to do it twice. Then we started to do the proper measuring of metrics with the door our metrics, meantime to recover, meantime to production. Now you tightly integrate with tools like Jira and GitLab, right? If you were to swap I guess between Jenkins and GitLab tomorrow, well, you have to redo all these integrations, right?


I set to realize, the more you bring options and the more mature you get to become, the more complex your stack get to amendments becomes as well. There is upon, where you have to say, if the reason for which you want to use Jenkins is only ego driven then that’s not good enough anymore, right? If it’s your personal preference.


At the same time also, you look at cyber findings, right? Jenkins as dependency at all seven, eight years old with dozens of CDs, I don’t know if they’re dated. Is that a risk you want to take? You want to look at the cyber posture of the products, you’re going to look at the features, the cost, the open-source community around it, is it open-source, is it a cut or is it one of those core software, right? Commercial Open-source software that effectively as a foundation of open-source but all the cool, or enterprise where you needed features like simul, single sign on and all back, and different things like that which are really common sense and really needed for any enterprise of any scale are now paid feature with close IP which is really a model I don’t like, right?


Because you’re pretending effectively to be an open-source company but you’re not, right? That’s also things to think about, right? Vendor lock in, technology debt, it’s a very complex equation when you take a step back and you look at all the different factors. It’s obviously very opinionated, two different persons will probably not make the same decisions as well.


[0:14:31.8] MC: I love what you said that I think you might be the first person I’ve heard that say that when you’re looking at really standardization of your tool chain, you have to look not just at the capabilities of the individual tools but you actually have to look at the security of those tools themselves and let that be part of the decision-making process.


That’s really consistent with what, you know, CNC have recently released a white paper on supply chain security. I think that’s absolutely consistent with that approach.


[0:15:03.1] NC: Yeah, you know what’s interesting is, you see a lot of very big Fortune 100 having tremendous tech debt, right? You look at Atlassian, 1,400 CVs on some of these eight to 12 years old dependencies, that’s just unacceptable today and then they wonder why they have critical CVs coming out again and again. You need to take care of your software bill of material, right? It’s the same thing also when it comes to the risk of CICD pipelines, right? 


The next big wave of cyber-attacks will be targeted against these capabilities because if you get into the pipelines, you can easily inject malicious code and if you look at what’s going on, even recently with solar winds. If you get into the build server, you can inject malicious code and bypass all of the checks of the CICD pipelines, that’s going to be the weak link. All these CICD tools, all these even scanning tools and keep in mind, you look at the recent CV of Atlassian, right?


Jenkins got compromised because of the plug in between Atlassian and Jenkins. Lateral movement of some of these tools because of all these nonperson entity keys, right? Robot keys between product A and product B and by the way, we’re making, we’re doing a very poor job of access control, particularly when it comes to NP, right? 

Where they effectively have a bloated rights to products and that gives the ability of malicious actors to, not only laterally move but get tremendous access to things all the way to sometimes even being able to commit back to get and making code changes just because they got into a CICD pipeline or GR confluence or whatever tool. That’s also something to think about is, what kind of access control do you want to have in place when it comes to these kinds of tools and how do you mitigate the blast radius, you’ve seen also recently with Azure, with the compromise of their Kubernetes capability where effectively, they were using the same shared key NP key to manage their clusters.


Even though you get a dedicated cluster per customer on the dedicated VM, there was an ability to effectively use the same secret to authenticate or talk and to authenticate across all the tenants. That’s another thing is, if you have a multi-tenant situation, you want to make sure your NP keys are created in a dedicated pertinent way so if a key is leaked into one of the tenants, that tenant or that hacker is not able to get into the other tenants as well.


[SPONSOR MESSAGE]


[0:17:28.4] MC: Prisma Cloud secures infrastructure, applications, data and entitlements across the world’s largest clouds, all from a single unified solution. With a combination of cloud service provider APIs and a unified agent framework, users gain unmatched visibility and protection and for our federal customers, Prisma Cloud is now fed ramp moderate. To find out more, go to prismacloud.io. 


[INTERVIEW CONTINUED]


[0:17:56.7] MC: You mentioned a couple of minutes ago when you were talking about some of the things that you built during your time at the United States Air Force. You mentioned Kubernetes. Kubernetes is obviously is a pivotal point of what you guys did. Tell me a little bit, what was it about Kubernetes specifically that got you so excited and had you worked with Kubernetes prior to US Air Force and DHS, what did that look like for you? 


[0:18:21.4] NC: Yes, so not before DHS because that was the beginning of Kubernetes but yeah, I guess although you do see job applications asking for 12 years’ experience in Kubernetes, so who knows, right? 


[0:18:32.6] MC: I’ve seen that. 


[0:18:33.9] NC: I don’t know if I have 12 years’ experience in something that didn’t exist 12 years ago, so that is one thing. You know, the reason why we picked Kubernetes is again, multifaceted, right? One is it’s a vibrant open source community. It is one of the cognitive computing foundation of course donated initially by Google. The beauty there is the abstraction layer, so you have the ability to abstract yourself from your cloud provider and storage and networking capability from a cloud standpoint, from my own premise standpoint. 


It gives you a lot of ability to run anywhere and that is really what’s so critical when it comes to particularly the DOD if you want to run software all the way from jets to bombers to space systems to clouds having that abstraction capability and layer to orchestrate and have a very high level of disaster recovery and high ability baked in and not just have virtual machines, right? That effectively a VM image has to be designed per cloud. 


That creates this bottleneck where in this case, the contender just run anywhere and so that changed the dynamics of reuse of codes and binaries running across the enterprise and so then you have these Lego blocks you can reuse. Not only that but then because these are vibrant commercial community around it, you have so many companies that can sell you a CNCF compliant Kubernetes capability. 


Whether it is a VM ware with TKG, open shift with Rancher or open shift with Red Eye with open shift, Rancher with Arcade 2 and K3S, so you know, convoy it from date to IQ, right? AKS, EKS from Amazon and Azure, all of these things effectively are commercial implementation of Kubernetes in different ways with sometimes some level of vendor lock in. You do have to pay attention to that and that’s why we mandate the use of only the CNCF compliant capabilities so we don’t get locked into a specific implementation. 


That gives you effectively the ability to orchestrate and be abstracted but also to get support and scale and commercial implementation at scale without having a major risk of getting locked into a single company or cloud provider. 


[0:20:41.6] MC: I’d pulled up some things that were public around just some of your accomplishments while at DOD and there is a lot, so I know obviously we don’t have time to go through all of them but maybe from your perspective, which of the accomplishments are you most proud of? Obviously things you can talk about publicly. I think there’s in the general civilian population, I think there is maybe not a lot of awareness of these things. I love to hear it from your perspective, what are you most proud of accomplishment wise? 


[0:21:09.5] NC: Well, I think some of the biggest success were the ability for us to open source all of the work we’ve done at platform one and all the Kubernetes and all the implementation of the platform and all the cyber stack and so that’s been now consumed by dozens of commercial organizations but also five nations, 12 federal agencies outside of DOD are using pieces of platform one. 


We also created the hardened content repository, a more secured docker hub called Iron Bank, which is also open to the world and anyone can consume the containers we hardened. We have 900 containers both commercial products and open source products, which really streamlined the adoption of open source and also non-traditional startups can now get access to DOD in a much more streamlined way. 


That was also exciting to see as well. I think you know, the ability for us to demonstrate, we could put Kubernetes and the service mesh on the jet, on F16, in the [ghazi 0:22:04.8] hardware that’s 40 years old and showed that that kind of thing is possible, be ready to fly the jet and be able to receive over the air updates and decouple the flight control capability from the AI machine learning more innovative side of the house. 


So we can effectively rapidly update the more innovative side of the jet and really get access to best of breed AI ML come to it’s learning capabilities and do that over the year while flying the jet. In 12 days, there is also a lot of things that demonstrate, you know, if we can do that sky is the limit, right? I think it kind of opens the door to showing that this stuff can be done in the government. 


Then finally, also we demonstrated that the government can run a successful enterprise service as long as it keeps not forgetting that this is very much like a company and that the customer is all the wall fighter and the DOD programs and now the Pentagon. 


[0:23:01.9] MC: That’s certainly impressive. I know when I first heard this I thought, “This is going to be talking about like theory.” This is theoretical but you guys actually did this. You are talking about jets that actually fly that are in war fighting operations, right? This is actually has happened.


[0:23:16.8] NC: Real, real flying things, yes. 


[0:23:19.1] MC: That is impressive. That’s really impressive. 


[0:23:22.2] NC: Space systems and so on, yeah. 


[0:23:24.7] MC: That’s amazing. I guess a question I have for you is you know, obviously your time at DOD, how would you like to see DOD approve the acquisition process to foster innovation because I think that is part of it, right? That acquisition life cycle. If you could have a magic wand and change that, what would be some of the things you would change in that acquisition process to really kind of continue some of the work that you did but also to just increase that pace of innovation for DOD? 


[0:23:55.0] NC: Well, I think we need to move away from the water Agile fall process, right? Right now, we think Agile but effectively, we have all the impediments of Waterfall and all the impediments of Agile for very little of the benefits because effectively, we still buy requirements stuck in time. We don’t buy capacity of work, we don’t buy skills with a very clear definition of done, so the model we’ve been pushing at platform one, you know, we have 275 people at platform one. 


The way we staffed the team effectively is by buying skills because we don’t just want to buy waste the time and making sure that those people do actual work. We have a definition of done in the contracts to say, “Hey, you need to deliver the code inside of the government finished DevSecOps environment.” It has to pass the pipelines and the tests and the scans. It has to meet the user story intent and the product owner has to approve that story, right? 


These is that every mechanism implemented so effectively instead of describing all of the technical requirements and outcomes in the contract, which ends up creating mass insurance every time we need to make a change in a contract because we all stuck with outdated contract requirements and so moving away from that and shifting into effectively capacity of work that you can groom your backlog just going through common sense Agile collaboration management tools and our contracting mechanisms. 


That streamlines the velocity of the teams and the ability to do much more with the money. We estimate at least up to maybe 400 percent more work being done and we’ve seen also just with DevSecOps the decrease of everyone’s cost by 40 percent, which is pretty significant as well. 


[0:25:38.7] MC: Sorry, I hear you are using a lot of what I would say, I hear a lot of business terms in there as well, which a lot of times don’t typically mix with either cyber security or software development, so that brings in my mind metrics, right? Which I think are always key for you have to have in order to judge in the success of any program. 


Specific to let’s break it maybe into two categories either DevOps and DevSecOps, are there – let’s go back again and let us not assume that everybody listening has got fully functioning DevOps, DevSecOps in their organization. Were there initial metrics that you look for to kind of judge the success of the program as it matured? What do those look like? I mean, what could you share around that? 


[0:26:24.5] NC: Yes, so of course it depends what you’re doing right? But in case of product, if you have a piece of hardware, the decoupling from the software to the hardware, the ability to release in production multiple times a day, a week, whatever your target is and tracking the velocity of delivery but also not just the velocity but also the quantity of the delivery, so meantime to recovery, defects and the ability to recover fast. 


Fail fast but don’t fail twice for the same reason, loan fast, right? Reducing the impact, you know, people say, “We can’t fail in the Air Force because we have jets and bombers and nuclear weapons” but it all depends on what you mean by failing, right? When we talk small incremental delivery of capability, we never get to the point where you’re going to fail in a way that is catastrophic, right? 


You need to decouple and cut your software into modular architectures and then you can effectively update pieces without disrupting the critical flight control and air willingness of the aircraft. So we have many things to do to mitigate that, so we use it. There are metrics. There are raise the meantime to production we time to recovery all of these and then I think some of the very interesting metrics that people that do automative or a bit of system. 


IOT devices or whatever it is, the ability to do how to interloop testing so you can test the software and the hardware. If you look at Space X, right? They have 200 developers that you compare that to 4,000 at F35, yet Space X does 17,000 build of software a day. F35 doesn’t do that. Space X has kind of dated the software the day before the launch off when it takes years for software to be updated on the jet at least before, right? 


When you look at the number of defects, it is also drastic. When you start comparing also the reuse of code, you know there is 80% of the code base we use across the nine platforms of Space X where F22 and F35 only share 4% of the code base, right? Again, you’re in a situation where you don’t have any reuse. It is not a modular, it is a monolithic system, which create a lot of issues to update it. 


It is improving and the F35 team has done drastic work in the last two years to improve that and it is getting to become much better but some of the metrics will be around in the meantime to production, how to end up testing and your capability to test your software to do rigorous testing and making sure you’re not breaking things on the hardware and the ability to update the software a day before the launch like Space X, right? 


Where often space systems in the Air Force have in space force I guess now have a two months freeze before launch, right? Where we end up actually being in a more precarious situation because effectively Space X has fixed the issues that went out allowing to be installed because we’re in a freeze period where that commercial launches have already addressed and so you’re actually creating more risk thinking you’re more secure. 


That is why it is always interesting, right? The balance between security compliance and velocity, they are all competing things but at the same time, sometimes you make a decision thinking you are going to increase security and you end up decreasing it because you didn’t think of the outcomes. In this case, the perfect example of the 60-day freeze that we’ve removed actually because we’re creating more risk than we were solving. 


[0:29:46.0] MC: I guess when you – I can imagine how that conversation went the first time when you said, “Hey, let’s remove this code freeze that had probably been there for I’m going to say decades, what does – how do you measure, right? Because at the end of the day, I’ve always been a big fan of, “Look, you can bring an innovative new idea and people may look at you crazy but at the end of the day, if you can show metrics that this works that eventually you will win them over.” 


You may not be able to do everything day one but if you break it into small bits, you can do that. How did you do that? Because I can imagine again, we’re going to have many of our listeners that are thinking, “I want to do all of these things that Nick did in DOD and my company is probably is a fraction of the size of DOD.” How do you start to gain that mindshare around wanting to do things like that? 


[0:30:35.5] NC: Well first, you don’t listen to people that tell you not to do it, right? Because if I had listen to most of the people and most of the achievements I have done, people told me I was wasting my time and not sure they even bother, right? Don’t listen to those people because effectively, you are not going to do anything if you don’t even try and you need to try and believe that you are going to succeed. 


If you already try in a half-baked way and already thinking you’re going to fail, you might as well not try, right? You need to try to be all in and come up with data and I think for us, why we were able to convince people is unfortunately, we would probably not have been able to do that if we were just the first one to try it. In this case, by showing the Space X data, we’re able to show that it made sense and that effectively the risk was increased by freezing the code base competitive commercial launches. 


To us very clear, we could have compared the data and show the number of defects, the number of issues, pending issues and bugs that were already addressed in near releases that were not effectively addressed because of the freeze on the space force side. Those metrics and data points were exactly what we needed to convince people but you’re facing a different issue when you are the first one to try something. 


That was easy for us to be second one effectively and that is why people like Elon Musk are leading the pack, right? They are willing to take the risk and measure the risk and if you don’t take risk, you’re going to get behind. You are not going to be able to innovate and you’re not going to move fast enough. You look at the velocity of Space X compared to many others, they are miles ahead, right? 


That’s because of the measured risk they’re taking but at the same time, look at the launches they are doing with humans on board, they have no issues, right? I think it is important also to weight that risk and balance it. It is a tough thing to do but if you don’t try hard enough to innovate and do it in a fast-paced, an incremental pace, you’re not going to be able to even matter and I think what is even most scary to do even getting hacked or having an issue would be not to be a relevance tomorrow so that no one is even bothering hacking you. That would be pretty bad for everybody. 


[0:32:51.5] MC: What’s next for you? 


[0:32:53.0] NC: Well, you know I think I am going to take some time with the kids. I was lucky to sell 12 companies already at the end of the day for me, that’s really the luxury there. I have plenty of time and I’m going to probably join a few boards and try to help and try to provide advice. I am going to do a LinkedIn live every two weeks and try to make people laugh and share some interesting advice. 


I am even having this crazy idea of maybe doing some consulting where if companies are willing to do it live and make it public then I don’t charge a dime. Effectively, assuming companies are willing to share enough and without getting into the confidential stuff maybe too much but enough so that I can help them then I would be free. That could be interesting so we can help many other organizations as well. 


[0:33:41.1] MC: If listeners, if they want to connect with you, obviously I think you mentioned you’re going to do a LinkedIn live so obviously you’re on LinkedIn but what’s the best way for them to connect with you? 


[0:33:49.9] NC: Yeah, LinkedIn is definitely the best way and we’re going to do these events and we have a website there that I’m launching that’s going to have a lot of the content and created content. I am also really a big believer that education and continuous learning has to drastically change and improve and so we need to really work on how do we let people learn multiple times a day and we give an hour a day to people a platform who want to learn so we don’t get behind still and we can also catch up sometimes. 


I am going to try to really provide unbiased created content that I am not pushing a specific product versus another that really help people keep up with what is going on in the world. 


[0:34:32.1] MC: That’s great, I love it. Well Nick, thank you so much. It’s been really enlightening having you on the podcast and thank you so much for all the innovation you brought to the United States and the Department of Defense. Thank you. 


[0:34:43.7] NC: Yeah, thanks so much. Thanks for having me. 


[END OF INTERVIEW]