S2:E8 Design at Scale with Savan Kong

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 [e-mail].

Northern LinkedIn

Episode Transcript

Paul (00:30):
This is The 311 Podcast and I'm your host, Paul Bellows.
This is a show about the peoplethat 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 andset of experiences.
He was most recently the firstever Customer Experience Officer

(00:54):
for the United States Departmentof Defense.
One of the largest organizationsof any kind in the world.
The DOD is the largest budgetsegment in the US federal
government, the largest employerin the nation, and a massive
collection of sub entities eachwith their own leadership and
mandate.
Savan followed a path throughthe private sector, starting as

(01:14):
the first employee of Redfin,now a$2 billion plus NASDAQ
listed technology company withnearly 5,000 employees in the
real estate space.
Savan brought UX and designthinking to that thriving
business to create a patentedmap-based search and advertising
technology.
He led consumer design at Amazonand held other executive roles
in the private sector beforejumping into the defense

(01:36):
industry as a digital serviceexpert at the Defense Digital
Service.
When the CIO of the DOD tappedSavan to pioneer the new CXO
role, that was a lot ofacronyms, Savan brought a design
mindset to the job in every way.
And in this episode, he's goingto share his mindset and models
for how to introduce designinfrastructure into an

(01:57):
organization as complex as theUS DOD.
I think you'll like hisapproach, and in the show notes,
we'll be sure to spell out themodel he lays out in the episode
in great detail.
Here's my conversation withSavan.

Savan Kong (02:12):
My name's Savan, not Savon.
If I had to introduce myself in30 seconds, I would say I am a
customer experience thoughtleader.
Most recently, running customerexperience at the Department of
Defense.
But I've worked across theentire sort of spectrum of
product and design and customerexperience design across federal
government and industry.
Most recently, part of my jobwas to try to understand how we

(02:36):
can influence better customerexperience through policy and
strategy in the Department ofDefense.
But there's a bunch of differentways that we can dive into of
how we could potentially bedoing that.

Paul (02:49):
There's sort of this myth that exists, and one place I
wanna start our conversation isthis myth that government is big
and bureaucratic,

Savan Kong (02:56):
Mm-hmm.

Paul (02:56):
business is agile and strategy focused and moves fast.
And it's funny.
I don't know that, I believethat myth.

Savan Kong (03:04):
I don't either.

Paul (03:05):
Government is big, you know, and

Savan Kong (03:06):
Yep.

Paul (03:06):
there are bureaucracies within government,

Savan Kong (03:08):
Yep.

Paul (03:08):
But I'd love your thoughts as a customer, a designer
focused on the customer, whathave you seen as the main
difference moving betweenprivate sector and public
sector, in terms of the work youdo and the readiness of the
organization to embrace thatwork.
What have you seen as the, themost noted differences between
those two sides of the industry?

Savan Kong (03:28):
That's a great question, Paul.
To maybe take a step back, andreally sort of like try to
understand what design is, anddesign thinking is.
To me, design is really, anintentional act.
An intentional act of creatingsomething to solve a set of
problems.
Now, if we use that as a basisof understanding what design is,

(03:50):
I think that the government andthe Department of Defense has
historically been a forwardthinking organization that has
done that.
Right.
Whether it's through theestablishment of different
agencies, whether it's throughthe adoption of different
processes the act of designinghas historically been done in
the department for many years,many generations.

(04:11):
Now, I think where thedisconnect is, in industry, we
have nomenclature in terms likehuman-centered design, service
designers, user experienceresearchers that is not
applicable in many ways in theDepartment of Defense.
And in many ways that narrativeof establishing those types of
roles with those titles hashasn't been there until

(04:34):
recently.
And so I think where thedifferences are is really in how
we're actually categorizing,these essential responsibilities
of designers, product managersand then being able to use that
same narrative and that same wayof describing essentially the
act of trying to solve theseproblems intentionally the same

(04:57):
way so that you can have thatone-to-one comparable between
industry and federal governmentor the department.

Paul (05:05):
It occurs to me that we're starting to see title parity,
role parity between what might

Savan Kong (05:09):
Yep.

Paul (05:09):
happen in say, a corporation And a government
department, the idea that youhad a customer experience title
is really interesting in agovernment agency.
Potentially it's the advent ofthe same technology, the same
technology problems occurring inboth.
We're all doing thisdigitization work, trying to
figure out

Savan Kong (05:26):
Yep.

Paul (05:27):
how we work through mediated interfaces, where we're
eliminating desk service andphone service, and we have
technology brokering theexperience between an
organization and a customer, itsservices.
Suddenly we're seeing titleparody and role parody showing
up across both organizations.

Savan Kong (05:42):
Yeah.

Paul (05:42):
It could an interesting lens to take to that problem.

Savan Kong (05:45):
Yeah.
In many ways there is a questionthat for people that have been
in industry their whole lives,if they're trying to transition
into government, there is aquestion of, how am I being
represented or am I beingrepresented?
Let's just take a UserExperience Researcher and that's
what you've done for your wholelife.
Up until recently you couldn'teven search for a job and find a

(06:07):
User Experience Researcher inUSA jobs just because there
isn't that one-to-onecomparable.
And at times, if you're lookingto make that shift you're gonna
ask yourself the question of, doI belong here?
And if I do belong here, how doI get represented in an
organization like this?
And, the funny thing was myfirst foray into government was

(06:28):
that defense digital service.
And we brought in some forwardthinking people to try to infuse
the best of industry into thedepartment.
What was funny was when I gotthere, my whole background was
working in these agiledevelopment teams.
We had product managers,designers, engineers, and when
you say product or program orproject manager, in the

(06:51):
department, it actually meanssomething very different than
what it means in industry.
And so to try to reconcile,okay, these people have these
specific responsibilities, thesepeople have these specific
responsibilities and they're notthe same thing is really
challenging at times.
'Cause when you're reaching outto people and you're like, oh,
you're a program manager, whatdoes that mean?

