The 311 Podcast

S2:E8 Design at Scale with Savan Kong

• Savan Kong • Season 2 • Episode 8

Share episode

Transforming the Department of Defence with Savan Kong. 

Today my guest is Savan Kong. Savan has a unique resume and set of experiences. He was most recently the first ever Customer Experience Officer for the United States Department of Defense. One of the largest organizations of any kind in the world. 

When the CIO of the DOD tapped Savan to pioneer the new CXO role, Savan brought a design mindset to the job in every way. And in this episode, he's going to share his mindset and models for how to introduce design infrastructure into an organization as complex as the US DOD. I think you'll like his approach, and in the show notes, we'll be sure to spell out the model he lays out in the episode in great detail. Here's my conversation with Savan.
---

Guest information:
Savan Kong LinkedIn
---

Savan's Model
Savan highlighted that design is an intentional act of problem-solving. He applied these principles to explore how the CXO office within the Department of Defense could leverage policy and strategy to enhance customer experience.

While establishing the CXO office, Savan applied four key strategies in his model. Including specific steps in creating design infrastructure that embraces the problem solving nature of design thinking into the CXO infrastructure.

  1. Building Alliances: Identify key individuals to understand the organization and advance the CXO agenda.
  2. Identifying Leverage Points: Understand the organization's priorities, learn its culture, and identify key levers for initiative momentum.
  3. Defining Measurable Outcomes: Establish IT governance, update strategy for investment guidance, implement performance management (including OKRs), create a consistent intake structure for customer feedback, and build a user experience foundation.
  4. Developing a Robust Design Infrastructure: Ensure the infrastructure is 
    1. authoritative (vetted, signed off, and documented),
    2. sustained (funded, adopted, and continuously improved), and
    3. scaled (impacts many, is agnostic, and normalizes expectations).

Recorded in May, 2025

This is a show about the people that make digital public service work. If you'd like to find out more, visit northern.co/311-podcast/

We're going to keep having conversations like this. If you've got ideas of guests we should speak to, send us an email to the311@northern.co.

Northern LinkedIn

Paul:

This is The 311 Podcast and I'm your host, Paul Bellows. This is a show about the people that make digital work for the public service. If you'd like to find out more, visit northern.co today. My guest is Savan Kong. Savan has a unique resume and set of experiences. He was most recently the first ever Customer Experience Officer for the United States Department of Defense. One of the largest organizations of any kind in the world. The DOD is the largest budget segment in the US federal government, the largest employer in the nation, and a massive collection of sub entities each with their own leadership and mandate. Savan followed a path through the private sector, starting as the first employee of Redfin, now a$2 billion plus NASDAQ listed technology company with nearly 5,000 employees in the real estate space. Savan brought UX and design thinking to that thriving business to create a patented map-based search and advertising technology. He led consumer design at Amazon and held other executive roles in the private sector before jumping into the defense industry as a digital service expert at the Defense Digital Service. When the CIO of the DOD tapped Savan to pioneer the new CXO role, that was a lot of acronyms, Savan brought a design mindset to the job in every way. And in this episode, he's going to share his mindset and models for how to introduce design infrastructure into an organization as complex as the US DOD. I think you'll like his approach, and in the show notes, we'll be sure to spell out the model he lays out in the episode in great detail. Here's my conversation with Savan.

Savan Kong:

My name's Savan, not Savon. If I had to introduce myself in 30 seconds, I would say I am a customer experience thought leader. Most recently, running customer experience at the Department of Defense. But I've worked across the entire sort of spectrum of product and design and customer experience design across federal government and industry. Most recently, part of my job was to try to understand how we can influence better customer experience through policy and strategy in the Department of Defense. But there's a bunch of different ways that we can dive into of how we could potentially be doing that.

Paul:

There's sort of this myth that exists, and one place I wanna start our conversation is this myth that government is big and bureaucratic,

Savan Kong:

Mm-hmm.

Paul:

business is agile and strategy focused and moves fast. And it's funny. I don't know that, I believe that myth.

Savan Kong:

I don't either.

Paul:

Government is big, you know, and

Savan Kong:

Yep.

Paul:

there are bureaucracies within government,

Savan Kong:

Yep.

Paul:

But I'd love your thoughts as a customer, a designer focused on the customer, what have you seen as the main difference moving between private sector and public sector, in terms of the work you do and the readiness of the organization to embrace that work. What have you seen as the, the most noted differences between those two sides of the industry?

Savan Kong:

That's a great question, Paul. To maybe take a step back, and really sort of like try to understand what design is, and design thinking is. To me, design is really, an intentional act. An intentional act of creating something to solve a set of problems. Now, if we use that as a basis of understanding what design is, I think that the government and the Department of Defense has historically been a forward thinking organization that has done that. Right. Whether it's through the establishment of different agencies, whether it's through the adoption of different processes the act of designing has historically been done in the department for many years, many generations. Now, I think where the disconnect is, in industry, we have nomenclature in terms like human-centered design, service designers, user experience researchers that is not applicable in many ways in the Department of Defense. And in many ways that narrative of establishing those types of roles with those titles has hasn't been there until recently. And so I think where the differences are is really in how we're actually categorizing, these essential responsibilities of designers, product managers and then being able to use that same narrative and that same way of describing essentially the act of trying to solve these problems intentionally the same way so that you can have that one-to-one comparable between industry and federal government or the department.

