launch

Dana Chisnell

‘This Was Really About Culture Change’: Dana Chisnell on the U.S. Digital Service Realizing Its True Calling

Dana Chisnell was a user research and civic design consultant at the U.S. Digital Service from 2014 to 2016. She returned to USDS from February 2021 to September 2023. Dana is the co-founder of the Center for Civic Design.

Dana Chisnell spent her first stint at the U.S. Digital Service embedded within the U.S. Citizenship and Immigration Services (USCIS), contributing user experience design and research expertise. 

As her time with the organization progressed, Dana and the team learned how they could be most valuable within the federal government: Not necessarily by putting out fires, but rather by shifting the culture in a more intentional, design-oriented direction. 

Below, Dana speaks about building professional communities within the White House and an auspicious first meeting with President Obama.


June 28, 2019

Emily Tavoulareas:

Dana, tell us how you got to the U.S. Digital Service.

Dana Chisnell:

I was mostly working in the private sector as a user experience designer and researcher. But I had got this bug about design in election administration in the early 2000s and got curious about how elections were run. And in 2012, a bunch of people got together, led by me and my friend Cyd Harrell, who later was chief of staff at 18F.

We ran a study where we looked at county election websites and what voters’ questions were. It turned out to be really interesting for a variety of reasons. I was going around giving talks about this study, including one that I gave in September of 2013 to the first cohort of Presidential Innovation Fellows and other folks. Erie came up to me afterward and said, “So if we just create a style guide for federal websites and make everybody use it, will that make government better?” And I said, “That is a horrible idea that will never work.” [Laughs.] She and I and a bunch of us ended up at Shake Shack, talking about how tech and design in government seemed way behind the private sector. 

A year later, in August 2014, I got a call from Erie. She said, “You’re going to get an email. I want you to come to a thing. It’s going to be at the White House. I can’t really tell you what it is, but you really want to be there.” 

The email was from Todd Park and had instructions for getting into the Eisenhower Executive Office Building (EEOB). A day of meetings is laid out. I had an interview with Aaron Snow and Hillary Hartley about possibly working with 18F. And I had an interview with Todd Park. He said, “What do you want to do?” I replied, “I don’t even know what this event is. What is happening right now?” I am not convinced anybody at that event knew what was going to happen.

At that event were Eric Hysen, Ginny Hunt, Lisa Gelobter, Dave Recordon, Megan Smith, and a couple of other people who joined in the early days. I had met Eric and Ginny before in the election space when they were working for Google.org. The people attending this event – what turned out the be the first roundtable that led to the U.S. Digital Service – were all tech and data nerds from Silicon Valley, and I’m a designer not from Silicon Valley. I thought, “This is weird and I don’t understand what’s happening here.”

It was a very complicated, but fascinating, day. There was one session with Tom Kalil about innovation and data and tech and government. Another engineer from a big tech company was very confidently holding forth about all the things government should be doing with data. I thought, “I don’t belong here.”

Emily:

Why did you feel like you did not belong there? 

Dana:

There was no discussion about the experience the public was having with government. It was all about tech, all about data. I was like, “You can talk about open data all you want, but if the data is crap to begin with and it’s not a format that can be used, it’s not going to help anybody. Silicon Valley is not going to work here.” Little did I know I was about to face two years of that. 

So we get about two thirds of the way through the day. They round everybody up and say, “We’re going across the street to the West Wing.” I thought, “I wonder if we’re going to meet the President. Probably not, because this is just a tiny little weird old tech meeting.”

We arrived at the Roosevelt Conference Room. Erie’s over in one corner, and Charles was in another, and Jennifer Anastasoff is there. Mikey Dickerson’s there, too. I hadn’t met Mikey before. And Todd is holding forth. He’s sitting in the President’s chair. About 10 minutes into that, the President came into the room. There’s standing and much applause.

Todd gets out of the President’s chair and President Obama sits down. He said that he was not excited about how HealthCare.gov rolled out, the most important policy position of his entire administration. It helped him realize that delivering services to the public over the public internet was going to be a really important part of the way government operated from that point forward.

At the time, there were countless other projects that looked very much like HealthCare.gov in the federal government. And the success of the rescue team — who came in with private sector practices from the 21st century — was a pattern that he wanted to formalize. In case we hadn’t realized it, we were there because he wanted us to come work for him. If family needed convincing, he would pick up the phone and talk to spouses, talk to children.

Emily:

You did not know what the purpose of the meeting was going into it, right?

Dana:

I really didn’t. But before I left for D.C., my husband Jared had seen the email. He said, “You’re going to be recruited for something.” I was like, “No. They don’t want me for anything.” My co-director at the Center for Civic Design had been at the White House two weeks before for a data jam that Erie ran, about open data from the Bureau of Labor Statistics. When I was talking to her about it, she said, “It’s probably one of those things.” 

Anyway, 45 minutes after arriving, the President leaves for a press conference. He was only supposed to stay for about 10 minutes. There were so many interesting things about this. First of all, he comes in one door and his scheduler or his assistant comes into the other door. She pops him a folder with talking points. And he just chucks that right away and talks extemporaneously for 45 minutes. Most of us were dumbstruck. Then he shakes everybody’s hands and he leaves and goes and does a 90-minute press conference. And we’re embargoed, because the formation of the Digital Service hadn’t been announced yet. So we couldn’t tell anybody who was in the room or what happened.

We had to surrender our devices before we went into the room, too. As soon as we left, everybody grabbed their stuff out of the cabinet. Steve VanRoekel, who was the Chief Information Officer (CIO) at the time, walks us over to Jackson Place. He says, “This building is condemned, but the General Services Administration (GSA) owns it. So we’re going to do a little renovation and put the Digital Service here.”

The building was damaged in the earthquake, and GSA closed down the main floor and the basement instead of fixing it. So it seemed like, “This great space is really close to the White House, isn’t it awesome?”

We all sat around the table for a bit. There wasn’t any equipment yet. Todd starts going around the table saying, “Are you in? Are you in? Are you in?” And then I got on a plane and I went back to Boston. When I got home, I told my husband. We’d just got married in June.

He said, “You know you have to do this.” I’m like, “A, we just got married. And B, I just started a company last year.” He said, “Yeah, but you can go for a few months and then come back.” So I started October 21, 2014, expecting to scrub in for 3 months. I actually showed up a couple days early. There were not many people there. Nothing was organized yet. 

Emily:

I love the “yet.” It wasn’t organized — yet.

Dana:

That took about a year. There wasn’t a computer for me, but I was expecting that. There were just a bunch of people scrambling. There were three projects going on. One was HealthCare.gov preparing for the second open enrollment. They were already entrenched, and that was not an option that was given to me. Also, the user interface was not the thing they cared about at the time — they were just trying to keep the servers up. There was another project with the Department of Veterans Affairs (VA) because in August of 2014, Congress had passed the Veterans Choice Act, a law that allowed veterans to use their benefits outside of the VA.

It would go into effect on Veterans Day 2014, but nobody had done anything about implementing it. There was a big scramble to figure out how to let veterans know that they could do this and what the rules were. This is where we find out there are a lot of different databases spread out across the VA and none of them match up, and nobody knows who’s enrolled in anything.

Then there was immigration. The President was going to take executive action on Deferred Action for Childhood Arrivals (DACA) and U.S. Citizenship and Immigration Services (USCIS) had been trying to develop their own software for a couple of years in their own digital transformation. They were moving from Waterfall to Agile, and there were a lot of challenges. In anticipation of this executive order, the White House wanted a Digital Service team at USCIS to help them get ready for big growth in the numbers for the DACA expansion and the deferred action for parents, which was the other part of the program. That was all stopped in a lawsuit later, just before we were ready to press the button. Twenty six states sued the federal government.

I got a call from Vivian and Brian while I was deciding whether to join, and the immigration work seemed to be the best defined and a project where I felt like I could do the most good.

I showed up and there were two project plans: One for helping USCIS work on DACA and the other to get them to press the button on green card renewals, which it turns out they had tried four or five other times and weren’t ready for whatever reason. So we went on a deep dive into a brand new domain and in an organization that doesn’t know anything about user-centered design, doesn’t know much about tech, really. It’s a bunch of people at USCIS who’ve never made software themselves before. 

Vivian is a really great policy person. Her background in tech with her policy work was a phenomenal combination to add to this particular team. And Brian, I learned later, had already been at USCIS for some weeks. He’d shown up in July. He and I got along immediately. We understood each other right away. I loved working with that little team.

Emily:

When did you make the decision to focus on USCIS?

Dana:

That was really in the first couple of days that I was there. The team was working on a plan to get the I-90 green card renewal stuff rolled out at USCIS and starting to look at what it would take to implement DACA in the system called ELIS. And I was like, “I know about project plans, let’s talk about that.” Next thing I knew, I was on the team and showing up to do user research.

Emily:

At that time, as you said, USDS was very nascent — a lot of things were not set up yet. How would you describe USDS at that stage?

Dana:

I’m trying to think of what I told my mother when I called her. I remember talking to people about it: “Hey, that thing that happened with HealthCare.gov where a bunch of people came from the private sector to help fix it? Now there’s a team that does that throughout government, and I’m going to be doing it at immigration.” It was very much about firefighting. Words like “modernizing tech” were not a thing yet. That was not a message that we were talking about. It was about fixing problems.

We had an offsite my first week, and that was Matthew Weaver’s first day. The group had a conversation: What do we want to do? How do we want to do it? And how do we talk about it? Because it wasn’t like anything else that was happening anywhere, especially government. What I told people at the time was, “I am going to work for the Obama White House to try to fix the experience that the American public has with government.” It was really that vague.

I was pushing a lot: “Can we please not talk about tech?” But the messaging was definitely fixing technology in government. Later, I realized that the technology and engineering processes had to be addressed before anyone could focus on the experience of internal or external users. 

Emily:

Did your perception or your definition of USDS evolve over time?

Dana:

For sure. But it’s still a very difficult thing to describe to people who were not in it. I still have a hard time. I’m pretty sure that my [then] co-director still does not understand what I was doing there.

Emily:

What was so challenging about that?

Dana:

It was a very different way of working from what most of us had seen in the private sector. We had this challenge as we were hiring in describing the work and setting expectations. I would recruit all of these brilliant designers and they would say, “It’d be great. I want to come into an agency. I want to build this team.” I’m like, “Yeah, it’s not going to be like that. We want people who have excellent technical skills, but also brilliant leadership skills. You’re going to bring your tech skills and not get to use them. You’re going to use them to teach other people how to do this work. We’re going to build capacity inside government.”

Emily:

It sounds like at some point, you realize this is not actually about designing. It’s getting others to understand and/or do it. When did that light bulb go off?

Dana:

Well, there was an advantage of starting out at USCIS and their not knowing anything about user-centered design at all — not even the concepts — and there being 100 developers making software and no designers. There was no way I could do all the design that there was to do. All I could do is make everybody in that organization a better designer.

I had also had the experience in my work with election administrators across the country of creating tools, templates, and guidelines for _them_ to follow to do better design, themselves. Turns out that experience was transferable to what I was doing at USDS. 

With Eric, we had a lot of discussions at USCIS about the USDS engineers not doing the work, but leading the developers at USCIS to do better work. That meant getting a lot of career feds who were project managers before to own and learn more of the technical skills of managing a big product, knowing what you were getting from your team, from your developers, from your contractors. A bunch of the teams came to the same conclusions: That this was not about doing the fixing ourselves, but helping other people learn how to fix the problems. 

Emily:

In such an engineering-heavy culture, what was it like to try and build out the design capacity?

Dana:

It was awesome, actually. I had worked in software development for decades, so I had no fear of that part. Working with developers and engineers was something I was really used to. The challenge was leadership at the agency that was not technical and didn’t value design. So there wasn’t any formal way that I could insert a design practice or help people do better design. I had to do everything by informal influence.

On the Digital Service side, I had the advantage that every engineer I ever worked with came from someplace where user-centered design and human-centered design were in the company culture. Amazon, Google, Stripe — those companies all had designers and researchers. So when the engineers came to the Digital Service, they were like, “Where are all the researchers? Where are all the designers?” And I was like, “You get to help me do this.”

And they did. This was where we got the “generalist problem solver” definition. Whatever needed to be done, whoever was available to do it, went and did it. All of the engineers who I worked with were awesome. I remember one episode where I was traveling, and there was this particular workshop with the front-end developers and the product owner to identify gaps in a workflow design. My original plan was to run this as a design studio, but I couldn’t be there. Nick Leseki and Victor Garcia were there, and I said, “Hey, you guys know enough to do this. Can you facilitate?” And they were like, “Uh, okay.”

They did it and it ended up being wildly successful. And it was because A, they came from a culture where doing that kind of activity was normal, and B, they were game for doing whatever needed to be done. So I had a lot of support from the Digital Service team that I worked with. I love them.

Emily:

You all had a really solid team. I’m curious about value and prioritization of design as part of the operations and hiring. How was that within USDS?

Dana:

The early days of USDS had site reliability engineers, including the first Administrator. Agencies all over the federal government couldn’t keep their servers up. So dealing with that made a lot of sense. At the end of the first year when we had 60 engineers and maybe five designers, that ratio still made sense. Honestly, there wasn’t that much design work to do, because if you can’t keep the system up, that’s part of the user experience. I remember this tense conversation with the Talent team about how we needed to stop talking about tech all the time. But because the tech was the user experience, and if you can’t keep that stuff up, it doesn’t matter how good or bad the user interface is. When you start to solve the layering problems of keeping the servers up and getting a stable technology stack and making sure that the platforms all work, then you can start to think about how good or bad the software and the user experience are. It was a solid year before anybody said, “Okay, we probably need some designers now.” 