(07:12):
And just to even have thatclarity of conversation and
communication is very hard,especially when you have these
different universes you'recoming from.

Paul (07:22):
And there are unique aspects to working in public
sector too, we have politics, wesort have this public aspect of
this belongs to the public andthere are elected officials and
you know,

Savan Kong (07:33):
Yep.

Paul (07:34):
the act of new releasing interfaces.
We're changing a public servicewhere that looks like policy,
sort of the funny melding ofpolicy and interface and
product,

Savan Kong (07:45):
Mm-hmm.

Paul (07:45):
These things all kind of can wrap together.
I wouldn't mind hearing some ofyour thoughts on just talking to
the customer is harder ingovernment,

Savan Kong (07:52):
mm-hmm.

Paul (07:53):
because that be seen as a political act too.
You know, overall consulting.

Savan Kong (07:56):
Yep.

Paul (07:57):
are we consulting on policy or are we just simply
trying to design a usableproduct?
Those lines can get, could justget complicated.
A lot of the legislation and thepolicy that existing government
is to protect from politicalconsultation under the guise.
You know, like we wanna avoidpolitical acts on the
operational side.
But that can put realconstraints around what you can

(08:20):
do in terms of just talking tocustomers.

Savan Kong (08:23):
Yep.

Paul (08:23):
I don't know what DOD what was that like?
What was your ability just toaccess your customer, whether
it's for research or testing orvalidation?
What is that I.

Savan Kong (08:32):
Really challenging.
I'd say it's probably thehardest thing about my job when
I was there, is trying toidentify, one, who those
customers are based on whatorganization you're with.
You look at an organization likethe CIO.
Ultimately our customers are thewar fighter if you're in
Department of Defense, right?
That's sort of like what itboils down to.

(08:53):
However, with that being said,there are different facets of
that customer journey thatdifferent organizations are
accountable for.
Whether you're working in policyor you're working in
acquisitions, or you're workingin IT, you see different facets
of what that customer journeylooks like.
The challenge that we had withinCXO was trying to really

(09:15):
identify who some of those keyplayers are.
And then the second piece ofthat was because we were so
siloed and disjointed, there'svery few times where we all
actually got together as adepartment, a DOD, and then had
conversations about, what arecommon things that we're seeing
as pain points if you're in theArmy or the Navy or the Air

(09:36):
Force or Space Force orwhatever?
What does that look like and howdo we as an organization, take
into account some of the thingsthat are our advantage, like we
have a massive sort ofinvestment in IT, we are looking
at and working on some of themost critical projects that
pertain to national security,and we also have an
exceptionally high level of verytalented people that understand

(10:01):
how the department works.
To be able to bring togetherthose sort of disparate sources,
those disparate customers, andthen be able to have that
conversation was, frankly, thefirst step that I took as CXO.
How do we bridge this gap wherewe have a lot of people that
have pockets of excellence, butat the same time, a lot of those

(10:21):
conversations get lost in theshuffle because it's such a
massive organization.
That's a big challenge.
And I would say, if I had todistill it, communication and
understanding how to communicateeffectively was probably the
hardest part of my job.
You had to be able to not justtalk to your customers, which
are people downrange in thefront lines.

(10:42):
But also you have to be able totake that, speak to, say, the
Department of Defense, and thenalso then be able to parlay that
back into another group likeCongress or the public, and then
be able to translate, a lot ofthe work that we're doing.
That in and of itself isexceptionally hard to do,
especially in a place that's asbig as the DOD.

Paul (11:02):
What a radically complex set of stakeholders you would be
managing there.
It deeply reminds me of GeneralStanley McChrystal's book, Team
of Teams, he sort of about, inthe context of war, we have
organizations that were built assilos because these are
intelligence agencies.
Not communicating is kind of theM.O.

Savan Kong (11:22):
Yep.

Paul (11:22):
for the US military in terms of, in his book it's the
Iraq theater and what washappening in that context.
But to say they were gettingreally circles run around them
by insurgents

Savan Kong (11:34):
Mm-hmm.

Paul (11:34):
who could break down all silos of communication, who
could be, a lean and agile.
We're using software languagethere, but, you know, even just
talks about the breaking theculture of communication down
to, if we're not talking to eachother, we're not solving the
problems.

Savan Kong (11:49):
Yep.

Paul (11:50):
I would imagine that, that you were on a similar journey.

Savan Kong (11:53):
Yeah, there's definitely that fine line
between sort of nationalsecurity risks of communication,
and I would maybe bucket thatinto a different set of
information, that is purposelysort of quarantined, purposely
siloed and versus something thatis,you know; we talk a lot about
interoperability when I was atdepartment, and they still do,

(12:16):
things need to work welltogether.
You need to be able to seeinformation in a timely way so
that you can make intelligentactions,what to do next.
And you need to be able to seeit from as many different places
as possible and then distillthat information.
And a lot of times, theprinciples of, what we're trying
to do is still the same, even ifthe information may be a little

(12:37):
bit different and hearing thatconsistently across the entire
department was one of the thingsthat actually was really
surprised by, is understandingand listening to these themes
that when we first got together,I thought we were gonna have a
horrible meeting.
I thought people were gonna bevery gun shy about saying, Hey,
this is really bad.

(12:58):
Then it's happening here and Idon't know how to fix it, or
we're doing exceptionally welland it's making somebody else
look really, really bad.
And I was afraid we would shutdown.
But at the end of the day,bringing us all together into a
safe, trusted place where we canhave conversations and you can
follow up the conversation withsome action, let's just say,

(13:19):
Hey, we're gonna put togetherthis report.
It's gonna be sent up to theDeputy Secretary.
We're gonna then take in part,that information into the next
budgeting cycle so that you canactually see investments being
made in customer experience.
That's where you can actuallystart to build a lot of momentum
in this space.
Because, you get feedback allthe time, right?
I get feedback from LinkedIn,from leadership, from my