Paul:

It occurs to me that we're starting to see title parity, role parity between what might

Savan Kong:

Yep.

Paul:

happen in say, a corporation And a government department, the idea that you had a customer experience title is really interesting in a government agency. Potentially it's the advent of the same technology, the same technology problems occurring in both. We're all doing this digitization work, trying to figure out

Savan Kong:

Yep.

Paul:

how we work through mediated interfaces, where we're eliminating desk service and phone service, and we have technology brokering the experience between an organization and a customer, its services. Suddenly we're seeing title parody and role parody showing up across both organizations.

Savan Kong:

Yeah.

Paul:

It could an interesting lens to take to that problem.

Savan Kong:

Yeah. In many ways there is a question that for people that have been in industry their whole lives, if they're trying to transition into government, there is a question of, how am I being represented or am I being represented? Let's just take a User Experience Researcher and that's what you've done for your whole life. Up until recently you couldn't even search for a job and find a User Experience Researcher in USA jobs just because there isn't that one-to-one comparable. And at times, if you're looking to make that shift you're gonna ask yourself the question of, do I belong here? And if I do belong here, how do I get represented in an organization like this? And, the funny thing was my first foray into government was that defense digital service. And we brought in some forward thinking people to try to infuse the best of industry into the department. What was funny was when I got there, my whole background was working in these agile development teams. We had product managers, designers, engineers, and when you say product or program or project manager, in the department, it actually means something very different than what it means in industry. And so to try to reconcile, okay, these people have these specific responsibilities, these people have these specific responsibilities and they're not the same thing is really challenging at times.'Cause when you're reaching out to people and you're like, oh, you're a program manager, what does that mean? And just to even have that clarity of conversation and communication is very hard, especially when you have these different universes you're coming from.

Paul:

And there are unique aspects to working in public sector too, we have politics, we sort have this public aspect of this belongs to the public and there are elected officials and you know,

Savan Kong:

Yep.

Paul:

the act of new releasing interfaces. We're changing a public service where that looks like policy, sort of the funny melding of policy and interface and product,

Savan Kong:

Mm-hmm.

Paul:

These things all kind of can wrap together. I wouldn't mind hearing some of your thoughts on just talking to the customer is harder in government,

Savan Kong:

mm-hmm.

Paul:

because that be seen as a political act too. You know, overall consulting.

Savan Kong:

Yep.

Paul:

are we consulting on policy or are we just simply trying to design a usable product? Those lines can get, could just get complicated. A lot of the legislation and the policy that existing government is to protect from political consultation under the guise. You know, like we wanna avoid political acts on the operational side. But that can put real constraints around what you can do in terms of just talking to customers.

Savan Kong:

Yep.

Paul:

I don't know what DOD what was that like? What was your ability just to access your customer, whether it's for research or testing or validation? What is that I.

Savan Kong:

Really challenging. I'd say it's probably the hardest thing about my job when I was there, is trying to identify, one, who those customers are based on what organization you're with. You look at an organization like the CIO. Ultimately our customers are the war fighter if you're in Department of Defense, right? That's sort of like what it boils down to. However, with that being said, there are different facets of that customer journey that different organizations are accountable for. Whether you're working in policy or you're working in acquisitions, or you're working in IT, you see different facets of what that customer journey looks like. The challenge that we had within CXO was trying to really identify who some of those key players are. And then the second piece of that was because we were so siloed and disjointed, there's very few times where we all actually got together as a department, a DOD, and then had conversations about, what are common things that we're seeing as pain points if you're in the Army or the Navy or the Air Force or Space Force or whatever? What does that look like and how do we as an organization, take into account some of the things that are our advantage, like we have a massive sort of investment in IT, we are looking at and working on some of the most critical projects that pertain to national security, and we also have an exceptionally high level of very talented people that understand how the department works. To be able to bring together those sort of disparate sources, those disparate customers, and then be able to have that conversation was, frankly, the first step that I took as CXO. How do we bridge this gap where we have a lot of people that have pockets of excellence, but at the same time, a lot of those conversations get lost in the shuffle because it's such a massive organization. That's a big challenge. And I would say, if I had to distill it, communication and understanding how to communicate effectively was probably the hardest part of my job. You had to be able to not just talk to your customers, which are people downrange in the front lines. But also you have to be able to take that, speak to, say, the Department of Defense, and then also then be able to parlay that back into another group like Congress or the public, and then be able to translate, a lot of the work that we're doing. That in and of itself is exceptionally hard to do, especially in a place that's as big as the DOD.

Paul:

What a radically complex set of stakeholders you would be managing there. It deeply reminds me of General Stanley McChrystal's book, Team of Teams, he sort of about, in the context of war, we have organizations that were built as silos because these are intelligence agencies. Not communicating is kind of the M.O.

Savan Kong:

Yep.

Paul:

for the US military in terms of, in his book it's the Iraq theater and what was happening in that context. But to say they were getting really circles run around them by insurgents

Savan Kong:

Mm-hmm.

Paul:

who could break down all silos of communication, who could be, a lean and agile. We're using software language there, but, you know, even just talks about the breaking the culture of communication down to, if we're not talking to each other, we're not solving the problems.

Savan Kong:

Yep.

Paul:

I would imagine that, that you were on a similar journey.

Savan Kong:

Yeah, there's definitely that fine line between sort of national security risks of communication, and I would maybe bucket that into a different set of information, that is purposely sort of quarantined, purposely siloed and versus something that is,you know; we talk a lot about interoperability when I was at department, and they still do, things need to work well together. You need to be able to see information in a timely way so that you can make intelligent actions,what to do next. And you need to be able to see it from as many different places as possible and then distill that information. And a lot of times, the principles of, what we're trying to do is still the same, even if the information may be a little bit different and hearing that consistently across the entire department was one of the things that actually was really surprised by, is understanding and listening to these themes that when we first got together, I thought we were gonna have a horrible meeting. I thought people were gonna be very gun shy about saying, Hey, this is really bad. Then it's happening here and I don't know how to fix it, or we're doing exceptionally well and it's making somebody else look really, really bad. And I was afraid we would shut down. But at the end of the day, bringing us all together into a safe, trusted place where we can have conversations and you can follow up the conversation with some action, let's just say, Hey, we're gonna put together this report. It's gonna be sent up to the Deputy Secretary. We're gonna then take in part, that information into the next budgeting cycle so that you can actually see investments being made in customer experience. That's where you can actually start to build a lot of momentum in this space. Because, you get feedback all the time, right? I get feedback from LinkedIn, from leadership, from my partners, from miscellaneous teams, and it's really about how do you actually take that information and then be able to distill it and then create something actionable from there.

Paul:

So you are the first

Savan Kong:

Mm-hmm.

Paul:

Customer Experience Officer in, in DOD. So your day one is you are a role that has not existed before.

Savan Kong:

Yep.

Paul:

You have a mandate that is, if not brand new, at least novel within the

Savan Kong:

Yes.

Paul:

organization, which is to

Savan Kong:

Yep.

Paul:

bring design thinking into a massive, sprawling, complicated. Embattled, you know, pun intended and not intended both.

Savan Kong:

Right.

Paul:

but, you know embattled organization with, with an enormous mandate, enormous budget, but enormous constraints. There will be people listening to this that are trying to bring design thinking into much smaller organizations. But

Savan Kong:

Yep.

Paul:

what is your strategy on day one? Where do you start? What is your first step into the job?

Savan Kong:

That's a great question. When I showed up, my friend, John Sherman was the CIO at the time, and he tapped me on the shoulder. He knew that customer experience was important, that user experience is important. But I think there's really layers to a lot of the motivation behind setting up something like a CXO office. And it is the layering of things like LinkedIn posting my computers don't work. It is, you know, we have these defense business board reports that say, Hey, like user experience and the DOD is really, really trash. You guys should fix it and here's how. It is leadership saying, Hey, our computers and our networks aren't as good as they could be'cause I know when I go home they're much faster. Why is that? And then you also have people that are down range that are just trying to get online and they can't. Right. So you have sort of the swirl of information that is constantly bombarding you, but you need to have champions to raise their hand and say, okay, we understand this is a problem. We don't know exactly how it's gonna be established yet, but we should probably start to invest in it. So I think the first thing, was John really understanding that an investment needs to be made. And he brought me in. My question to him was, what's the responsibilities of this person? Like, what are we doing, right? And, and how do we get there? And you know, we probably spent a good couple months just trying to understand some of the big key levers that we can use within the department. And there are things that, if you've never worked in the DOD or in federal government, there are things that you have to be able to do if you're trying to get momentum a across any initiative. And so, what we settled on was: there's some sort of governance that needs to happen. IT governance is what we called it. So, that was one of the things that we said, okay, we need to invest in it, in this thing. There is some strategy that needs to be updated so that people that are looking to make investments in customer experience can point to something authoritative, some strategic document that needs to be published so that when they get asked a question of why should I invest in something like Eternity, where you're measuring the effectiveness of your computer and your network, why should I make that investment versus going to buy another missile or versus going to buy more guns, right? So you can actually point to an authoritative source to be able to do that. We had a big piece around the performance management, which is around our OKRs, understanding how we're doing with our investments. And then, there is a, a big sort of like piece that covers all that, which is around intake, which is just constantly getting information, talking to customers, making sure that we actually have a structure for that. Once we've got all those things in place, we then establish the user experience part. The way I describe it usually is you have to have a set of things to be able to direct you on this road trip so that eventually you can get to the user experience piece, which is the last piece of how we've structured the CXO office. And that honestly took probably a good six months just to try to flush that all out and get that established.

Paul:

And, and that doesn't actually seem slow to me, given the

Savan Kong:

Yeah.

Paul:

scale of the organization and

Savan Kong:

Right.

Paul:

the amount of water you're trying to carry.

Savan Kong:

Yep.

Paul:

For folks that are listening who maybe the DOD is a big amorphous object. They've seen movies with military people in it, wherever people have built

Savan Kong:

Right.

Paul:

their understanding. I would imagine, Customer Experience Officer in the military, people are instantly thinking interfaces and software. But you sort of talked about like network latency and computer

Savan Kong:

Yep.

Paul:

performance, people's ability to do their jobs effectively, efficiently. Can you talk a little bit about maybe sort of the breadth and scope and then maybe sort of dial into to an example of the kind of problem you were tasked with solving the kind of challenge you

Savan Kong:

confronted. Yeah. I mean the, the, the scope of our organization of CXO was specifically IT. You could argue that customer experience should expand beyond that. And in many ways it's probably the right thing to do because there is a lot that goes into process design that goes into training talent and recruiting. But for CXL, we, we just looked at the IT investments that we were making and trying to understand if those investments were really moving the needle. And there's really two parts of that. So there's the modernization of technology and really looking at what's coming up to see if it's actually going to be helping us solve problems. But I would argue that maybe a bigger challenge was. Understanding what we were making and deploying that was becoming quickly antiquated, right? Things that are what we would term as as tech debt. And how is that really sort of like pulling us down and creating that weight, like. The DOD is good at making investments in technology. The thing that we're not as good at is turning things off, right? We'll have these systems that are in place for a significant amount of time. We've spent five years trying to get it onto the system. We've then hired people to, to be able to work it. And you know, we'll have these legacy systems in place for years, even if it's not something that is moving the needle. The act of trying to identify tech debt and then be able to put a plan in place to be able to update that is exceptionally hard. I would say there's probably some politics there. There's probably some just angst and anxiety around turning things off because we could be missing something. But for the most part, looking at those two pieces, the modernization and then the tech debt, and then looking at what it looks like for people to use those systems is maybe the breadth of sort of what we were doing To sort of like put a microscope on that, I'd say there are things that we were looking at. I'll give you an example, Paul, that was specifically around how performant a person is. So when you go and you sit down in front of your computer, how long does it take you to be productive? Right? And it's questions like that. And, you know, coming from our background that that simple question can get pretty complicated pretty quickly, depending on sort of how you define certain things. But we would have very frank and honest conversations about can we measure, do we even have the capability to measure these things? And if so, how do we actually start to produce reports that were being consumed in a way where we can have some sort of achievable difference? Right? And then the third piece is, okay, so we can measure these things. We got people on board. How do we put together a plan to make investments to actually make the changes that we need to make? I'll give you one specific example. So in different parts of the DOD, you have these computers that are shared computers and a lot of times you'll go onto one of these shared computers and it'll just be bloody long to boot up and you're thinking, well, this computer doesn't look that old. What's going on? One of the things that we ended up doing was, we're looking at not just the hardware and the software, but the configuration of these computers because,

Paul:

Computers are not performing well. Let's get new computers. But really it's, it's the network latency and the load time of a virtual desktop with all the configurations to load onto that shared computer so that I have my private environment running on this machine, getting that, all that data across the network.

Savan Kong:

Yep.

Paul:

So maybe it's a network design problem, or a software boot problem or a minimum load problem. There's so many ways you could approach that, but until you know the problem you're trying to solve, the actual problem, you know the symptom. For folks who are just sort of maybe hearing about what design is or you know, still are trapped in the, it's making things look pretty.

Savan Kong:

Yep.

Paul:

Design is about getting to the root cause. It's a set of processes and tools to get to root cause.

Savan Kong:

Yep.

Paul:

Once you're on bedrock, now we're in a a position from which we can actually start to build new solutions into outcomes. I love that.

Savan Kong:

That's, that's absolutely right. One of the, the big challenges that the DOD has is we, we, we tend to get fixated on things, I'll just give you an example, like artificial intelligence right now, it's hot everywhere, right? Not just the, the DOD, but across the entire globe. And we'll get fixated on these things. And whether it's the cloud or artificial intelligence or whatever it may be. And we forget to ask the question of, what is it that I'm trying to solve for? Right? And why are we doing these things? And the further and the bigger that chain is, and the further down you are in that chain, the more that that question either gets lost or muddied. And you'll have people then start working on these problems, but they don't know why they're working on the problems. They just know that they need to deploy the the latest, you know? Artificial intelligence solution and get it to work. But you know, one of the big things that we were trying to do within CXO was be able to create these narratives or a template for narratives so that they can actually take the body of work that they're doing and then tie that back into the problems that they were trying to solve. It sounds very, very simple, but you times that by an enterprise as large as the department, and it becomes really complicated really quickly.

Paul:

Yeah, no kidding. You talked a little bit about finding your levers or at least your points of leverage. What points of leverage can you even create in an organization that's sprawling? You

Savan Kong:

Mm-hmm.

Paul:

know, when there are so many stakeholders, how do you even get the right people in a room together? You talked about something earlier that I wanna circle back to, which I thought was really interesting. You talked about your day one activities and you said, you started by building alliances. Then you started to look for your leverage points. What can

Savan Kong:

Mm-hmm.

Paul:

I move and how can I create change? What is available to me? You talked about measurement in say like getting to measurement of what, what are we changing and how can we measure that change? So those are sort of steps three. And then you talked about building your infrastructure the tooling of your design practice within government. And I think that is so essential to talk about. I'm so curious about that for you and your, you're within the IT department, which will itself be a massive IT department. know, probably as big as anything on earth, in Yeah. terms

Savan Kong:

of the total number

Paul:

of bodies and budget and systems and technology,

Savan Kong:

Yeah.

Paul:

Rivaling the, you know, the Amazons and Microsofts and Googles of the world. What did your design infrastructure look like? Who was on your team? What were you doing? What kinds of design tools did you bring to bear? I'm curious just to get into how the sausage was made.

Savan Kong:

That's a great question. Initially, the team was really small. It was myself and my deputy. And really we were just attest to see if something like this would work. Right. And, you know, eventually we, we became still a small team relative to how big the department is. But my intention for something like CXL and whether it's at the department or anywhere else is putting together things that are authoritative, that can be sustained and they can be scaled. And I think if you can hit those three things, you can be successful. The one thing I didn't wanna do was I didn't wanna be everywhere all at once. It's physically impossible, but also, you know, isn't a good way to be able to take, you know, a lot of these things that were in, in some cases radical ideas, like, you know, measuring things and then putting things into some sort of dashboard so you can actually start to track that and then align it to OKRs. A lot of times people don't understand what that looks like, even though it could be very basic to maybe me and you. And so my goal from day one was to be able to establish a culture or the idea of a culture of what customer experience looks like, and then be able to champion that with other people. We always had close ties with leadership within, say the Navy or the Air Force. And then trying to sort of get them to collaborate with us pretty closely so that they can actually take a lot of things that we were looking for in terms of metrics, policy changes, strategy, and then be able to align their specific strategy to some of the things that we were looking for. Right before I left, we were working on a a toolkit to push out to the world. So that, you know, organizations can take a lot of things that were top of mind for us, that were important, and then be able to apply that within their own place. One of the things that we heard, pretty consistently was, I would have these conversations with people within the department and they would be like user researchers, or user designers or product managers. And the challenge that they had was they said, Savan, you know, I was hired to be a designer here, but I'm the only person I'm on an island Leadership wants to support me, but they don't know how, they don't know what I should be doing or what I could be doing. How do I sort of like get more in touch with your organization so that we can actually start to one, give them some of the support they need just from a leadership perspective. But two, they're trying to execute on their initiatives. Are there ways that we can produce, say, toolkits or systems or design thinking that they can then just apply to their organizations? And so that's really, you know, what, what I was trying to do within the first year and a half was to establish some foundation of what design looks like within the DOD, but then start to identify the champions and then roll out specific languages and systems and infrastructure for them to be able to take that and champion within their own organization.

Paul:

It is such a common narrative that within public service, you'll finally get a job classification for a designer, like the union classification, the

Savan Kong:

Yeah.

Paul:

ability to hire these people. You bring them in.

Savan Kong:

Right.

Paul:

And then you don't know how to engage with them. You don't know how to put them to work.

Savan Kong:

Yes.

Paul:

And then you get designers, the just so many folks, just people who have a design role who's like, I wish I just had a seat at the table where decisions were getting made.'cause I think I could improve the quality of those decisions. Then, of course, there's also the converse of the designers who get a seat at the table, and then suddenly they're exposed to the fire hose of complexity at government. Now they're, wow. It's overwhelming. It's like the dog that caught the bus. It's like,

Savan Kong:

Right.

Paul:

Oh God. These are really wicked problems.

Savan Kong:

Yeah.

Paul:

As designers, we have to have that deep confidence that by bringing our process, the apparatus of design forward,

Savan Kong:

Yep.

Paul:

You have believe in design as a value, as a way of solving problems. How did you help folks that were maybe siloed or, out on that lonely island trying to figure out how to get to the table? What are some techniques that you saw that maybe worked or some narratives of people actually finally, getting to that point of influence and be able to use design in the way it's meant to be used, which is again, solving business problems.

Savan Kong:

Yeah, that's a great question. You know, the DOD is very hierarchy driven. Right. There's a chain of command and it's, it's probably the best, and it, depending on who you ask, maybe the worst thing about the department. Right. And so for me, when I joined the DOD there's two things that I wanted to do when I initially started. The first was I was just really trying to learn as much as possible. About how the organization works. And then the second piece of that was, I wanted to be respectful of the history that was there, the culture that's there. And you know, a lot of times when you have these outsiders coming in, they'll just wanna shake things up and say, oh, well we did it like this at Microsoft or at Amazon. It worked really well. We should do that here. Without really understanding the history behind things and how decisions are made. And so, I took that same approach when standing up CXO was okay. Like if we see people that are having a hard time like a designer that wants to run a design sprint, but they need to be able to bring in their customers, right? A lot of times the customers that you need to talk to will be behind a different set of individuals that are gate kept or they're deployed or whatever reason. And so, we tried really hard to become supporters of a lot of those initiatives by talking to their leadership and saying, sir, ma'am, you know, there's this thing that's coming up and we think it's critical because of X, Y, or Z, but be able to speak in a language where their leadership understands that they need to make that investment if they want to have some sort of return. Many times when you are in an organization and you are not part of that leadership chain, your voice is really muffled, right? You don't actually have the ability to reach up to, say, a colonel or a general and say, sir, ma'am, I wanna do this. What do you think? There's like layers upon layers that you need to get through. Paul, another piece of that that I'm thinking that's really interesting that you didn't specifically ask, but from a design perspective, the question around having a seat at the table is an interesting one because I get asked that a lot. I would say from a design perspective, if you are in a position to be promoted to a rank where you are becoming a leader in whatever industry it is I would say it's almost as important for you to be as open and have the empathy to understand what the business challenges are and be able to understand why P and L is important, to be able to understand why burn rate's important, right? All these things that historically as designers you may not have cared about, but they do influence your ability to be successful in that world that you're in. And so I tell people that are trying to become leaders in either design thinking or that design space that you really have to understand and have a greater sense of empathy for the entirety of that culture and that organization for you to be effective.

Paul:

But that goes back to your second point in terms of your day one activities, which is what are your leverage points? And I think it's such a common error that designers make, which is we bring our toolkit, there's an arrogance to design, potentially of, I have all