Kathy:

Dana, do you think the hiring priorities changed over time?

Dana:

I do. The Talent team started to realize how all the things fit together. As other teams came on, like the VA team, they had designers. That made a difference in the trajectory and the success of those teams. Although the first months were rocky. Over a few years, the way that cross-functional Digital Service teams worked was an essential element in the longer-term evolution of what “modernizing” technology means. Then, it was about replacing legacy systems. Now it includes service design and not just delivery.

Emily:

And as that shifted, it also raised questions of “How do we organize ourselves? How do we structure ourselves as this team is growing and what we need is becoming more clear?” How did the design community evolve? 

Dana:

We reached some critical mass where there were enough people who needed some kind of structure. It was clear we were not going to be managed. Everybody was told upfront, “You’re here, you’re leaders, self-organize, get the stuff done. You’re not going to get performance reviews. I’m not going to manage you.” 

By then 18F already had guilds. They had developed this mechanism for getting like people together to teach one another and for therapy and all the things that smaller communities get together for. We felt like we needed to do that, too. We set up norms around who was going to be in which groups, which we ultimately labeled “communities of practice,” because some of the positions were so undefined. It’s pretty clear who was an engineer, but after that, who’s a bureaucracy hacker and who’s the designer? Can you go to the other Communities of Practice (COP) meetings? What are you supposed to do in them? The design COP was fairly informal, but it felt compulsory. I at least felt like I had a duty to be there.

Emily:

Where did the compulsory feeling come from?

Dana:

I wanted to know what other people were working on. I wanted to see what challenges they were encountering. And I wanted to help some of the new people understand what the work really was and how to do it. But it didn’t really feel like that much of a community for me. 

Emily:

One of the themes across the interviews is this tension between the obvious need to organize ourselves in some form, and the resistance against it. From your vantage point, both at USCIS and the design community, what did that look like?

Dana:

It was mostly growing pains. The Digital Service team at USCIS was a tight unit. We worked really well together, we were friends. I didn’t feel like I needed a lot in the way of support, but I was curious about what else was going on. There were people who were not working for the USCIS team who I really wanted to know and hang out with and learn from. That was my personal motivation for spending time at the mothership and the COP. 

Now, imagine that you bring together 100 people who you specifically recruited because they are leaders, type-A, and startup-y folks, and then tell them to self-organize and “you’re not going to be managed.” Then you get to a point like, “Now we need to get organized and establish some norms and grow up a little bit and create a less —” I don’t know, fraternity-like environment… Maybe that’s not the right word.

We had a lot of work to do and we had to build infrastructure for ourselves, including hiring. There were a bunch of people at HQ all the time and these teams out in the world, and then there were enough people who were not engineers that we needed some way to give them support. We had to try something more managed, that would give people an anchor and would bring the teams in agencies back to the mothership.

That was painful for everybody because it was mostly an experiment, and there was this temporary feel about it. Toward the middle of my second year I said to Mikey, “I want to develop this elite team of user researchers who work on policy problems.” And he replied, “That’s a really great idea. But I don’t know if we’re going to exist after 2016. I’m working on trying to make the Digital Service a permanent thing, but I don’t know what’s going to happen. So I’m going to say no.” 

There were all these layers of growth: getting things done, building infrastructure, trying to help people feel like they were supported in very stressful, very challenging situations, and trying to establish the Digital Service as a real thing that was going to last longer than the Obama Administration. It was nuts. 

That’s a really long answer. It was all growing pains. Everything an organization goes through when the culture changes from 10 people to 100 people in a year — I don’t know if there is any graceful way to do that. 

Emily:

Are there pivotal milestones in USDS’s evolution that you may not have noticed at the time?

Dana:

A big one for the Digital Service at USCIS was the case against the President expanding DACA. It basically stopped the reason that we were at USCIS to begin with, and we ended up in a team meeting with the deputy chief of staff, Kristie Canegallo, to figure out what to do next. There were 10 of us in this tiny little cramped office, and we’re like, “Okay, the reason that we were put there is gone. What do we do now? Do we stay or do we go?”

For that team, and probably for the Digital Service at large, it was a pivotal point. We figured out who we were and what the work was. We stopped being a firefighting team, at least at USCIS, and became a Digital Services team that could actually bring 21st-century practices to an agency through tech and design in an on-going way. That is really when we embedded and committed and built different kinds of relationships in the agency.

It was not about digital transformation. This was not about 21st-century technology. This was really about culture change.

Emily:

Thank you so much for your time, Dana.