(13:43):
partners, from miscellaneousteams, and it's really about how
do you actually take thatinformation and then be able to
distill it and then createsomething actionable from there.

Paul (13:56):
So you are the first

Savan Kong (13:58):
Mm-hmm.

Paul (13:58):
Customer Experience Officer in, in DOD.
So your day one is you are arole that has not existed
before.

Savan Kong (14:05):
Yep.

Paul (14:05):
You have a mandate that is, if not brand new, at least
novel within the

Savan Kong (14:11):
Yes.

Paul (14:11):
organization, which is to

Savan Kong (14:12):
Yep.

Paul (14:12):
bring design thinking into a massive, sprawling,
complicated.
Embattled, you know, punintended and not intended both.

Savan Kong (14:24):
Right.

Paul (14:24):
but, you know embattled organization with, with an
enormous mandate, enormousbudget, but enormous
constraints.
There will be people listeningto this that are trying to bring
design thinking into muchsmaller organizations.
But

Savan Kong (14:37):
Yep.

Paul (14:37):
what is your strategy on day one?
Where do you start?
What is your first step into thejob?

Savan Kong (14:44):
That's a great question.
When I showed up, my friend,John Sherman was the CIO at the
time, and he tapped me on theshoulder.
He knew that customer experiencewas important, that user
experience is important.
But I think there's reallylayers to a lot of the
motivation behind setting upsomething like a CXO office.

(15:04):
And it is the layering of thingslike LinkedIn posting my
computers don't work.
It is, you know, we have thesedefense business board reports
that say, Hey, like userexperience and the DOD is
really, really trash.
You guys should fix it andhere's how.
It is leadership saying, Hey,our computers and our networks

(15:25):
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 peoplethat are down range that are
just trying to get online andthey can't.
Right.
So you have sort of the swirl ofinformation that is constantly
bombarding you, but you need tohave champions to raise their
hand and say, okay, weunderstand this is a problem.

(15:47):
We don't know exactly how it'sgonna be established yet, but we
should probably start to investin it.
So I think the first thing, wasJohn really understanding that
an investment needs to be made.
And he brought me in.
My question to him was, what'sthe responsibilities of this
person?
Like, what are we doing, right?
And, and how do we get there?
And you know, we probably spenta good couple months just trying

(16:10):
to understand some of the bigkey levers that we can use
within the department.
And there are things that, ifyou've never worked in the DOD
or in federal government, thereare things that you have to be
able to do if you're trying toget momentum a across any
initiative.

And so, what we settled on was: there's some sort of governance (16:28):
undefined
that needs to happen.
IT governance is what we calledit.
So, that was one of the thingsthat we said, okay, we need to
invest in it, in this thing.
There is some strategy thatneeds to be updated so that
people that are looking to makeinvestments in customer
experience can point tosomething authoritative, some

(16:50):
strategic document that needs tobe published so that when they
get asked a question of whyshould I invest in something
like Eternity, where you'remeasuring the effectiveness of
your computer and your network,why should I make that
investment versus going to buyanother missile or versus going
to buy more guns, right?
So you can actually point to anauthoritative source to be able

(17:12):
to do that.
We had a big piece around theperformance management, which is
around our OKRs, understandinghow we're doing with our
investments.
And then, there is a, a big sortof like piece that covers all
that, which is around intake,which is just constantly getting
information, talking tocustomers, making sure that we
actually have a structure forthat.

(17:35):
Once we've got all those thingsin place, we then establish the
user experience part.
The way I describe it usually isyou have to have a set of things
to be able to direct you on thisroad trip so that eventually you
can get to the user experiencepiece, which is the last piece
of how we've structured the CXOoffice.

(17:56):
And that honestly took probablya good six months just to try to
flush that all out and get thatestablished.

Paul (18:04):
And, and that doesn't actually seem slow to me, given
the

Savan Kong (18:07):
Yeah.

Paul (18:07):
scale of the organization and

Savan Kong (18:09):
Right.

Paul (18:09):
the amount of water you're trying to carry.

Savan Kong (18:12):
Yep.

Paul (18:12):
For folks that are listening who maybe the DOD is a
big amorphous object.
They've seen movies withmilitary people in it, wherever
people have built

Savan Kong (18:20):
Right.

Paul (18:20):
their understanding.
I would imagine, CustomerExperience Officer in the
military, people are instantlythinking interfaces and
software.
But you sort of talked aboutlike network latency and
computer

Savan Kong (18:31):
Yep.

Paul (18:31):
performance, people's ability to do their jobs
effectively, efficiently.
Can you talk a little bit aboutmaybe sort of the breadth and
scope and then maybe sort ofdial into to an example of the
kind of problem you were taskedwith solving the kind of
challenge you

Savan Kong (18:46):
confronted.
Yeah.
I mean the, the, the scope ofour organization of CXO was
specifically IT.
You could argue that customerexperience should expand beyond
that.
And in many ways it's probablythe right thing to do because
there is a lot that goes intoprocess design that goes into

(19:06):
training talent and recruiting.
But for CXL, we, we just lookedat the IT investments that we
were making and trying tounderstand if those investments
were really moving the needle.
And there's really two parts ofthat.
So there's the modernization oftechnology and really looking at
what's coming up to see if it'sactually going to be helping us

(19:28):
solve problems.
But I would argue that maybe abigger challenge was.
Understanding what we weremaking and deploying that was
becoming quickly antiquated,right?
Things that are what we wouldterm as as tech debt.
And how is that really sort oflike pulling us down and
creating that weight, like.
The DOD is good at makinginvestments in technology.

(19:51):
The thing that we're not as goodat is turning things off, right?
We'll have these systems thatare in place for a significant
amount of time.
We've spent five years trying toget it onto the system.
We've then hired people to, tobe able to work it.
And you know, we'll have theselegacy systems in place for
years, even if it's notsomething that is moving the

