Jeff Maher
‘It Was a Bunch of Truth Tellers Willing to Roll Up Their Sleeves’: Jeff Maher on the Spirit of the U.S. Digital Service
| Jeff Maher was Engineering Manager and Software Engineer at the U.S. Digital Service for two years, beginning in January of 2015. Prior, he was a 2014 Code for America Fellow and a software developer at companies including Johnson & Johnson and Vanguard. |
Jeff Maher came to the U.S. Digital Service on the heels of a Code for America fellowship and with a keen interest in making it easier to get benefits and healthcare. He was embedded within the organization’s first agency team at the Department of Veterans Affairs (VA) and part of a group that worked on the claims backlog and the Vets.gov website.
During his tenure, he learned that technical skills were important, but certain soft skills even more so — like a high EQ and an ability to receive and process feedback. Below, Jeff discusses the need for structure as USDS expanded; the impact of smart interview questions; and the three most important skills a USDS staff member can possess.
June 28, 2019
Kathy Pham:
Jeff, tell us how you started with the U.S. Digital Service.
Jeff Maher:
I was a Code for America fellow in 2014 and interested in the intersection between digital services and government. People just weren’t getting good government services. There weren’t good digital interfaces or thinking around, “What do people really need?”
I was much more focused on joining 18F at first. But White House Chief Technology Officer Todd Park visited Code for America to discuss the Department of Veterans Affairs (VA) claims backlog, and how people weren’t able to get healthcare or disability benefits. I thought, “This would be a really high impact place to work.” I had no idea that it was connected to USDS. So I applied, got my offer, and then heard, “Hey, show up to the U.S. Digital Service on your first day.”
I went to my VA orientation on January 11, 2015 and then walked over to Jackson Place, the USDS headquarters in a townhouse by the White House. The first thing I saw was that the doorbell was out. Erie Meyer and Emily Tavoulareas gave me a warm welcome — and then asked me if I knew anything about circuit breakers, because the power was out in the building and the heat wasn’t working, either. So Erie dispatches me to go figure out if I can figure out how to turn the heat on.
Kathy:
How would you describe USDS? And what else was your first day like?
Jeff:
It was a bunch of truth tellers who were willing to roll up their sleeves and get things done — but also willing to listen to people.
That first day, even before I arrived at Jackson Place, was chaotic. It was a snow day in D.C. and the government shut down. An HR rep told me they didn’t know what department I was in or who I should report to.
Once I was at Jackson Place, the rest of the day was spent talking with Erie and Emily, soaking in USDS culture, and meeting people at the all-staff meeting, which was between 10 and 20 people.
Kathy:
What was that first staff meeting like?
Jeff:
I was really nervous; there were some big names in the room. People were talking about challenges in hiring. There was a lot of excitement around the VA team. And there was talk about USDS’s immigration work.
Kathy:
What was the team — both at the VA and USDS broadly — setup like at that time?
Jeff:
The VA team lived out of the basement of Jackson Place for a few weeks, to incubate in the USDS culture and build an appetite for risk. Learning that lots of people are going to say “no” to us, but that there are other people here who are also bashing down bureaucratic walls. I also learned a lot about procurement from Traci Walker, and that was really helpful.
The VA team was very confusing at the beginning because nobody knew what we were supposed to do. Even when I was interviewing, the interview questions there wasn’t a strong idea of what our work would be like. I got asked questions about complicated algorithms that seemed more likely to be questions asked of someone joining Google’s Search team – not web forms like I had expected. When I was asked for feedback about the interview, I said, “I think you’re going to get the wrong people. If you’re asking people to come in and be really awesome with algorithms, you’re just not going to have the right skills. You need people with the ability to work within organizations that don’t understand more basic technology and get people onboard.”
Kathy:
When did it seem like we started getting direction? And what do you think that process was like?
Jeff:
The high point of confusion was the first few weeks. After that, we started talking to the Veterans Benefits Management System (VBMS) people for the first time. Our team spent a lot of time figuring out why it was taking so long to process a claim. But we didn’t really know what or where the problem was. We were looking at everything from the VA computer network to organization dynamics. We kept getting sent down rabbit holes where people were either incredibly resistant to talking to us, or rabbit holes that were obviously doomed. We kept winding up in places where a project was so far gone that there was no hope that any engagement with us would actually fix it. It started feeling like we were being set up to fail by people who didn’t want us to be involved at the VA.
Kathy:
Can you tell me about one of those rabbit holes?
Jeff:
There was a particularly awful one. Ellen Ratajak, Alex Gaynor, Robert Sosinski, and I were trying to learn more about VBMS (Veterans Benefits Management System, a $200m a year case management system), how to get data in and out of it, and what kind of lift it was to add features. However, VBMS had a complex ownership and staffing structure, which meant digging through a bunch of layers to find an actual developer. There was a VA leadership team, which outsourced much of the development to SPAWAR (Space and Naval Warfare, part of the Navy). SPAWAR turned around and did a giant procurement, got a prime vendor, and broke it up into five or more subcontractors. We visited South Carolina to meet with the SPAWAR, some of the VBMS leadership team, and the biggest of the subcontractors. Our mission was to find a developer in the room and have them tell us how to setup VBMS’s code base on our computers. We quickly learned that we’d need access to a gazillion different systems to even get a copy of the code, on top of the distinct feeling that SPAWAR and the VBMS leadership team didn’t really want us getting involved even when the contractor was willing to give us information.
Emily:
What happened when you went back to D.C.? How did the VBMS work evolve?
Jeff:
We realized how many hurdles there were to getting access and talking to the right people in the VA. Weaver was really sold on an all-access pass, which was basically a signed letter from somebody high up to show people that, “Hey, you need to talk to USDS, or you need to give us access to your system.” Ellen focused on building a better relationship with the VBMS people. And I focused on hiring more people into USDS and our VA team.
Then Robert Sosinski told us more about appeals disability claims issues (or put shortly: appeals, which also had a sizable backlog). Appeals were managed in a separate leadership chain (BVA, Board of Veterans Appeals), were mostly processed outside of VBMS even though there were still moments where they had to use it, and it seemed like there was an openness to change. A lot of us had an epiphany: “We should give this more of a look.”
We sat with the people who processed appealed claims. We started mapping out the journey of what the appeal process looked like. We saw the VBMS touchpoints where they had to review medical evidence PDFS and VBMS would crash every third PDF that you would open. It was clear that the people reviewing appeals were bogged down by how slow VBMS was and how there was no workflow engine within VACOLS (i.e. it was just a tool to view data and where files physically existed, but case status was indicated by who’s desk the paper was on). We started getting a better picture of how to improve appeals and it seemed more possible to make change with BVA than with VBMS.
In late May, we realized we needed to convince appeals of a different way of doing this. They needed an end-to-end claims processing system. A group they were working with, MITRE already had some plans on how to modernize, but it seemed a bit disconnected from agile/iterative practices and UX research checkpoints. It also just seemed drastically expensive, and we thought there might be lighter and more human centered ways to help with BVA clear and keep down its backlog. And we had to sell them on user-centered design and research, and building software in incremental pieces. So we started putting together a pitch.
There was one day that was a really pivotal turning point for the project. With BVA leadership, we were invited to MITRE’s headquarters for two full days; it was called “a lockdown.”
There were two moments in that meeting that turned the tide. The group was made up mostly of contractors and VA IT employees, and they were diving deep into how to correspond with Veterans about appeals. They said it was going to take years to build one of the components, which was a letter production system. Meanwhile, Alex Gaynor was sitting in the back corner writing a letter template system in Python. And when they asked us, “How would you do it?” Alex went up front and said: “While you were talking, I built your system.”
Emily:
It was so great. You guys hit it out of the park.
Jeff:
I gave an agile/iterative pitch on behalf of our VA Digital Service team about our plan: “We’re going to interview the people who process the disability benefits. Then we’re going to map it all out. We’re going to build something over the course of two weeks, deliver a little bit of it, and check in and see if we have it right. And then we’re going to just keep doing that forever.”
I totally bombed it, and it probably sounded overly simplistic. Agile planning was so foreign to the business people and the IT people. They said, “That’s no plan. This is not how you do a project in government.” But Kavi Harshawat jumped in and phrased it in a way they understood, and you could see the light bulbs coming on. It gave us the runway to write a document that explained that we understood what the problem was, but also how we would go about fixing it. He really saved the day, and got us the credibility that got us permission to build their new case management system: Caseflow.
Kathy:
Jeff, can you tell us about the genesis of Vets.gov?
Jeff:
It was really hard to log into a lot of VA systems and apply for benefits. There wasn’t a menu of veteran services and how to interact with them. Marina had the idea of Veterans.gov, and had started by consolidating job sites that the VA was building. The VA had about six different sites to help Veterans find jobs based on transferable skills from things they did in their military service. Marina got those redundant projects canceled, which was actually the source money to fund the USDS team at the VA. It was smart people moving things around. And that was the first part of Vets.gov.
Here’s where I came into the picture: We had a team offsite in August and realigned a lot of priorities. Some people left the team because they didn’t agree. And this is really where we had our first, “Oh, I know what our team’s mission is. I know what our values and goals are.” Delivery is the strategy became our mantra, and we had three big areas to focus on delivery: the spinal care app, Vets.gov, and the start of Caseflow.
Kelly O’Connor pitched Marina on moving me to Vets.gov to help build the engineering team. I was reluctant because I thought building a website might not be the fastest way to make claims easier, and was enjoying the work with BVA on Caseflow. But it became clear that this was important: Veterans didn’t even know what benefits they could get and how to apply. So I wound up moving over in January.
The first two goals were: How do we get people to focus? And, how do we build an operations team that knows how to keep the site up? In that first quarter, we got organized as a team and knew how to deploy the site manually. And we started getting more engineers for the team: Anne Kainic (now: Palay), Courtney Eimerman-Wallace, Robbie Holmes, Alex Yale-Loehr, and Albert Wong joined up early in 2016.
In quarter two we were heavily recruiting Stacey Langer as the Vets.gov Product Lead, and when she joined a lot happened. She realized there was too much context switching going on: Even though people had projects that they belonged to, they were also on different projects with different people. She lined up the team into clearer lanes. We also became more formal with one-on-ones and had a reporting structure: Emily Wright-Moore was the head of design, and I was the head of engineering because people needed clear escalation routes. Mary Ann Brody also joined our team to lead UX Research.
In May the healthcare app was coming due, but it wasn’t ready. The code quality was subpar and there weren’t a lot of automated tests. The engineering team was worried, but they were afraid to say no. I remember talking with Stacey and saying, “We might go ahead with the app, but the team’s going to fall apart. The project might fail and these people are getting ready to kill each other.” We became therapists, getting bleeding hearts to realize that everybody else was a bleeding heart, too. We assumed best intentions, came together, set a new timeline, and finished things. And in June, we were legitimately ready to put something really big and important out there. Plus, the team really began to gel.
There were problems; some data was coming in backwards. But the team was ready to do blameless postmortems. There was a lot of drama, but everything came together. And it was the first moment where we felt, “Oh, this is actually going to change things. This is a different way of putting a veteran service online.” We were seeing an increase in the rate at which people were applying.
You could write a book on just that three-month period of launching the healthcare application — there’s way more depth to that story than what I’m conveying. Anne Kainic, who was leading the engineering efforts, was amazing and should really write that book.
Kathy:
A thread that I see is the importance of structure in an environment where people don’t like structure. I’m interested to hear your perspective on how pivotal it is to have structure.
Jeff:
When we went to the USDS offsite, we did a personality exercise that put me more on the chaos side of things (i.e.I was as far as you could get from supporting structure). It felt really weird becoming one of the co-creators and advocates for a more structured way of operating. But it was something the team needed.
Kathy:
Jeff, can you talk about your involvement in hiring?
Jeff:
In my third week, Weaver came to me and said, “You’re running hiring now. Go talk to Erie.” So Erie and I started figuring out applications, how to log into the then hiring system, and who would be good to sync with around both the USDS hiring pipeline and to get more hiring permissions at VA.
From there, there were two things that were pretty big: How do we evaluate resumes when they do come in? And, how do we get the VA to take rolling candidates? There was a lot of back and forth with the VA HR machine because we had headcount for up to 75-ish people, and we were only six. We had to do a lot of hiring.
Veteran preference was a part of the process that required very fixed hiring time windows to process, and we wanted more of a rolling application process. We came to an agreement with HR that we’d essentially create a hiring pool every month, starting on the first and ending on the last day. Then we’d give preference to Veterans that applied within that month’s window. Also, there was a lot of back and forth on whether people needed to live in D.C. or not. I remember editing the application site almost every single week: “Need to be in D.C.,” “Okay with remote,” “Need to be in D.C.,” “Okay with remote.”
We had our own VA hiring process for a good six months, and it mimicked what was going on with USDS. We were trying to figure out how we could take people from a USDS hiring pipeline, and still attach it enough to the VA hiring mechanisms, so that the VA would be okay with it. This would allow us to connect more to the USDS Talent Team, a bigger recruitment pool, and more interviewers.
We ended up getting a shared hiring pipeline, and that’s when the cooler stuff started happening like core competencies and performance profiles (as taught by Dana Chisnell and Jared Spool). Really good interview questions came out of that, and we started getting better at note-taking during interviews and generally becoming first-class skill interviewers as an engineering team. But there was still a lot of anarchy in the hiring process by the time I wound up leaving. It wasn’t clear who was asking what questions during an interview, and whether people were asking them consistently. And there were still a lot of opportunities for unconscious bias to work themselves into the hiring process.
Kathy:
How did you contribute to the types of interview questions that were asked?
Jeff:
I would ask, “Why is this a question? What information are we trying to get out of this question? Will it tell us if this person is able to accomplish these kinds of things in this kind of environment?”
I wrote a few of the interview questions. And I probably annoyed my colleagues sometimes, stressing that if we can get somebody that can do a simple computer task (i.e. steering away from complicated coding and Linux ops questions), but also speak bureaucracy and knock down barriers, that’s the person we want. We needed to be really clear about the competency.
Emily:
What competencies were most needed, to your mind?
Jeff:
You need three things. One, they’ve done technical work relatively recently and still understand how things are happening today. They speak the lingo and they have an idea of a good engineering workflow. Two is the EQ. The ability to listen to people and understand root needs. There are so many people that just can’t listen to another human. And three, they need to be able to set up systems that deliver continuous feedback. When I say systems, I don’t only mean computer systems. I also mean people systems. They need an awareness of whether something is working. An ability to set up a group of people to listen to each other more, or hear from their constituents more. That skill is relevant to everyone across the board, but engineers are sometimes the ones who least understand that. You need engineers who are willing to speak across silos and talk to people and keep getting feedback from different places.
Another thing is finding people that would fall in love with the problem and not the solutions. Folks with this mindset are aware of the context and challenges, and find the appropriate tool for the job rather than just trying to force a solution. It’s commonplace for software engineers to want to use a shiny new technology or something overly complicated, but folks that are attuned to user needs and the delivery environment are able to choose the appropriate actions and tools needed. Some days, that’s not writing code – and lots of engineers struggle with that.
Kathy:
Jeff, thank you for spending time with us.