Savan Kong:

Yep.

Paul:

these solutions, please just let me use the solutions I have.

Savan Kong:

Yep,

Paul:

If you don't figure out what are your leverage points, and your leverage points are what does this organization deeply care about? What are those things that

Savan Kong:

exactly.

Paul:

this organization values, which could be hitting budgets? Then let's figure out how design helps you hit budgets more effectively. It's activating people in terms of, like, rewarding careers. Let's figure out how to use design, figure out how you can use what the organization already values.

Savan Kong:

Exactly.

Paul:

And then attach your work to those things. I just love how you brought those two things together. I think that's so important. A designer who doesn't understand the business and have respect for the subject matter experts within the business will probably always be on the sidelines.

Savan Kong:

Yeah I, I completely agree. And, you know I think that is the challenge as we look ahead of what's coming up in design, especially in federal government, is how do we as designers or design thinkers in this space, align ourselves more closely with outcomes whether it's of government outcomes as civil servants or, if you're going to academia, what does that look like to be promoting things that your institution's working on, or, in industry, how do you actually help increase the whatever gizmo that you're trying to sell? Like how do you help do those things? And I think that with the advent of a lot of these AI tools, we're starting to see the shift of the amount of time that you're spending on collateral that you may be making to thinking more critically. And I think that's probably one of the more exciting pieces of what's coming up, is that shift to more critical original thought, creative thought. It started to happen and you're spending less time in documents, you know, on slides in Figma or Photoshop, whatever that you're doing. And I think that's exceptionally exciting.

Paul:

I have a colleague who runs a project management consultancy. You know, he, he sort of said, you know, the, the measure of an effective PMO, project management office, should not be the rigor you apply to projects. It should be the throughput

Savan Kong:

Yes,

Paul:

that your products produce.

Savan Kong:

I love that.

Paul:

Right? You know, like, are you moving? That should be the only thing that you really care about. And everything else, all the rest of the process should serve that goal of are we actually getting the work done? Is the work moving smoothly through our systems?

Savan Kong:

I love that.

Paul:

You gave us a gift a few minutes ago that I wanna come back and put some punctuation behind. You talked about one of your thinking models for the design infrastructure in an organization. You used three terms that I think are just worth just exploring for a few minutes. You said authoritative, sustained and scaled, and each of those works together and each of them is really important. Can we talk about authoritative for just a moment?

Savan Kong:

Yep.

Paul:

Because again, we build a design system, no one uses it. You know, we

Savan Kong:

Yes.

Paul:

build content standards. The classic, we wrote a style guide that no one read.

Savan Kong:

Right.

Paul:

So the authority of the tooling we build for design, could you talk a little bit about what that journey was like and what your experience was of trying to build authoritative tools within an organization or authority? As you said, this

Savan Kong:

Yep.

Paul:

is a highly hierarchical command control culture.

Savan Kong:

Mm-hmm.

Paul:

How do you build authority within a group like the DOD?

Savan Kong:

It's one of the hardest things. It's also one of the things that will make you lose your hair the quickest. The thing that the department does a really good job of is we're really good at producing documents. We're really good at writing emails. We're really good about coming up with things, right? And everybody in the department has good ideas all the time. The challenge that you have is in a very hierarchy driven organization how do you know with all the information that's out there and all the initiatives that's happening, how do you know what to prioritize and what things to do and what investments to make? And that's where, the idea of having authoritative documentation or authoritative initiatives comes into place. And what I mean by authoritative is it has been vetted through a formal processor system. People have had the ability to contribute to it in some meaningful way. And then at the end of the day, a signature from whoever it is, in the case that I'm thinking about it was with Deputy Secretary Hicks signing a document called Fulcrum for Us. And that was the IT advancement strategy. The idea of an a authoritative document does a couple things for the user. The first thing is it gives them a quick playbook to be able to reference just in case they're trying to do something. The second thing is it gives them the ability to have weight behind their decisions. So if you are caught between, oh, I need to either sweep my floor or I need to look at this data and be able to have some analysis, you could then pull up something like Fulcrum and say, okay, i'm gonna do the analysis piece versus going out and sweeping the floor because this has been sort of backed by somebody that has a ton of influence and sway in the government. And that's a very, sort of terse comparison, but you could see how that could play out when you're making investments in either tooling or talent or process changes, you have to have authoritative things to lean back to and say, okay, user experience is important because it was documented here. That document has also been vetted across the entire TOT, and this is why we should, we should be making those investments without like an authoritative source. You're not gonna be able to get any type of movement across the department with investments.'Cause our budget is massive, but that budget gets cut up so quickly that. If you're not in a place to have either backing or authority behind it, it's not gonna happen.

Paul:

I like that you brought the tool tooling of design, how do we create the right message? But it's really about hooking the tooling of design into the power structures within the organization so that you have the backing of the organization, and it's hard to do that. So you, I would imagine, you need to be absolutely laser focused on what is the most important piece here, which is where I say, you know, you need to bring your design prioritization of, if nothing else is true, this must be true.

Savan Kong:

Right. Right.

Paul:

That is a design action, of that prioritization, that focusing work. And then by hooking into those power structures, now you have the authority of the organization behind you.

Savan Kong:

Mm-hmm.

Paul:

And now these ideas, these concepts, this infrastructure can travel out into the organization and it, and it's hard to, people won't change if they don't have to. So.

Savan Kong:

Right.

Paul:

you want to make it more likely that they're going to change towards these things. Okay, I love that. So then your next ingredient in the recipe was sustained. And I think this is so important'cause we, we

Savan Kong:

Yep.

Paul:

build things with no sense of how are we gonna keep feeding and watering this? You know? So what does sustainment look like within the organization? How do you think about that?

Savan Kong:

I think like of all of the three things that I talked about, I think the sustainment piece is probably the most challenging and tricky. I would argue that the department has a pretty good infrastructure to take in ideas, right? We've got organizations like TIU and you know I can't remember if we dismantled the dib, but there's organizations that can go out and look for new ideas or that can actually start to take in new ideas from academia and industry. And so the top of the funnel for the department, I would argue is, is not where the challenge is. The challenge is once you've gone through a series of either prototypes or initiatives, how do you actually take that and then how do you apply it to a greater workforce within the department? Right. And that's where the sustainment comes in. It's do you have the right funding mechanisms to be able to take this thing and then deploy it? Do you have the right authority to be able to deploy this thing behind certain environments? Are there users like across the department that are actually gonna pick this thing up and use it? Or are we just deploying something that somebody has mandated, let's just say a Microsoft teams where people don't love it, but they don't hate it, but they're sort of mandated to use it. And so it's things like that, for the department when you get offered a piece of technology, you're sort of like forced into that piece of technology. Unlike in industry, if you're like, oh, I don't like Google documents, I can go and just pick up Microsoft Word or something like that and use that to write what you wanna write. And so the sustainment piece is a tricky facet because the things that we use in terms of how do we actually consistently improve upon this tool that we've deployed, but also how do we actually measure what good looks like, right? So that we can constantly improve upon that through investments. And it's really, really tricky. It's, it's probably the hardest one,

Paul:

Absolutely. You know, people love to create, they don't love to maintain.

Savan Kong:

Right? Right. And I think like the, the other, the other side of that is, how do you put together a decision framework so that if you wanna spin something down because you know, that it's being discontinued, how do you do that? And that's a really big challenge, especially if you have a user base that's as large as the DOD. And I would say, you know, just in terms of being good stewards of taxpayers dollars, I would say if this current administration really had to focus on one thing to do, to be able to recuperate a lot of lost money in terms of investments of tools that may or may not be great, like that would be a good worthwhile place to start.

Paul:

It's powerful to shut things off.

Savan Kong:

It is.

Paul:

That is a part of the playbook that's being enacted in May of 2025 right now is a lot of things

Savan Kong:

are getting shut Right,

Paul:

off.

Savan Kong:

Right.

Paul:

and we'll see how those

Savan Kong:

Right.

Paul:

decisions are getting made. The final piece, and DOD is probably the most powerful lens on this, you talked about scale, so building design, infrastructure that can scale.

Savan Kong:

Mm-hmm.

Paul:

What did that look like for you? What did scale mean at the DOD.

Savan Kong:

Scale for us? I think there's a couple different frames of reference you could probably take that through. For us, within CXO specifically, we looked at problems that were not specific to a defense agency or through one of the major service branches. So for us, scale always meant is the thing that we're investing in going to be impacting a large amount of people that is agnostic of your organization, right? Can we actually take whatever this is, let's just say it's the latest version of Eternity for capturing user metrics and performance metrics. And then can we apply that across the organization so that we can actually. Start to understand what the picture looks, like and have that same sort of consistent frame of reference. I'll give you an example of this as well. When we were asking for metrics from the different organizations, we said, we wanna see where you guys are now with this benchmark, for this specific thing. I won't get into the exact metrics, but, we had a wide variety of different answers across the board. And the reason being was because there were different tools that people were using that had different definitions of what success looked like and they were talking to very different user groups and a user base. So the idea of scaling is not just the quantity of people that you were trying to, solve for, but it's really sort of doing it in a way where we can start to normalize the conversation of what it is the expectations were, and then what we expect in terms of outputs from the different organizations. That's both tooling conversations, that's policy conversations is this policy really just for this specific organization? And then that's also the strategy piece. So when we actually released Fulcrum, that's not just a CIO strategy piece, that's a Department of Defense. So now you Navy, you Air Force, you take a look at this document that is a DOD wide document, you then go and you write your own. But it has to align to these things that we've written here.

Paul:

One of my favorite quotes comes from Don Norman, who's sort of one half of the Nielsen Norman Group, the legendary UX consultancy, and he

Savan Kong:

Yep.

Paul:

defines user experience design. I can't do a British accent, but I assume this sounds better, with a British accent, but he says, user experience design is the elimination of fuss and bother.

Savan Kong:

Mm. I love that.

Paul:

What you just described, for scale can be architectural, et cetera, but can things grow and go, like, have you sanded off all the rough edges? The wonderful way you talked about these three principles is for, authority and sustainment and scale, you talked about using the toolkit of design. To address the design toolkit itself, of need these things to be hooked into what's most essential for the organization. We need these things to have support and understand what will take to keep feeding and watering these things. And then we need to build these in a way that they can go out and do the work without a human having to be there to keep pedaling that bike forward. These things are so well designed we've eliminated all the friction to adoption.

Savan Kong:

Yeah.

Paul:

They just work, this way works better than other ways. You know you will