(20:12):
needle.
The act of trying to identifytech debt and then be able to
put a plan in place to be ableto update that is exceptionally
hard.
I would say there's probablysome politics there.
There's probably some just angstand anxiety around turning
things off because we could bemissing something.
But for the most part, lookingat those two pieces, the

(20:34):
modernization and then the techdebt, and then looking at what
it looks like for people to usethose systems is maybe the
breadth of sort of what we weredoing To sort of like put a
microscope on that, I'd saythere are things that we were
looking at.
I'll give you an example, Paul,that was specifically around how

(20:54):
performant a person is.
So when you go and you sit downin front of your computer, how
long does it take you to beproductive?
Right?
And it's questions like that.
And, you know, coming from ourbackground that that simple
question can get prettycomplicated pretty quickly,
depending on sort of how youdefine certain things.
But we would have very frank andhonest conversations about can

(21:19):
we measure, do we even have thecapability to measure these
things?
And if so, how do we actuallystart to produce reports that
were being consumed in a waywhere 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 tomake investments to actually

(21:40):
make the changes that we need tomake?
I'll give you one specificexample.
So in different parts of theDOD, you have these computers
that are shared computers and alot of times you'll go onto one
of these shared computers andit'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 endedup doing was, we're looking at

(22:03):
not just the hardware and thesoftware, but the configuration
of these computers because,

Paul (22:08):
Computers are not performing well.
Let's get new computers.
But really it's, it's thenetwork latency and the load
time of a virtual desktop withall the configurations to load
onto that shared computer sothat I have my private
environment running on thismachine, getting that, all that
data across the network.

Savan Kong (22:22):
Yep.

Paul (22:23):
So maybe it's a network design problem, or a software
boot problem or a minimum loadproblem.
There's so many ways you couldapproach that, but until you
know the problem you're tryingto solve, the actual problem,
you know the symptom.
For folks who are just sort ofmaybe hearing about what design
is or you know, still aretrapped in the, it's making
things look pretty.

Savan Kong (22:41):
Yep.

Paul (22:41):
Design is about getting to the root cause.
It's a set of processes andtools to get to root cause.

Savan Kong (22:47):
Yep.

Paul (22:47):
Once you're on bedrock, now we're in a a position from
which we can actually start tobuild new solutions into
outcomes.
I love that.

Savan Kong (22:53):
That's, that's absolutely right.
One of the, the big challengesthat the DOD has is we, we, we
tend to get fixated on things,I'll just give you an example,
like artificial intelligenceright now, it's hot everywhere,
right?
Not just the, the DOD, butacross the entire globe.
And we'll get fixated on thesethings.
And whether it's the cloud orartificial intelligence or

(23:17):
whatever it may be.
And we forget to ask thequestion of, what is it that I'm
trying to solve for?
Right?
And why are we doing thesethings?
And the further and the biggerthat chain is, and the further
down you are in that chain, themore that that question either
gets lost or muddied.
And you'll have people thenstart working on these problems,

(23:40):
but they don't know why they'reworking on the problems.
They just know that they need todeploy the the latest, you know?
Artificial intelligence solutionand get it to work.
But you know, one of the bigthings that we were trying to do
within CXO was be able to createthese narratives or a template
for narratives so that they canactually take the body of work

(24:01):
that they're doing and then tiethat back into the problems that
they were trying to solve.
It sounds very, very simple, butyou times that by an enterprise
as large as the department, andit becomes really complicated
really quickly.

Paul (24:14):
Yeah, no kidding.
You talked a little bit aboutfinding your levers or at least
your points of leverage.
What points of leverage can youeven create in an organization
that's sprawling?
You

Savan Kong (24:23):
Mm-hmm.

Paul (24:23):
know, when there are so many stakeholders, how do you
even get the right people in aroom together?
You talked about somethingearlier that I wanna circle back
to, which I thought was reallyinteresting.
You talked about your day oneactivities and you said, you
started by building alliances.
Then you started to look foryour leverage points.
What can

Savan Kong (24:38):
Mm-hmm.

Paul (24:38):
I move and how can I create change?
What is available to me?
You talked about measurement insay like getting to measurement
of what, what are we changingand how can we measure that
change?
So those are sort of stepsthree.
And then you talked aboutbuilding your infrastructure the
tooling of your design practicewithin government.
And I think that is so essentialto talk about.

(24:59):
I'm so curious about that foryou and your, you're within the
IT department, which will itselfbe a massive IT department.
know, probably as big asanything on earth, in Yeah.
terms

Savan Kong (25:08):
of the total number

Paul (25:09):
of bodies and budget and systems and technology,

Savan Kong (25:12):
Yeah.

Paul (25:13):
Rivaling the, you know, the Amazons and Microsofts and
Googles of the world.
What did your designinfrastructure look like?
Who was on your team?
What were you doing?
What kinds of design tools didyou bring to bear?
I'm curious just to get into howthe sausage was made.

Savan Kong (25:28):
That's a great question.
Initially, the team was reallysmall.
It was myself and my deputy.
And really we were just attestto see if something like this
would work.
Right.
And, you know, eventually we, webecame still a small team
relative to how big thedepartment is.
But my intention for somethinglike CXL and whether it's at the

(25:50):
department or anywhere else isputting together things that are
authoritative, that can besustained and they can be
scaled.
And I think if you can hit thosethree things, you can be
successful.
The one thing I didn't wanna dowas I didn't wanna be everywhere
all at once.
It's physically impossible, butalso, you know, isn't a good way

(26:11):
to be able to take, you know, alot of these things that were
in, in some cases radical ideas,like, you know, measuring things
and then putting things intosome sort of dashboard so you
can actually start to track thatand then align it to OKRs.
A lot of times people don'tunderstand what that looks like,
even though it could be verybasic to maybe me and you.

(26:31):
And so my goal from day one wasto be able to establish a
culture or the idea of a cultureof what customer experience
looks like, and then be able tochampion that with other people.
We always had close ties withleadership within, say the Navy
or the Air Force.
And then trying to sort of getthem to collaborate with us

