Brian Lefler
‘There Was No Script – Just a Sense of Importance’: Brian Lefler on Helping Develop A Theory of Change
| Brian Lefler was an engineer and founding member at the U.S. Digital Service, active from 2014 to 2017. Prior, Brian was a senior software engineer and site reliability engineer at Google, and a software development engineer at Amazon. |
Brian Lefler was one of the earliest members of the U.S. Digital Service, embedding across a range of federal agencies to help untangle complex technical problems. He was one of a handful of Google engineers who joined the fledgling USDS before it formally launched.
Brian’s work spanned the U.S. Citizenship and Immigration Services (USCIS), the Department of Defense (DOD), and the Internal Revenue Service (IRS). Throughout each engagement, he prioritized discovery sprints, relationships, and projects with the potential to meaningfully impact peoples’ lives.
Below, Brian discusses working without a playbook, the importance of feedback loops, and the qualities of a successful USDS staffer.
January 28, 2025
Emily Tavoulareas:
Brian, how did you get to the U.S. Digital Service?
Brian Lefler:
I was at Google working on Maps. I had recently come from site reliability engineering, where Mikey Dickerson had been my grand boss. He vanished one day – and then I learned where to from the cover of Time magazine.
When Mikey came back to Google, he and some others gave a talk about the Healthcare.gov story. “You’ll laugh, you’ll cry, you’ll throw up in your mouth a little bit,” was the talk’s tagline. It was so popular that they did an encore. I didn’t see either of the talks, but I heard about them. And I took away a very basic statement: They needed help to do more of this work, and it didn’t require a unique set of skills. I knew Mikey Dickerson and I admired him, but I didn’t hold him up as a superhero: He was just a darn good engineer.
Healthcare.gov – a signature presidential initiative, the administration’s most important project – fell over because of a technology problem. It’s not like a contract went to one corrupt official with one corrupt contracting officer. There was something systemic at play – and that tells you it’s happening on all the other projects, too. I heard there was a need, and I imagined myself able to help. That’s why I volunteered.
In spring 2014, I sent Mikey a very short email: “When you took a sabbatical for Healthcare.gov, I thought it was a tremendous thing at the time, and still do. I also thought it was hopeless, but your team story has convinced me otherwise. I will do an up to six month repair mission if there’s space on a team and an opportunity to save lives. I want to do something, but I don’t know how to plug in effectively.” I also shared my experience at Amazon and Google with Mikey.
Emily:
What happened next?
Brian:
In May I decided to go, and I was in Washington, D.C. less than a month later.
After I got approval to go do this, I furiously lobbied my favorite engineer from a recent team I’d been on, Hannah Tang, to join me. After several weeks badgering her about the opportunity to save lives, she said it wasn’t the right time and recommended her husband instead. Her husband was Albert Wong, another Googler.
Emily:
Tell me more about your expectations coming into USDS.
Brian:
I volunteered for up to six months because I thought a thousand Google engineers were going to volunteer, too. I assumed if I volunteered for more time I would make the final list. That was my logic, which was wildly optimistic.
I knew by the time I showed up on June 9 that I was going to go work at the Department of Veterans Affairs (VA), and then from there I would work at the U.S. Citizenship and Immigration Services (USCIS) for a two-week sprint with Albert, Mollie Ruskin, Amélie Koran, and Charles Worthington.
I actually got there a week early. I went to the VA and the Department of Defense (DOD) and talked to a few key people about the treatment record problem and how I was going to help figure it out.
But that was diverted because after the two weeks at USCIS, it was clear we could continue to make a difference there. They had been very receptive to our work at all levels, not just at the top. It was also clear that our USCIS report was not going to be helpful without follow up. So I thought, “I should probably do this instead.”
Emily:
Did you know when you started the discovery sprint that it was going to need follow up? Or did you realize during the process?
Brian:
I did not know going in. There was no playbook. We were just going to figure it out with a very slight bit of information from the previous folks who had come in and done sprints. I didn’t expect to stick around, and that wasn’t a call I made until the end of those two weeks.
The system we were looking at was called ELIS 2, and it was part of the USCIS ELIS (Electronic Immigration System) program. ELIS was a very expensive system that was not working. They were going to have to turn it off; the writing was on the wall.
ELIS 2 was a phoenix from the ashes. Could Immigration take that same contracting structure and with a little bit of money left in the couch cushions, build a real system? That’ll work. Our motivation was to assess things honestly.
Emily:
So this is all happening summer of 2014. The momentum for USDS was building. I’m curious to hear your memories of that time beyond the USCIS team.
Brian:
It was clear that something was shaping up, but I didn’t know that Mikey was going to lead it. We had office space at Jackson Place. I met Erie Meyer and Haley Van Dyck; they were advocates for this work.
Emily:
So you’re hearing murmurings about USDS and slowly connecting to the people who are involved. What was your impression?
Brian:
I knew that Jen Pahlka had a proposal called GovX. There was originally a notion that it was going to be a two-body organization: The General Services Administration (GSA) for implementation, the White House for policy, and the two bodies would closely interact. Are you familiar with this proposal?
Emily:
Oh that’s interesting… that’s a separation Jen writes about in her book, one that is a central problem with technology and government. The thesis of her book is about the separation of implementation and policy. I’ve never heard the GSA-White House split described that way.
Brian:
It made sense from one perspective: The White House is going to have priorities, dictate terms, and sign deals and interagency agreements. And GSA is going to be cost reimbursable and operate more as an internal contractor.
But that deal fell apart shortly before I showed up. When GSA launched 18F in March 2014, I believe that was essentially a declaration that GSA didn’t have to care about this other organization being built in the White House – they were just going to do general services contracting.
Around this time we did our USCIS sprint, and it was a very busy two weeks. We were rewriting and sharing notes every day. We worked hard to pound out the report and turned it in. And then Charles goes back to the Office of Science and Technology Policy (OSTP), Albert goes back to Google, and so on. When we delivered the report I said I could continue to provide assistance, but there was no larger group. That Monday, I called a career fed at USCIS to let me into the building and sat at an empty cubicle. But I did this every single day for weeks. I would occasionally go back to Jackson Place to keep in touch with someone like Charles, Ryan, or Erie, who were more connected to USDS. But mostly I was at USCIS. I was not involved in spinning USDS HQ up. My job was to make our first extended field operation successful.
Emily:
One of the themes from all of these interviews has been the power of the discovery sprint. It’s this replicable process that shows up everywhere. The one you worked on in June 2014 was the third. It sounds like by that time, they had learned a few lessons. Can you tell us more?
Brian:
“They” as a collective didn’t exist. No one had written any distilled wisdom. I read a report and thought, “Oh, this might be how you write a report.” I heard some negative feedback on one of the reports and thought, “Oh, I should be more careful.” That was the extent.
In the weeks prior to us showing up, USCIS Chief Information Officer (CIO) Mark Schwartz sent us some questions: What do we need to do to make sure we’re ready for comprehensive immigration reform? How do we accelerate productivity? How can we improve the product definition process? Is our tech stack serving our needs? What should our next steps be in moving towards a best practice DevOps approach?
Mark Schwartz had really stuck his neck out to do agile things on a project that had a terrible record. So I also understood the assignment was to assess whether his approach had a credible path forward. Mark Schwartz earnestly wanted to do better. We felt a lot of pressure to get it right, because we understood it was consequential to have the White House come in and give you a report card. Beyond that there was no script – just a sense of importance and gravity and humility. So we talked to people who were there. We asked them what was going well and what was not.
Emily:
How did you decide who to speak with?
Brian:
And after we talked to one person, we’d ask that person who else we should talk to. There were two buildings where all of this was happening – the contractor site and the government office – so it was pretty easy to cover all the ground.
Emily:
Looking back, what do you think worked well about the discovery sprint process, and not necessarily just at USCIS?
Brian:
It was good that we knew and respected the assignment: to do an assessment where the people on the ground largely have the knowledge. It was good that we, coming from Google and the White House, brought a lot of high hopes and prestige and expectations and openness. They weren’t defensive; it was a group that did want advice and feedback. The fact that we set our own trajectory, ran around and talked to everybody, and then combined notes at the end of the day was useful.
We didn’t get everything 100 percent right. We would go on to completely replace the login system for ELIS before launch, but that need wasn’t in the report.
Emily:
I want to flash forward: Tell us about your trajectory at USDS and what you worked on. You came in for this presumably temporary assignment and didn’t know what to expect. How long did you end up staying?
Brian:
Three years full time, more if you include part time. I did a discovery sprint at the DOD and stuck around for a year. Then I went to the Internal Revenue Service (IRS) for a year. I also did short action at 11 CFO Act agencies. Something would come up and we’d check it out for a week or two. If I was available and they needed someone seasoned, I would help. For example, the FAA drone site needed proofing before it went live, and that took two days.
Emily:
A lot of people in USDS had a particular purview. But your experience at USDS entailed plugging in for a short amount of time and then moving to the next thing. I’m curious how that worked operationally within USCIS.
Brian:
There were long assignments and short assignments. I moved when I sensed I would be more useful in another project. At USCIS, we had gotten fairly stable. We went from one to about six people over the course of that year. The Deferred Action for Parents of Americans (DAPA) executive order got paused by the Supreme Court and then eventually killed.
Ultimately, I left because Mikey was planning to pick someone to be the head of the USDS effort at USCIS and make it a more permanent initiative. I wasn’t wild about agency teams as a concept. I had the incorrect view that you could have five equals running around managing their own schedules and their own priorities. That was working for us, but only because we were incredibly senior people taking a hiatus out from our other life. I had the Google mindset that hierarchy is bad culturally, but I don’t think that was justified.
So I went to a new team at the DOD and spent six months on service treatment records. We succeeded: that system was quite stable by the end of our time. Then they began building the Defense Digital Service as a permanent entity with a more clear portfolio, so I went to the IRS for a year. I ended up leading that team for a period. I learned the lesson from several years earlier: If I say no to this job, then who ends up leading it?
Emily:
The IRS is fundamentally different on so many levels from other parts of the U.S. government. What was your mandate when you were there?
Brian:
We had a clear mandate. There was a 2015 hack of the IRS where potentially 700,000 taxpayer transcripts were exfiltrated from the agency. They had a system for accessing your transcript, but the system had flaws that allowed people to impersonate others. So someone could steal transcripts, file fake returns that result in a tax refund, and route that refund to the bank account of their choosing.
The U.S. government learned that more than 100,000 tax returns were stolen and used to claim over $50 million over several months from this one incident. And the incident was actually seven times larger than was known at the time – so $350 million in tax fraud.
At some point, because of the sheer volume of the fraud, they stole the identity of an IRS employee. That kicked off the internal investigation where they realized a 3,700% increase in the number of taxpayers requesting transcripts. So to be clear, the system was almost entirely being used for fraud. It was a tiny minority of time being used for its legitimate purpose – which also tells you about the lack of system awareness and anomaly detection.
Emily:
Was that fixed?
Brian:
By the time we were done, yes. I feel quite good about the system and the ownership we left behind.
At first they just turned off the “Get transcript” functionality. “Go talk to TurboTax or H&R Block and have them request your transcripts, and maybe we’ll accept it – but only if you go through one of these gatekeepers.”
We wanted to turn it back on. The project was called Secure Access, and it started before I got there. About six months after I joined, we had replaced the system. We added new checks. I had a fun week reproducing the existing hack and showing that it didn’t work anymore.
After that, we had wind in our sails. Next were projects to improve the information architecture of irs.gov. And we had a project for online accounts. Once users log in, could we give them something that doesn’t look like a mainframe? We saw that through. But it was definitely clear that they didn’t have a Mark Schwartz. The IRS culture is much more risk averse, which is justified by their mission, but it makes it harder to do stuff. At USDS I learned you can have the best people in the world, but if you put them on a project where no one cares if it succeeds, then they may not succeed.
Emily:
You’ve mentioned Mark Schwartz a few times. It sounds like he created space for something viable to take root. What do you think it was about him and his approach that created that space?
Brian:
He was willing to take risks and adopt industry practices. And that willingness gave cover for other people to take risks. I have a much deeper respect for that after years in government than I did at the time.
I credit both Mark and Kathleen Stanley. Kath ran the USCIS Office of Transformation Coordination that ELIS was under. She was on the business side and also taking a huge amount of risk. Probably more risk than Mark, because what he’s doing will at least be respected by others in the CIO community even if the project doesn’t succeed. But if you’re on the business side, you either got a product or you don’t.
Emily:
Brian, is there anything you learned from USDS that you wish you had known from the beginning?
Brian:
I didn’t understand the value of management and organization when I arrived. It became clear to me quickly that the executive core on ELIS and USCIS was quite good. But not having been in a tech company – not having seen a successful project – made it difficult for them to achieve their mission. They didn’t have the tools or experience. It was very powerful when folks from tech companies came in with their experience and knowledge, but we lacked the federal expertise the career civil servants had. So it was a good union.
I also thought I was going to show up and be writing code 100 percent of the time. But it was so much more valuable for me to do management consulting. The government was actually able to hire all of the talent they needed to execute successfully, but how to organize and adopt the right culture had been lost somewhere along the way. That gave me a deep respect for how organizations can help people succeed – or sabotage them. When you’re in a tech company, there’s an understanding of how to get things done. There’s a reward for implementation, for acting, for tolerating risk. And if smart people don’t have that cultural capital on an engineering project, they struggle.
Emily:
You mentioned how successful technology projects are run. Can you give us a quick example?
Brian:
There are a lot of day-to-day things that need to be done – and there are lots of things that you can do wrong. At the end of the ELIS sprint in 2014, I had an analogy: It’s like USCIS had built a house without ever having seen a house. It didn’t work well, but it was an admirable attempt.
Meanwhile, your ability as someone who has seen a house – that is, who has built technology projects – is immense because you’ve done the hard work. You know stuff that seems basic to you. When you don’t understand a house, your air conditioner may not be working because you don’t have a front door. And that may not be immediately obvious if you don’t understand the systems at work. But it’s a really quick fix. And there were some fairly quick fixes to get ELIS to be successful.
Also, implementation matters a whole lot. You need the expertise and the right set of people and distributions. The government actually tended to get those things right. What’s trickier are software projects above a certain complexity. These haven’t been done before; if they had, we would be copying the code. So you can’t just know how the final system will look and if you succeeded.
Most development accounts for this. Typically you can hit “enter” and learn whether it compiles the code. You can hit another button and run unit tests. Each of these provides slightly longer bits of feedback. What you shouldn’t do is write code and not even know whether it compiles, whether it passes unit tests, whether it passes integration tests, whether the system is usable – and then find out six months later when they turn it on whether it works. The tighter any feedback loop can be, the better. You wouldn’t paint a portrait with a blindfold on, right?
Kathy Pham:
What types of backgrounds do you think people should have on a government software team? If you were to create your team, what would you start with? An engineer, designer, product, legal, HR, etc.?
Brian:
Those feel like essential components if you’re trying to restructure an organization from a top-down approach. Boiling the ocean is not a good approach. I wish luck to anyone who’s trying to improve government efficiency, but I think a top-down approach is often wrong. You need to have enablement. A lot of stuff is tribal knowledge. It’s cultural, it’s how things are done. Is reporting failure swiftly rewarded or punished? You need to know what went wrong to fix it. And if people are afraid of punishment, they don’t raise their hand and say, “My fault.” And then you’re going to spend four hours trying to figure out what someone already knows.
You can set these worlds up in a very destructive or constructive way, but it’s subtle. It’s nuanced. Also, tech projects should generally be made up of high-performing individuals who work well together.
Kathy:
What are the skills or backgrounds of those high-performing individuals?
Brian:
Technical excellence and teamwork skills.
Kathy:
I get this question often from all students. They ask, “If I’m building a team, do I need a software engineer? A designer? A consultant?”
Brian, what does technical excellence mean to you?
Brian:
USDS was different: We were often working with a larger organization and were there to help them do better. That’s different from line staff. So I wanted folks who were tech leads or managers – someone who is not only knowledgeable about their own work, but also has people skills and empathy. Someone who is easily able to form opinions, but also reconsider them in the face of new information. Those qualities get people promoted into leadership, whether it’s thought leadership, like a technical lead or people leadership like a manager.
You want that flexibility and discretion in a job like USDS, because it’s a leveraged position where you have the capacity to do a lot of damage or do a lot of aid in a short span. You should have a different standard than for people who can come in and do an honest day’s work on a hard project, like the line engineer role. For this sort of intervention team, you want someone who can really excel at the leadership aspects. You need someone from a healthy, productive culture of delivery. It’s very hard to mandate that from the top, but you can enable it or shut it down. Mark Schwarz is a good example of that: He brought in people like his own agile coaches, who might individually be hit or miss but set the tone for what Mark wanted.
The better model for reform centers excellence and training. There were plenty of old techniques that captured this very well during World War II or other times of great government expenditure. Training Within Industry is a good example. You train the trainers; knowledge goes through, it doesn’t come from above. If I was to have a theory of change, I would focus on doing a very important thing very well, and then spreading that knowledge. I do feel in our great moments, USDS enables those virtuous cycles.
Kathy:
Brian, what were you most proud of at USDS and what do you feel left lasting impact?
Brian:
I’m most proud of the results. As for the organization itself, I am proud of the people. We had an unusually high concentration of talented people willing to make sacrifices for the public good. There was a pent up desire in my industry to do public service. When USDS offered that opportunity, we had tremendous humans who came forward, worked hard, and supported each other. And we had external leadership that cared about those outcomes and worked with us to achieve them.
Emily:
Brian, thank you so much for your time.