Savan Kong:

Yeah.

Paul:

get better outcomes. To the designers listening to this, saying, how do I get to the table? You already should have the tools.

Savan Kong:

Right.

Paul:

To bring design to the table. Savan, this is a great recipe for how to build the design infrastructure into the most complex government organization. I can imagine the Department of Defense of the United States government. What

Savan Kong:

Yeah,

Paul:

powerful mission you've been on.

Savan Kong:

I appreciate that. It has definitely been challenging, but also really fun, right? It's also a really fun job.

Paul:

Again, I'd encourage anybody who wants to sort of think more about this and through that the military lens, General McChrystal's book Team of Teams is a different context, a different set of problems. So a lot of similarities between what you and I just talked about here and the ideas you brought to the table. It's worth a read. I just love the conciseness and, and the clarity around the ideas you shared today, but at a more human level, for those folks who are struggling, who are in the thick of it, who are trying what kept you going? You talked about the fun of it, and the,

Savan Kong:

Yeah.

Paul:

joy of solving problems, but what for you was the motivation to do this really hard work?

Savan Kong:

I'm by nature a constant learner. Every single one of these jobs I've been fortunate with, i've worked in slightly different capacities. I've never sort of worked in policy in a policy shop. I didn't know the first thing about it before jumping in. And you know, I thought that was fun, right? And then before that never worked in the department. And I thought that was fun too. It's like, okay, you're going and you're learning something different. And you know, I had the pleasure of speaking at my high school a couple weeks ago, and you know, one of the things I told the kids was the first job that you take doesn't define you. Like your major doesn't define you. Just because you're in marketing doesn't mean you're doing marketing. It's really just a stepping stone to whatever it is that gets you exceptionally excited to wake up every day. And I think, for me, I've been fortunate enough now to have at least a foundation or a basis of design thinking that I could take to any industry and anywhere in the world and apply that and hopefully help these organizations become a lot more positive once I've left in some ways. Whether that's through working at a place where I'm actually building things with software design and designers, or whether that's through writing policy or whether that's just looking at business operations. I think the art of thinking through critical things intentionally and trying to understand the problems is the same regardless of where you're at. But you know, being able to do that and have people take that chance to hire you to do those things and learn those things really gets me excited, now I'm at this crossroads in my life where I'm trying to figure out what I want to do when I grow up. And I keep going back to, I wanna be at a place where I am constantly being challenged and I can still apply the things that I've learned. But I also wanna learn new things. I don't wanna do the same thing I was doing back when I was 27, 28. Right. That'd be boring.

Paul:

The world is full of problems and opportunities

Savan Kong:

Yeah.

Paul:

and design is the toolkit to approach them well among other toolkits. I

Savan Kong:

Absolutely.

Paul:

thank you so much Savan, for sharing your experience with us today and I can't wait to hear what you do next.

Savan Kong:

Me too. I'll let you know when that happens. Thanks, Paul. I appreciate you.

Paul:

Thanks for joining Savan and I for this conversation, and thanks to Savan Kong for sharing his unbelievably unique experience of the DOD with us. There are a few bigger or more complex organizations in the world, than the US Department of Defense, but the model that Savan brought to building out design infrastructure is robust and simple enough that I'm confident you can adopt it as a design leader in your organization. The recipe this event brought to bringing design into the public service is one, build your alliances. You're going to need support, champions, a team, and to win hearts and minds. Start by understanding who has influence, build relationships, and create your partnerships. If you want to go fast, go alone. If you want to go far, go together. Two, find your leverage points. If you want to create change, then learn what the cultural and strategic values of the organization already are. Then use those as leverage points to amplify the importance of design and use design to solve the problems that the organization already cares about. This will create a tailwind for your work. Three, define your measures. If you want the organization to value design, then learn how to measure the value that design produces. And if it's connected to the leverage points you've identified, you'll build support naturally. Four, develop your design infrastructure. This is the most important component because in any large public service organizations, individuals don't scale, but systems can. You need to invest in systems, policies, and infrastructure for design, so that as the organization starts to value design, the work can grow. With regards to design infrastructure, Savan also gave us a second model that I think is very useful. Your design infrastructure needs to be authoritative, sustained and scalable. Authority is essential because change doesn't happen without top down support. Find out where the power structures and points of influence are and connect your infrastructure there. Sustainment means ongoing resourcing and support,

design work

Paul:

is evergreen, so be sure to clearly articulate the business value in measurable terms, and advocate for ongoing resourcing and budgets, not just one-off projects. Scalability is where design can truly shine. Learn about the barriers to adoption and bring your design toolkit to the toolkit of design. Remove barriers, improve processes, make better tools. Design is the goal, but also the path. With the current US administration agenda, many great people have been let go, Savan being one of them. But I can't wait to see where he's gonna land next. His thinking will benefit any organization that takes him on. I hope you enjoy this conversation. Please do subscribe and follow us. For more, I'd like to thank my colleagues who work with me on this podcast. Kathy Watton is our show producer and editor, Frederick Brummer and Ahmed khalil created our theme music and intro. We're gonna keep having conversations like this. Thanks for tuning in. If you've got ideas for guests, we should speak to, send us an email to the311@Northern.co. The public service is about all of us, and when done right,

digital can

Paul:

be a key ingredient for a better world. This has been The 311 Podcast and I've been your host, Paul Bellows.