(26:55):
pretty closely so that they canactually take a lot of things
that we were looking for interms of metrics, policy
changes, strategy, and then beable to align their specific
strategy to some of the thingsthat we were looking for.
Right before I left, we wereworking on a a toolkit to push
out to the world.
So that, you know, organizationscan take a lot of things that

(27:18):
were top of mind for us, thatwere important, and then be able
to apply that within their ownplace.
One of the things that we heard,pretty consistently was, I would
have these conversations withpeople within the department and
they would be like userresearchers, or user designers
or product managers.
And the challenge that they hadwas they said, Savan, you know,

(27:38):
I was hired to be a designerhere, but I'm the only person
I'm on an island Leadershipwants to support me, but they
don't know how, they don't knowwhat I should be doing or what I
could be doing.
How do I sort of like get morein touch with your organization
so that we can actually start toone, give them some of the
support they need just from aleadership perspective.

(27:59):
But two, they're trying toexecute on their initiatives.
Are there ways that we canproduce, say, toolkits or
systems or design thinking thatthey 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 halfwas to establish some foundation
of what design looks like withinthe DOD, but then start to

(28:23):
identify the champions and thenroll out specific languages and
systems and infrastructure forthem to be able to take that and
champion within their ownorganization.

Paul (28:33):
It is such a common narrative that within public
service, you'll finally get ajob classification for a
designer, like the unionclassification, the

Savan Kong (28:42):
Yeah.

Paul (28:42):
ability to hire these people.
You bring them in.

Savan Kong (28:44):
Right.

Paul (28:45):
And then you don't know how to engage with them.
You don't know how to put themto work.

Savan Kong (28:49):
Yes.

Paul (28:49):
And then you get designers, the just so many
folks, just people who have adesign role who's like, I wish I
just had a seat at the tablewhere decisions were getting
made.
'cause I think I could improvethe quality of those decisions.
Then, of course, there's alsothe converse of the designers
who get a seat at the table, andthen suddenly they're exposed to
the fire hose of complexity atgovernment.
Now they're, wow.
It's overwhelming.
It's like the dog that caughtthe bus.

(29:10):
It's like,

Savan Kong (29:10):
Right.

Paul (29:11):
Oh God.
These are really wickedproblems.

Savan Kong (29:15):
Yeah.

Paul (29:16):
As designers, we have to have that deep confidence that
by bringing our process, theapparatus of design forward,

Savan Kong (29:23):
Yep.

Paul (29:23):
You have believe in design as a value, as a way of solving
problems.
How did you help folks that weremaybe siloed or, out on that
lonely island trying to figureout how to get to the table?
What are some techniques thatyou saw that maybe worked or
some narratives of peopleactually finally, getting to
that point of influence and beable to use design in the way
it's meant to be used, which isagain, solving business
problems.

Savan Kong (29:44):
Yeah, that's a great question.
You know, the DOD is veryhierarchy driven.
Right.
There's a chain of command andit's, it's probably the best,
and it, depending on who youask, maybe the worst thing about
the department.
Right.
And so for me, when I joined theDOD there's two things that I

(30:06):
wanted to do when I initiallystarted.
The first was I was just reallytrying to learn as much as
possible.
About how the organizationworks.
And then the second piece ofthat was, I wanted to be
respectful of the history thatwas there, the culture that's
there.
And you know, a lot of timeswhen you have these outsiders
coming in, they'll just wannashake things up and say, oh,

(30:27):
well we did it like this atMicrosoft or at Amazon.
It worked really well.
We should do that here.
Without really understanding thehistory behind things and how
decisions are made.
And so, I took that sameapproach when standing up CXO
was okay.
Like if we see people that arehaving a hard time like a
designer that wants to run adesign sprint, but they need to

(30:49):
be able to bring in theircustomers, right?
A lot of times the customersthat you need to talk to will be
behind a different set ofindividuals that are gate kept
or they're deployed or whateverreason.
And so, we tried really hard tobecome supporters of a lot of
those initiatives by talking totheir leadership and saying,

(31:11):
sir, ma'am, you know, there'sthis thing that's coming up and
we think it's critical becauseof X, Y, or Z, but be able to
speak in a language where theirleadership understands that they
need to make that investment ifthey want to have some sort of
return.
Many times when you are in anorganization and you are not
part of that leadership chain,your voice is really muffled,

(31:33):
right?
You don't actually have theability 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 layersthat you need to get through.
Paul, another piece of that thatI'm thinking that's really
interesting that you didn'tspecifically ask, but from a
design perspective, the questionaround having a seat at the

(31:56):
table is an interesting onebecause I get asked that a lot.
I would say from a designperspective, if you are in a
position to be promoted to arank where you are becoming a
leader in whatever industry itis I would say it's almost as
important for you to be as openand have the empathy to
understand what the businesschallenges are and be able to

(32:20):
understand why P and L isimportant, to be able to
understand why burn rate'simportant, right?
All these things thathistorically as designers you
may not have cared about, butthey do influence your ability
to be successful in that worldthat you're in.
And so I tell people that aretrying to become leaders in
either design thinking or thatdesign space that you really

(32:43):
have to understand and have agreater sense of empathy for the
entirety of that culture andthat organization for you to be
effective.

Paul (32:52):
But that goes back to your second point in terms of your
day one activities, which iswhat are your leverage points?
And I think it's such a commonerror that designers make, which
is we bring our toolkit, there'san arrogance to design,
potentially of, I have all

Savan Kong (33:07):
Yep.

Paul (33:07):
these solutions, please just let me use the solutions I
have.

Savan Kong (33:11):
Yep,

Paul (33:11):
If you don't figure out what are your leverage points,
and your leverage points arewhat does this organization
deeply care about?
What are those things that

Savan Kong (33:19):
exactly.

Paul (33:19):
this organization values, which could be hitting budgets?
Then let's figure out how designhelps you hit budgets more
effectively.
It's activating people in termsof, like, rewarding careers.
Let's figure out how to usedesign, figure out how you can
use what the organizationalready values.

