Disrupting for Impact with Preston Dunlap
Listen on iTunes, Spotify, or your favorite podcast app.
In this episode of Defense Unicorns, a podcast, Preston Dunlap takes you on the journey of being the former Air Force CTO and 1st Chief Architect. He goes into the value of people with authority providing support and top cover for those disrupting for impact and how to turn motivation into outcomes. He also tells listeners the importance of finding urgency without waiting for emergencies. Preston is the founder of Arkenstone Ventures, and you can follow his career and journey by following him on LinkedIn.
Defense Unicorns, a Podcast, is hosted by Robert Slaughter, Founder, and CEO of Defense Unicorns.
Guests this week include:
Preston Dunlap, former Air Force CTO, and 1st Chief Architect
Highlights from Defense Unicorns, a Podcast:
This interview has been lightly edited for length and clarity.
(0:16) What is CTO & Chief Architect
(3:09) Challenges of systems integrations.
(7:11) Is there Progress or Talking Points in Acquisition
(12:51) Motivation Into Outcomes
(20:18) What type of change would make the biggest impact?
(27:38) urgency within the department
(36:23) National Security Issues with current events
(41:54) Advice for Disruptors
(49:42) Advice to those with Authority
(53:43) Exciting things between DOD and technology
ROB: We’ve been working together for a number of years while I was still serving. One of the things that always confused me a little bit is the title of CTO in Chief Architect. I’d love to hear, in your own words, what those positions referred to and what sort of roles and responsibilities you had at the time.
PRESTON: Thanks for asking. It was quite an honor to be asked to come back to the Defense Department after a hiatus of a few years at the Johns Hopkins Applied Physics Lab. At the time, there was only one service that sort of brilliantly recognized that the department was basically scattering seed corn for science and technology activities. We had folks overseeing that, and then we had a whole slew of programs of record and acquisition programs, sort of like “silos of excellence,” as some folks would affectionately call them. Each of them got together, and they, I think, astutely realized that if you had a company, you would have somebody that was looking at the collection of products as a whole and the engineering and technology associated with those programs and products from inside that business.
Many titles could go along with that, but basically, they recognized one thing: the need for coherence across all the different programs. And second, to be able to think about the integration of those activities in the acquisition process. So that at the end of the day, you don’t just have a series of a thousand widgets coming off the proverbial conveyor belt; you actually have systems that are modular and upgradable. Then, as one might crazily sort of want, you actually get them to work together so that you can bring together a system of systems that work as our operators need them, which is actually how we use them in sort of day-to-day operations or conflict.
Being able to pull together the technology, the startup mindsets, and the industry experience into the way the Pentagon works to try to change that was essential to being able to be part of the acquisition apparatus because that’s where money flows. That’s where scale happens. That’s where programs become more real and get delivered. Having a foot in that was essential to being able to have actual influence and the opportunity to partner with all the great folks that are requiring, designing, building, and delivering systems for what was just one service.
And then, about a year into it, it became two services for both the Space Force and the Air Force.
ROB: When you talk about systems integration, can you talk a little bit about some of the challenges and some of the things that are going well or maybe not so well?
PRESTON: This is not too dissimilar to large corporations, but the government is the largest company, certainly in terms of human capital, on the planet. So the largest employer and, on a bad day, the largest bureaucracy. There you’ve got the challenges of scale, and that’s both a people challenge as well as a product and how you build challenge, and what the system or the approach to acquisition and developing requirements tends to do, in some sense by design, is to basically remove any type of dependency on another program or another office. That, in its time, has good reasons. The idea is that you don’t want to hold up your schedule waiting on someone else’s or multiply risks from one product to another.
That sort of isolation basically created the incentives so that whenever we decided we needed to go buy a new plane or a new munition or a new software system, we thought of those as a department by design and effectively as an individual island of itself. It would have its own requirements, its own schedule, its own vendor or vendors, and its own metrics for the whole delivering and developing of the program itself as a thing. Then the incentives were applied to program managers and engineers and to the oversight organizations, from Congress to the White House to the Secretary of Defense’s office. All those pressures are there to basically deliver on time and on schedule.
Those are good ambitions and a good end state. But what happens is that the tendency is to basically remove any risks associated with allowing, say, that munition to talk to a different platform. You end up in states where, say, former and now-late Secretary Ash Carter would often tell me and others, “We’re buying platforms without bullets.” You know, we need to have munitions to go with our platforms and sufficient inventory and capability. So that mindset has largely been missing, with few exceptions or “lighthouses on the hill”, so to speak. What that means is that when we build something and design it, we need to think of it as an ecosystem.
That tends to go against the grain of the natural processes — the training that we put our folks through is, in fact, exactly how we operate, right? We don’t just fly planes without munitions. We don’t have maintainers that don’t have platforms with them. We don’t have aircraft carriers without planes and sensors. It all goes together. So it makes sense that we should actually have people thinking about how to not only deliver excellent warfighting capabilities but also how those systems come together to achieve the intended effect, as a family would.
Coming back to the department, the last three years, at a service level as opposed to the Secretary of Defense level, provided the opportunity to work with like-minded folks and find brilliant people that were out there ready to actually think differently about acquisition and technology integration. Where do we get it from, and how do we pull together both commercial and traditional sources into not just great individual programs but actually thinking of a collective whole — a collective Air Force, a collective Space Force, a collective Department of the Air Force, a collective joint force, and so on.
ROB: Can you talk a little bit about the progress that’s been made? Do you think things are heading in the right direction? Do you think it’s moving fast enough? It sounds obviously very promising, but one of the first thoughts that come to mind is the difference between the talking points and what’s actually getting executed.
PRESTON: Yeah, Rob, it’s a great observation. The question is how much of our speeches or visionary statements are coming to fruition and at what scale, speed, and pace. And that’s a good question to ask, and I don’t think we should ever stop asking that question.
I don’t know if it was fear or inhibition of being able to integrate and apply capabilities, technology, and products that exist for things like commercial applications that was an inhibitor to that speed and agility. This is a common talking point now, but say, in 2014 or 2015, this was a new idea. Various secretaries, like Ash Carter, pushed this in a big way to try to instill it inside the Department of Defense and the intelligence community as well. But one obvious thing is trying to figure out how to integrate and adapt technologies that exist either in another part of the government or in the commercial sector where something is serving an excellent purpose that could be transferred or maybe slightly modified to be able to be used in a national security setting to be able to design acquisition programs or requirements to absorb that in other cases; it doesn’t make sense to be able to do that. There are things like munitions and others that don’t have broad commercial applications, thank goodness. So you need to be able to think about how to design and develop those in an agile way, both from a software and a hardware perspective. So there’s a variety of strategies that have been proven both successful and where you should watch out to make sure there are no warning signs.
However, we’re not near the speed and pace that we should be in developing and integrating modern technologies. And that’s a concern because, number one, we’re losing out on tech and products that are available across the globe because we have limitations, concerns, or risks associated with integrating them. The speed is way too slow. That’s sort of our problem on the supply-side, ingestion side. It’s there; we just can’t integrate it; it’s right beyond our grasp; you just can’t touch it and pull it in. On the other side, in the more competitive landscape, you can look out and see China, which is sort of the standard example of a country that has a different approach to things. That’s not an approach that we would want, but they’ve also shown the ability to push and deliver technologies very quickly.
So you’ve got an outside that is moving quickly, building technology in a rapid way, and expanding in a bunch of different directions, both physically and from a tech perspective. And so we’ve got this opportunity loss from not being able to integrate what’s literally right here on our shore and risk of competitors or potential competitors growing overseas, developing technologies that would put us and our allies and partners at risk. I think removing that pence from both the inside and outside creates sufficient desire and momentum to be able to push the boundaries, deliver, and motivate. I think it does so in a big way. That’s why you hear people talking that way. That’s why a lot of the forces are communicating that way. But what happens is that that sort of vision, desire, motivation, and energy gets hit by the wall of the way things have been done, the way procedures have been incentivized, the way we’ve been trained, or the risks that could be posed. If things don’t go perfectly, what happens to the people or the programs? What happens to the money? There are all these incentives that push against a true and genuine desire to move quickly, adapt, and deliver technologies.
I believe we are in a good place in terms of the idea, the concept, and the vision. I think both in Congress, and in this and previous White Houses, as well as in the Department of Intelligence community, the rubber meets the road. Just like in a startup or a business, it’s all about execution and finding everything from A to Z. You’ve got to be able to then take that vision and translate it into policies, procedures, execution, and delivered programs that not only work well themselves but also integrate together. That’s the secret sauce. So, when you get a team together — you get programs together, leadership together, executors together, builders together, and users together — it’s not surprising that great things happen. It’s just really hard for a massive institution to do it, and that’s no excuse. So long way of saying, Rob, I think we’ve got to move, move faster, more quickly. We can do it smartly, but we shouldn’t do it foolishly. That’s just essential, and it’s just an opportunity lost if we don’t.
Every time I see things like that happen, I just get excited that people are taking the mantle from those of us that have gone before and are continuing to not only deliver but also move to deliver at scale. That’s so essential, not simply in software, although we talk a lot about that, but it’s also a revolution in hardware as well.
ROB: So clearly, the motivation is there, both from external factors as well as internally within the Department of Defense; a lot of passionate, motivated people really create that change. How do you turn motivation into outcomes, though? What do you think specifically are the steps for success that you think, in general, the DOD has been missing?
PRESTON: When it comes to getting from A to Z or from a vision and desire to reality, there are so many people, programs, and businesses that, frankly, trip up along the way. I mean, that’s why the common adage is that you can have a great idea as a startup, an early founder, or an early company. But execution is the secret sauce. or if you’re building hardware, it’s not just that designer prototype; it’s the execution at scale and the manufacturability of the programs. That’s where things make a difference at scale. And so, to not be too enamored with one side or the other of that equation, but to be able to get all the way through the process, it is essential to have something like a strong commercial sort of play, a strong defense, and intelligence play, or a broader national security type of play.
So how do you do it well? There are easier-to-touch metrics in the private sector, things like revenue and the valuation of companies — a more quantifiable approach. You can find some of those, although we tend to report out and get asked about input metrics. It’s not obvious that those input metrics are directly related to the output results. In some cases, those are there for excellent reasons. In other cases, they’re there because a program had a serious issue that shouldn’t have happened. So rules or procedures were in place to do it.
But I think that there’s a better way: if we could work as a community, from the builders outside the department to the buyers inside the department and the overseers and Congress on the hill, we could actually transition to thinking about measuring performance on outputs. You’ve got a different set of incentive structures. It’s not just, “Am I doing the checklist?” for whatever program or acquisition, or “Am I building the artifacts?” but “Am I delivering?”. For things like software, we’ve seen where that actually can play out, where people can tangibly see code being not just developed but delivered into production and used. Software is sort of attuned to that.
What hasn’t happened as much is revolution. We have tried to push this and will continue to do so on things like open architecture, digital engineering, and standards. But in some sense, you should be able to see that either sub-components or portions of hardware can also be thought of as modularly built. And if you do that, you sort of have a moral equivalent to software modularity and deployment. So, by thinking of building hardware in an agile fashion, you can begin to have time and space where you can actually begin to see the output of the development of hardware and not just software. This shift from input to output is just a really powerful tool to be able to incentivize delivery.
Now, I’ll just say that’s motivational and explain why I think it works. The challenge is that you have to have not only the right motivation but also pull together a team of people who understand what the technology, the components, and the products need to be. In other words, not just how to construct a contract but actually how to build a thing — a product that meets users' interests, needs, and requirements. Then you have to have operators that are able to interact with that. In the government, we tend to train our folks more for the checklists and contract actions of program management. We need that, but we also need to push harder on getting in-depth and understanding the technology and the product space because you need that to be really good buyers and really good partners with industry and operators so that you’re all in this together to develop. It takes those budgetary requirements, contracting, acquisition builders, and operator partnerships to actually make this magic happen, where you can actually deliver quickly, use it, and build as you go. Those are just some of the things that I would say that we need to do to be able to make this sort of future a reality, and you can see pockets where it happens. The secret sauce is not dissimilar. That’s a future that I think we still have to go towards. It’s one that I saw firsthand and helped push in the three-ish years that I was back in the department, and I’m so excited to see people sort of carry that torch on.
ROB: If you could make a change or two, something concrete, to change the entire department, what type of change in policy, law, or practice do you think would have the biggest impact?
PRESTON: Rob, that’s a great question again, and I’d certainly be interested in your thoughts as well since you’ve got this great perspective from living it, building it, and delivering it certainly in the software space. Let me take a stab at it, and I will certainly be appreciative of any thoughts you want to offer on the subject too.
You could take a few different angles. One is a cultural one. I don’t think you can mandate or write an instruction to say that if you’re in the space of developing, delivering, requiring funding, and acquiring a product, you should actually wake up every morning passionate about delivering it and fight as hard as you and the team can go deliver it. We don’t always incentivize that. We have people that want to do that, but they are not supported or enabled. The most impactful thing would be moving to a culture where that’s something that is not only broadly encouraged but practically encouraged as well. Both in terms of time and dedication and fundamentally as an expectation.
When I first arrived three-ish years ago, I did a tour of all the units across the globe and across the country that were doing acquisition. I by no means talked to everybody; however, in the sample size that I did talk to, I don’t think I came across anyone who had directly had conversations with their end-user or operational customers. The moat, or distance, between the user and the person trying to acquire it — and even the person writing the requirements — was large in both time and space. And so number one would be a culture of building products, not programs. Number two would be shortening the distances between the key stakeholders and that product that’s being built: the users, the builders, the requirers, and the acquirers, and pushing them together right at the beginning and keeping them together as they do that. Three would be where you can think of buying a portfolio of systems or a family of systems to be able to achieve that operational end state. We should be thinking about acquiring and developing portfolios or families of systems. We’ve done this in small portions and pockets. This is something that some people will often say and think of as a budgetary trick to get a pool of resources that can be moved from one project to another, and oversight is difficult. That’s not all, although I could see how that could be helpful. What I really mean is that you’ve got an integrated team where they’re not all behind various walls, not talking to each other or working together, so you end up having every single program needing to solve every edge case for that problem.
You could actually do it better and more effectively if you had a collection of capabilities. That portfolio product approach or portfolio acquisition approach isn’t simply a budget thing. This is really a product approach to being able to do that. So you have to consider the ecosystem, and we don’t really consider, plan for, or drive ourselves toward the portfolio ecosystem. So we may organize on an org chart, and it looks like that from a Privacy Impact Assessment (PIA) management perspective, but we’ve gotta really push ourselves to actually go beyond the administrative collection of programs into the development and delivery of programs.
That’s not just on the government side. If you’re in a large profit-and-loss organization, the tendency is going to be there too. If you’re a commercially facing organization, seeing and harnessing the power of transforming your P&L or your business into an ecosystem of capabilities that reinforce each other and integrate with other systems is just so powerful to be able to unlock the potential. That means you can move away from singular and proprietary approaches to revenue-generating opportunities and toward those that have a larger pie to go after because you can interlock and work with others.
ROB: Talk a little bit to the audience about the sense of urgency within the department. Do you think there’s a point in the future where we’ve waited too long to change and can no longer hit the pace that’s required?
Preston: Urgency is so key. If we’ve hit that point where it’s just too late, we’re probably not doing a Defense Unicorns podcast. This is not a good world to be in; that’s a bad day, and we’ve got lots of problems. Until then, we have to figure this out and try to effect change and scale quickly. That in and of itself is sufficient in my mind to think about driving the urgency. I talked about the lost opportunities where we can touch something but can’t use it, and the overseas side, where we have potential adversaries that are building capabilities that can contest, congest, or make our operations difficult. Those two things should be sufficient to motivate urgency. But those aren’t necessarily the things that we wake up to in the inbox, drilling us in the morning; it’s something else, or it’s an administrative matter, or it’s part of the input metrics that are at the top of the inbox to go execute during the day.
Aside from a national crisis moment where you can focus and achieve urgency through that focus, it’s very hard to do. You end up getting these pockets of urgency and opportunities to be able to take effect. That crisis of urgency creates opportunities to be creative and break down barriers for people to be able to see the problems in front of them and recognize that we need to actually go through that to be able to not only continue to work but to be able to enable our people to do what they need to do. What creative opportunities and urgency are out there from a real-world operational perspective that could drive things like advancing sensors, integrating data networks and observation, or being able to address and deal with a different class of challenges? Those are questions that people in the department are grappling with. That clear-eyed view of a real problem and a real challenge, and then driving to deliver it, has come to a focus like the point of a pin. A point in an era where everybody’s aiming in the same direction is essential.
The other approach that I came to the department recognizing is that you don’t always have an unfortunate real-world activity to drive that creativity and to work through molasses-like procedures and processes and try to make things better. You can do it program by program, acquisition by acquisition, or intelligence unit by intelligence unit. One of the things that I thought of was organizing, training, and equipping. It was basically not just bringing Silicon Valley speed into the department but also driving urgency for execution. And you could do that in a variety of ways.
I did it through a series of time-driven exercises led by the operational community that required a whole bunch of platforms and systems, some existing and some new to the community, with massively difficult objectives to achieve. Very short timelines — weeks to build or maybe a couple months to deliver — where the whole “classified” world is watching. There’s this immense sense of urgency to deliver something that is useful because the operators are driving it. Using that approach to being able to not give exact pinpoint answers to problems but to shake the system and be able to deliver and design, and waking up to the fact that we can actually do this here in the broader defense department and in the intelligence community, we’re literally doing it, and everybody’s aiming towards it. That was a tectonic shift in the way the department’s been thinking, and the ripple effects continue in a positive way. These ripple effects are continuing, and it’s encouraging to be able to see them.
We should watch them, encourage them, and enable them to continue to happen. Not just ones and twosies, but we need to do this in an exponential sense. Urgency is essential; it can be driven by a real-world operational focus of it’s here, and it’s pressing, and we have to address it, an operational future-where things actually happen in the world, where we need to be able to stabilize and be able to support our allies and partners. Then three: opportunities to be able to drive that sense of urgency through activities and procedures that could push not only operators and acquisition professionals together but also the community of developers.
As you can tell, I’m pretty passionate about the need for urgency. I think there’s a good number of folks that have it in the department. They’re often not the ones enabled to actually go execute and deliver. It brings us back to bridging the gap and shortening the distance between those people to get the job done.
ROB: This podcast is focused on innovative and passionate people centered on national security. A lot of those folks that are listening are a little bit on the junior to mid-career level. What advice do you have for the contractor, civilian active duty, enlisted, and officers who are trying to disrupt the system and, in many cases, trying to achieve an outcome in the direction upon which you talked about on this podcast? Those trying to achieve that mission impact but struggling with the day-to-day bureaucracy, what advice do you have for those folks?
PRESTON: First of all, I came across so many in those categories who saw the vision either themselves (almost in all cases) or heard from the top leaders talking about it and encouraging it. I was overwhelmed with the potential and excited by the possibility that even a quarter of those folks would actually come through and push through the potential of those ideas. It’s a different world. You’ve identified a real risk, which is that it’s no easy path to be a disruptor, an innovator, or an urgent deliverer inside a fairly arcane organization — the largest bureaucracy on the planet. So point one would be: Keep going; don’t stop. Point two would be: It’s going to be painful; recognize that upfront, and don’t be discouraged by it. It may or may not get easier, but go into it with your eyes wide open and with the tenacity that it takes to actually achieve something new. Number three is that it’s not necessarily inside the government versus outside. Any game-changing, innovative, forward-thinking individuals that see the world differently than others are going to push to create it and are going to face headwinds. The fourth thing I would say is that if you are in this apparatus that we’re talking about, in the national security-focused area, I would encourage you to be professional and respect the organizations you’re in. You can find folks that are out there that could be champions and meet them, and they won’t always have the bandwidth to be able to help guide, give advice, or maybe even directly support or enable you, but don’t be shy about doing it again in a professional way.
I think one of the things that I saw on this point was folks being concerned about talking to a superior or somebody in a different chain of command. There are good reasons why that is the case, but in the innovation space, if you do it appropriately, it is one of the most helpful opportunities because different people have different perspectives. It’s not the most senior person, it might actually be a more junior person that sees it, but they’re positioned appropriately to be able to take effect, order, and appreciate the problem that you’re seeing and perhaps help overcome whatever the barriers are to being able to achieve that. Raise the issue, ask for help, and build partnerships. Be professional, but don’t be shy. It may or may not come to fruition, and you may have to figure out a different path to achieve it, but remember, you’ve got advocates that are around the ecosystem, all the services, and the Department of Defense. There is certainly a general sense of collaboration focused on innovation and delivering real products. You’re not going against the grain of the strategic conversation. It’s really, Rob, as you mentioned, going against the grain of the way things are done or the execution approach.
Whether you’re a four-star or a one-star, enlisted, a junior officer, or part of the contractor innovation team, it can be a tough slog, but you have to see the vision and encourage others to move towards it. I hope to see more advocates out there at the senior and mid-level enable and empower folks to do that. I’m seeing a good trend, but I’d like to see the curve grow exponentially rather than linearly.
ROB: What advice do you have for those people who are already in that leadership role?
PRESTON: If you have some sense of authority, stop relitigating the same questions every day and free up that time, focus, and energy for delivery and not further deliberation, which is often in your power to do for the circle of authority that you’ve been granted. You can usually use that influence to influence other circles of influence, either above, adjacent, or certainly below. Be bold about how to do it. If you find yourself or others thinking, “That’s not the way we usually do it,” or “I’m concerned that somebody will raise a flag if we do it this way”, or “That’ll just delay us”, you might be right, but you gotta ask your question: is it worth going lower? Is it worth doing less for greater assurance of procedural success? Or do we take the procedural risk, so to speak, or the institutional risk to achieve something that not only is great but is essential for us to be able to deter defeat if necessary? And with that sense of urgency, I think it drives — certainly for me — a different calculus for those decisions.
You make decisions every day, maybe even every hour, on certain things. And that mentality shift, that sort of wartime mentality, even if we’re not in war, is what you’ve got to have to go do it, whether you’re at a low, mid, or high level. If you are in a position to simplify, enable, and encourage different thinking, you should do it if you can, and you’re going to have to communicate that. You’ve got to bring everybody along with you, so you can’t just sort of go rogue, but you can go bold. That’s what I encourage you to do: listen to those below you or adjacent to you, hear the problems or the opportunities, and apply a megaphone to those opportunities where you can. For the people’s sake, because it shows that you’re genuinely, authentically listening, but also for the country’s sake, because should we have to execute, we’ve gotta be able to do so and save people’s lives at the least possible risk. At the end of the day, that’s why you have a defense department and an intelligence community. We have the privilege and the opportunity in this acquisition, development requirements, and tech space to make a massive difference. You know, if we rise to the occasion.
Want to hear more? Tune in to the podcast episode, where we cover lots more.
You can also subscribe to Defense Unicorns, a Podcast on iTunes, Spotify, or your favorite podcast app.
Thanks,
The Defense Unicorns Team