Savan Kong (33:35):
Exactly.

Paul (33:35):
And then attach your work to those things.
I just love how you broughtthose two things together.
I think that's so important.
A designer who doesn'tunderstand the business and have
respect for the subject matterexperts within the business will
probably always be on thesidelines.

Savan Kong (33:49):
Yeah I, I completely agree.
And, you know I think that isthe challenge as we look ahead
of what's coming up in design,especially in federal
government, is how do we asdesigners or design thinkers in
this space, align ourselves moreclosely with outcomes whether
it's of government outcomes ascivil servants or, if you're

(34:12):
going to academia, what doesthat look like to be promoting
things that your institution'sworking on, or, in industry, how
do you actually help increasethe whatever gizmo that you're
trying to sell?
Like how do you help do thosethings?
And I think that with the adventof a lot of these AI tools,
we're starting to see the shiftof the amount of time that

(34:33):
you're spending on collateralthat you may be making to
thinking more critically.
And I think that's probably oneof the more exciting pieces of
what's coming up, is that shiftto more critical original
thought, creative thought.
It started to happen and you'respending less time in documents,
you know, on slides in Figma orPhotoshop, whatever that you're

(34:54):
doing.
And I think that's exceptionallyexciting.

Paul (34:58):
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, projectmanagement office, should not be
the rigor you apply to projects.
It should be the throughput

Savan Kong (35:10):
Yes,

Paul (35:10):
that your products produce.

Savan Kong (35:12):
I love that.

Paul (35:12):
Right?
You know, like, are you moving?
That should be the only thingthat you really care about.
And everything else, all therest of the process should serve
that goal of are we actuallygetting the work done?
Is the work moving smoothlythrough our systems?

Savan Kong (35:24):
I love that.

Paul (35:25):
You gave us a gift a few minutes ago that I wanna come
back and put some punctuationbehind.
You talked about one of yourthinking models for the design
infrastructure in anorganization.
You used three terms that Ithink are just worth just
exploring for a few minutes.
You said authoritative,sustained and scaled, and each
of those works together and eachof them is really important.

(35:46):
Can we talk about authoritativefor just a moment?

Savan Kong (35:49):
Yep.

Paul (35:49):
Because again, we build a design system, no one uses it.
You know, we

Savan Kong (35:53):
Yes.

Paul (35:53):
build content standards.
The classic, we wrote a styleguide that no one read.

Savan Kong (35:58):
Right.

Paul (35:58):
So the authority of the tooling we build for design,
could you talk a little bitabout what that journey was like
and what your experience was oftrying to build authoritative
tools within an organization orauthority?
As you said, this

Savan Kong (36:09):
Yep.

Paul (36:09):
is a highly hierarchical command control culture.

Savan Kong (36:12):
Mm-hmm.

Paul (36:12):
How do you build authority within a group like the DOD?

Savan Kong (36:16):
It's one of the hardest things.
It's also one of the things thatwill make you lose your hair the
quickest.
The thing that the departmentdoes a really good job of is
we're really good at producingdocuments.
We're really good at writingemails.
We're really good about comingup with things, right?
And everybody in the departmenthas good ideas all the time.

(36:38):
The challenge that you have isin a very hierarchy driven
organization how do you knowwith all the information that's
out there and all theinitiatives that's happening,
how do you know what toprioritize and what things to do
and what investments to make?
And that's where, the idea ofhaving authoritative

(36:59):
documentation or authoritativeinitiatives comes into place.
And what I mean by authoritativeis it has been vetted through a
formal processor system.
People have had the ability tocontribute to it in some
meaningful way.
And then at the end of the day,a signature from whoever it is,

(37:21):
in the case that I'm thinkingabout it was with Deputy
Secretary Hicks signing adocument called Fulcrum for Us.
And that was the IT advancementstrategy.
The idea of an a authoritativedocument does a couple things
for the user.
The first thing is it gives thema quick playbook to be able to
reference just in case they'retrying to do something.

(37:41):
The second thing is it givesthem 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 thisdata and be able to have some
analysis, you could then pull upsomething like Fulcrum and say,
okay, i'm gonna do the analysispiece versus going out and
sweeping the floor because thishas been sort of backed by

(38:04):
somebody that has a ton ofinfluence and sway in the
government.
And that's a very, sort of tersecomparison, but you could see
how that could play out whenyou're making investments in
either tooling or talent orprocess changes, you have to
have authoritative things tolean back to and say, okay, user
experience is important becauseit was documented here.

(38:26):
That document has also beenvetted across the entire TOT,
and this is why we should, weshould be making those
investments without like anauthoritative source.
You're not gonna be able to getany type of movement across the
department with investments.
'Cause our budget is massive,but that budget gets cut up so
quickly that.

(38:46):
If you're not in a place to haveeither backing or authority
behind it, it's not gonnahappen.

Paul (38:55):
I like that you brought the tool tooling of design, how
do we create the right message?
But it's really about hookingthe tooling of design into the
power structures within theorganization so that you have
the backing of the organization,and it's hard to do that.
So you, I would imagine, youneed to be absolutely laser
focused on what is the mostimportant piece here, which is
where I say, you know, you needto bring your design

(39:16):
prioritization of, if nothingelse is true, this must be true.

Savan Kong (39:21):
Right.
Right.

Paul (39:22):
That is a design action, of that prioritization, that
focusing work.
And then by hooking into thosepower structures, now you have
the authority of theorganization behind you.

Savan Kong (39:30):
Mm-hmm.

Paul (39:31):
And now these ideas, these concepts, this infrastructure
can travel out into theorganization and it, and it's
hard to, people won't change ifthey don't have to.
So.

Savan Kong (39:39):
Right.

Paul (39:39):
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 inthe recipe was sustained.
And I think this is so important'cause we, we

Savan Kong (39:50):
Yep.

Paul (39:51):
build things with no sense of how are we gonna keep feeding
and watering this?
You know?
So what does sustainment looklike within the organization?
How do you think about that?

Savan Kong (39:59):
I think like of all of the three things that I
talked about, I think thesustainment piece is probably
the most challenging and tricky.
I would argue that thedepartment has a pretty good
infrastructure to take in ideas,right?
We've got organizations like TIUand you know I can't remember if
we dismantled the dib, butthere's organizations that can

(40:23):
go out and look for new ideas orthat can actually start to take
in new ideas from academia andindustry.
And so the top of the funnel forthe department, I would argue
is, is not where the challengeis.
The challenge is once you'vegone through a series of either
prototypes or initiatives, howdo you actually take that and

(40:43):
then how do you apply it to agreater workforce within the
department?
Right.
And that's where the sustainmentcomes in.
It's do you have the rightfunding mechanisms to be able to
take this thing and then deployit?
Do you have the right authorityto be able to deploy this thing
behind certain environments?
Are there users like across thedepartment that are actually
gonna pick this thing up and useit?

(41:04):
Or are we just deployingsomething that somebody has
mandated, let's just say aMicrosoft teams where people
don't love it, but they don'thate 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

(41:25):
that piece of technology.
Unlike in industry, if you'relike, oh, I don't like Google
documents, I can go and justpick up Microsoft Word or
something like that and use thatto write what you wanna write.
And so the sustainment piece isa tricky facet because the
things that we use in terms ofhow do we actually consistently
improve upon this tool thatwe've deployed, but also how do

(41:46):
we actually measure what goodlooks like, right?
So that we can constantlyimprove upon that through
investments.
And it's really, really tricky.
It's, it's probably the hardestone,

Paul (41:58):
Absolutely.
You know, people love to create,they don't love to maintain.

Savan Kong (42:05):
Right?
Right.
And I think like the, the other,the other side of that is, how
do you put together a decisionframework so that if you wanna
spin something down because youknow, that it's being
discontinued, how do you dothat?
And that's a really bigchallenge, especially if you
have a user base that's as largeas the DOD.

(42:26):
And I would say, you know, justin terms of being good stewards
of taxpayers dollars, I wouldsay if this current
administration really had tofocus on one thing to do, to be
able to recuperate a lot of lostmoney in terms of investments of
tools that may or may not begreat, like that would be a good
worthwhile place to start.

Paul (42:46):
It's powerful to shut things off.

Savan Kong (42:49):
It is.

Paul (42:49):
That is a part of the playbook that's being enacted in
May of 2025 right now is a lotof things

Savan Kong (42:54):
are getting shut Right,

Paul (42:54):
off.

Savan Kong (42:55):
Right.

Paul (42:55):
and we'll see how those

Savan Kong (42:56):
Right.

Paul (42:56):
decisions are getting made.
The final piece, and DOD isprobably the most powerful lens
on this, you talked about scale,so building design,
infrastructure that can scale.

Savan Kong (43:06):
Mm-hmm.

Paul (43:07):
What did that look like for you?
What did scale mean at the DOD.

Savan Kong (43:12):
Scale for us?
I think there's a coupledifferent frames of reference
you could probably take thatthrough.
For us, within CXO specifically,we looked at problems that were
not specific to a defense agencyor through one of the major
service branches.
So for us, scale always meant isthe thing that we're investing

(43:35):
in going to be impacting a largeamount of people that is
agnostic of your organization,right?
Can we actually take whateverthis is, let's just say it's the
latest version of Eternity forcapturing user metrics and
performance metrics.
And then can we apply thatacross the organization so that

(43:55):
we can actually.
Start to understand what thepicture looks, like and have
that same sort of consistentframe of reference.
I'll give you an example of thisas well.
When we were asking for metricsfrom the different
organizations, we said, we wannasee where you guys are now with
this benchmark, for thisspecific thing.
I won't get into the exactmetrics, but, we had a wide

(44:18):
variety of different answersacross the board.
And the reason being was becausethere were different tools that
people were using that haddifferent definitions of what
success looked like and theywere talking to very different
user groups and a user base.
So the idea of scaling is notjust the quantity of people that

(44:38):
you were trying to, solve for,but it's really sort of doing it
in a way where we can start tonormalize the conversation of
what it is the expectationswere, and then what we expect in
terms of outputs from thedifferent organizations.
That's both toolingconversations, that's policy
conversations is this policyreally just for this specific

(45:01):
organization?
And then that's also thestrategy piece.
So when we actually releasedFulcrum, that's not just a CIO
strategy piece, that's aDepartment of Defense.
So now you Navy, you Air Force,you take a look at this document
that is a DOD wide document, youthen go and you write your own.
But it has to align to thesethings that we've written here.

Paul (45:23):
One of my favorite quotes comes from Don Norman, who's
sort of one half of the NielsenNorman Group, the legendary UX
consultancy, and he

Savan Kong (45:30):
Yep.

Paul (45:30):
defines user experience design.
I can't do a British accent, butI assume this sounds better,
with a British accent, but hesays, user experience design is
the elimination of fuss andbother.

Savan Kong (45:40):
Mm.
I love that.

Paul (45:41):
What you just described, for scale can be architectural,
et cetera, but can things growand go, like, have you sanded
off all the rough edges?
The wonderful way you talkedabout these three principles is
for, authority and sustainmentand scale, you talked about
using the toolkit of design.
To address the design toolkititself, of need these things to
be hooked into what's mostessential for the organization.

(46:03):
We need these things to havesupport and understand what will
take to keep feeding andwatering these things.
And then we need to build thesein a way that they can go out
and do the work without a humanhaving to be there to keep
pedaling that bike forward.
These things are so welldesigned we've eliminated all
the friction to adoption.

Savan Kong (46:20):
Yeah.

Paul (46:21):
They just work, this way works better than other ways.
You know you will

Savan Kong (46:24):
Yeah.

Paul (46:24):
get better outcomes.
To the designers listening tothis, saying, how do I get to
the table?
You already should have thetools.

Savan Kong (46:32):
Right.

Paul (46:33):
To bring design to the table.
Savan, this is a great recipefor how to build the design
infrastructure into the mostcomplex government organization.
I can imagine the Department ofDefense of the United States
government.
What

Savan Kong (46:46):
Yeah,

Paul (46:47):
powerful mission you've been on.

Savan Kong (46:48):
I appreciate that.
It has definitely beenchallenging, but also really
fun, right?
It's also a really fun job.

Paul (46:56):
Again, I'd encourage anybody who wants to sort of
think more about this andthrough that the military lens,
General McChrystal's book Teamof Teams is a different context,
a different set of problems.
So a lot of similarities betweenwhat you and I just talked about
here and the ideas you broughtto 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 morehuman level, for those folks who

(47:19):
are struggling, who are in thethick of it, who are trying what
kept you going?
You talked about the fun of it,and the,

Savan Kong (47:24):
Yeah.

Paul (47:25):
joy of solving problems, but what for you was the
motivation to do this reallyhard work?

Savan Kong (47:31):
I'm by nature a constant learner.
Every single one of these jobsI've been fortunate with, i've
worked in slightly differentcapacities.
I've never sort of worked inpolicy in a policy shop.
I didn't know the first thingabout it before jumping in.
And you know, I thought that wasfun, right?
And then before that neverworked in the department.
And I thought that was fun too.

(47:51):
It's like, okay, you're goingand you're learning something
different.
And you know, I had the pleasureof 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 youtake doesn't define you.
Like your major doesn't defineyou.
Just because you're in marketingdoesn't mean you're doing
marketing.
It's really just a steppingstone to whatever it is that

(48:15):
gets you exceptionally excitedto wake up every day.
And I think, for me, I've beenfortunate enough now to have at
least a foundation or a basis ofdesign thinking that I could
take to any industry andanywhere in the world and apply
that and hopefully help theseorganizations become a lot more

(48:36):
positive once I've left in someways.
Whether that's through workingat a place where I'm actually
building things with softwaredesign and designers, or whether
that's through writing policy orwhether that's just looking at
business operations.
I think the art of thinkingthrough critical things
intentionally and trying tounderstand the problems is the

(48:57):
same regardless of where you'reat.
But you know, being able to dothat and have people take that
chance to hire you to do thosethings and learn those things
really gets me excited, now I'mat this crossroads in my life
where I'm trying to figure outwhat I want to do when I grow
up.
And I keep going back to, Iwanna be at a place where I am
constantly being challenged andI can still apply the things

(49:19):
that I've learned.
But I also wanna learn newthings.
I don't wanna do the same thingI was doing back when I was 27,
28.
Right.
That'd be boring.

Paul (49:27):
The world is full of problems and opportunities

Savan Kong (49:29):
Yeah.

Paul (49:29):
and design is the toolkit to approach them well among
other toolkits.
I

Savan Kong (49:34):
Absolutely.

Paul (49:35):
thank you so much Savan, for sharing your experience with
us today and I can't wait tohear what you do next.

Savan Kong (49:42):
Me too.
I'll let you know when thathappens.
Thanks, Paul.
I appreciate you.

Paul (49:49):
Thanks for joining Savan and I for this conversation, and
thanks to Savan Kong for sharinghis unbelievably unique
experience of the DOD with us.
There are a few bigger or morecomplex organizations in the
world, than the US Department ofDefense, but the model that
Savan brought to building outdesign infrastructure is robust
and simple enough that I'mconfident you can adopt it as a

(50:11):
design leader in yourorganization.
The recipe this event brought tobringing design into the public
service is one, build youralliances.
You're going to need support,champions, a team, and to win
hearts and minds.
Start by understanding who hasinfluence, build relationships,
and create your partnerships.
If you want to go fast, goalone.

(50:32):
If you want to go far, gotogether.
Two, find your leverage points.
If you want to create change,then learn what the cultural and
strategic values of theorganization already are.
Then use those as leveragepoints to amplify the importance
of design and use design tosolve the problems that the
organization already caresabout.

(50:54):
This will create a tailwind foryour work.
Three, define your measures.
If you want the organization tovalue design, then learn how to
measure the value that designproduces.
And if it's connected to theleverage points you've
identified, you'll build supportnaturally.
Four, develop your designinfrastructure.

(51:15):
This is the most importantcomponent 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 theorganization starts to value
design, the work can grow.
With regards to designinfrastructure, Savan also gave

(51:36):
us a second model that I thinkis very useful.
Your design infrastructure needsto be authoritative, sustained
and scalable.
Authority is essential becausechange doesn't happen without
top down support.
Find out where the powerstructures and points of
influence are and connect yourinfrastructure there.
Sustainment means ongoingresourcing and support,

(51:59):
design work
is evergreen, so be sure to clearly articulate the
business value in measurableterms, and advocate for ongoing
resourcing and budgets, not justone-off projects.
Scalability is where design cantruly shine.
Learn about the barriers toadoption and bring your design
toolkit to the toolkit ofdesign.

(52:19):
Remove barriers, improveprocesses, make better tools.
Design is the goal, but also thepath.
With the current USadministration agenda, many
great people have been let go,Savan being one of them.
But I can't wait to see wherehe's gonna land next.
His thinking will benefit anyorganization that takes him on.

(52:41):
I hope you enjoy thisconversation.
Please do subscribe and followus.
For more, I'd like to thank mycolleagues who work with me on
this podcast.
Kathy Watton is our showproducer and editor, Frederick
Brummer and Ahmed khalil createdour theme music and intro.
We're gonna keep havingconversations like this.
Thanks for tuning in.
If you've got ideas for guests,we should speak to, send us an

(53:03):
email to [e-mail].
The public service is about allof us, and when done right,
digital can
be a key ingredient for a better world.
This has been The 311 Podcastand I've been your host, Paul
Bellows.