31 Learning from USDS Engineering Director David Holmes
We are joined by [David Homes](https://github.com/DavidEHolmes), Director of Engineering over at the United States Digital Service. Our conversation will cover a number of topics including technology accessibility, interacting with partners and translating business rules into code, and the mentorship and development of engineers.<br><br><br>### Resources and Shoutouts:<br>- [Join USDS](https://www.usds.gov/apply)<br>- [Civil Rights Data Collection](https://github.com/DavidEHolmes/crdc)<br>- [School Diversity Report](https://schooldiversityreport.com/#/)<br>- [US Web Design System](https://designsystem.digital.gov/)<br>- [Section 508 Compliance Site](https://www.section508.gov/)<br><br><br>##### Music Credit: [Tumbleweeds by Monkey Warhol](http://freemusicarchive.org/music/Monkey_Warhol/Lonely_Hearts_Challenge/Monkey_Warhol_-_Tumbleweeds)
Top Keywords
- business rules 0.006
- folks 0.006
- make 0.006
- usds 0.005
- project 0.005
- school 0.005
- engineers 0.005
- work 0.005
- engineering 0.005
- help 0.005
- zero eight 0.004
- talk 0.004
Transcript
Hello. I'm Ryan Cook, and this is Civic Tech Chat, a podcast about the civic technology movement. We seek to harness the power technology has to improve the delivery of public services to people everywhere. Welcome back for another episode of Civic Type Chat. If you liked our content so far, head on over to your podcast app and give us a five star review. Doing so helps us reach a broader audience and helps motivate me to continue making these episodes. This week, we're joined by David Holmes, engineering director with the United States Digital Service. We'll get to learn and lean on his experience as we talk about a few topics, including the idea of technology accessibility, partners and the transition of business rules into code, as well as mentoring and developing engineers on engineering teams. I know that I enjoyed this conversation, and hopefully, you will too. So let's go ahead and hop right into it.
David, thank you so much for coming on to Civic Tech Chat. Can you introduce yourself and tell us a little bit about what you do? Thanks, Ryan, for having me. Really excited to be on, this podcast.
So my name is David Holmes. I'm the director of engineering at US Business Service. And kind of a little bit of detail just in case some folks don't know what US Business Service is. It's what basically started in the White House that's tasked with handling, you know, really tough technical problems and using design and technology to deliver better government services, to the people. Like, for for instance, like, right, it doesn't make sense I can order McDonald's from an app on my phone and, like, it just shows up. Right? And just a magical easy to use app. But if, like, a veteran wants health care, they have to go through this entire complex process. So, like, we work on, like, those tough problems that we try to make something that shouldn't be that hard and just make it easier so that way people can can use them in a better way. As director of engineering, I pretty much oversee the entire engineering community. And my main focus there is just making sure that all the engineers are happy, working with agency leads that we have to ensure that all the projects we have is fully staffed up. I'm also on the hiring committee, that reviews all the interviews and transcripts and make a determination if someone should come on board or not. Also do some biz dev work, like, in between, like, as, like, we're starting new agencies and the projects. Like, I'll I'll talk to some of the folks there at the agency before we start, the project.
It sounds like you've got quite a bit of different hats that you have to wear. I I imagine you're a pretty busy person over there with the USDS role. Yeah. A little busy.
I'm always down to to have conversations like this. Awesome.
Speaking of your USDS presence, you have a page on there that talks a bit about you and perhaps why you joined USDS. And in that page, you cite an article and a Hacker News post that links to it from 2015 as a point of inspiration for joining the agency.
Could you tell us a little bit about that? Yeah. So I was on Hacker News, you know, this one day one day as I usually am. And I see this this article. I clicked the headline on something like, Obama's self startup in the White House. And I was like, oh, like, at the time, I was definitely working at a bunch of different startups and I love working in the start of culture. And I was like, one in the federal government? Like, yes. I'm I'm on board. And I clicked the article. I didn't even read the comment. I just clicked the article. I got halfway through the article, and I was just like, I gotta apply right now. And I just went and just sent my resume in. In a few months, yeah, I was here at USCIS,
just bought that Fast Company article and the Hacker News post. On that same page, you also mentioned that learning the plethora of acronyms used in government was a challenge, as you got started, which is certainly understandable. There are quite a few of those that float around. Over time, has that gotten easier?
And, do you have a favorite acronym among them? It has definitely gotten a lot easier, and I just provided them off in conversation, so I apologize if I use them. Yeah. I don't know if I have a favorite among them, but I definitely have a favorite government website URL. And so the register to to register a .gov, a web address, is .gov.gov. And I said to my favorite URL, like, I just picture being in that room making a decision. What should we name this? And someone was just like, just .gov. It was like, yes. We know it's a .gov, but what should we name this? No. I mean, like, .gov, .gov. If you go to .gov, .gov, then it's a .gov register for all the government URL. So this is my favorite website government website URL. And I think my favorite URL almost anyway.
Oh, I I think it would be amazing to have been a fly on the wall for that meeting. I imagine that turned into very much like a who's on first kinda situation.
Yeah. I imagine. I do. Yeah. I wish I could just go back and just be in that room.
And, as you mentioned, you know, you're currently a director of engineering. I imagine there were some steps before that in your career. How would you describe that path as you've ventured upward toward now leading a practice?
So back when I came to USCIS in 2016, I started working on the Social Security administration project, called disability claims processing system, and that was basically how do we make the disability disability claims processing system a little bit better. Then I moved on to department education where we help students get a debt in default, because tons of people are in student loan debt. And then I moved on to small business administration where we help disadvantaged businesses apply to get to the eight a certification a little bit easier. Some people was paying up to $30,000 to get into this program, which is free because it was so complicated. So we just made that a little bit easy and now it's a 100% digital, and you could do everything just straight online. And then I went to FEMA where we help with the grants management modernization, where they're trying to take 10 different grant systems, down into one. And as you can imagine, there's 10 different systems. You don't even know which one to actually go to. So we're trying to just how do we, you know, consolidate that down to one? And I became, director of engineering here at USCS. So it's been an interesting journey with a lot of impact. So so how we describe that path is just, you know, interesting and impactful. Right? Across the the the, breadth of, you know, in three years, I was able to have so much impact across many different agencies.
As an engineer, kinda trying to make that impact as as you mentioned, I imagine that there's a plethora of different tools and technologies that you've used along the way. In your experience so far, do you have a a favorite or a go to, programming language or or toolset? And if so, why is that your choice?
So my go to programming language is Python. And the reason why it's my choice is so, like, our MacBooks and Linux, it comes in it's all by default. And just the Python standard library, you could just do so much just with the standard library, and that's just usually my go to, especially if I just wanna write, like, a simple script or something like that. I just I just default, just jump straight into Python. And my go to tool, I would probably say for my editor, I use Sublime. I just love it. It just opens fast. It can open, you know, large files, and I know there's, like, Versus Code and Adam and all those, new things coming out, but just Sublime just just gets me. I even paid for it because I probably wouldn't have be because, like, it's just so great.
I I can definitely, understand both those choices. I I myself rather enjoy both Sublime and Python. So I'm I'm I'm right there with you on those opinions. Alright. I'd like to, go ahead and, have us, switch gears here a little bit. And, we're gonna end up talking through a couple of different topics, including some stuff about accessibility, some stuff about partners and idea of, like, turning business rules into code, and then a little bit about, mentoring and development of engineers. To start that, though, I'd like to hop into the accessibility portion of our conversation. And to start that off, I think there's an assumption out there that public sector projects have to work a little harder at accessibility than those in the private sector. I suppose there's the assumption that the public side can hand wave or can't hand wave some of that away via audience targeting, like, maybe the private sector can. Is is that something in your experience that seems to be true? Whether it is or isn't, like, what kind of impact does that have on your work? Yep. So it's definitely true. So,
by law, we have to do something that's called five zero eight compliance. And what that is is just, a law that requires federal governments to be safe and accessible for people with disabilities. And, like, a couple of months ago, I was actually just doing some fact checking. Twenty ten of Americans have some type of disability, and a lot of the work that we do impacts some of the most vulnerable populations. We need to make sure that the work that that we are outputting actually is usable by, you know, every American, citizen, and we wanna make sure that we can help those votes as well. So, the impact that it has on our work is nothing goes by without five zero eight compliance testing, and I think that's a good thing. That that makes a lot of sense. And I've heard folks often describe work to, like, get that sort of compliance.
Just I've heard them describe in a way that makes it seem like it's a a hard problem and to put that in quotes. Is that something you've observed, and are there patterns that you try to follow to to get to that end goal? No. I don't think it's a hard problem at all. One of the things
that, you know, that some people feel like it's hard is, like, actually built into the web. So there's things like alternate text for images and, make sure that you keep, you know, people who are visually impaired or blind or, you know, color blind in mind when you're picking design colors. You know, and and a large part of what we do is we talk to the users. Right? And we say, like, hey. How would you use this? So we actually go out and and talk to, you know, the, most vulnerable populations. So how would you actually use this this application? And then we work with them to make sure that it's it's easily accessible for them as well. But I don't think it's a hard problem, and there are some things you could do to learn more about, you know, usability testing for five zero eight compliance as section 508.gov, or you could use The US web design system, which is five zero eight compliant. Oh, for folks that aren't,
familiar with that system, could you give us kinda, like, the high level of what the, the web design system is?
Yes. Pretty much like Bootstrap. So if, business are familiar with, like, the, Bootstrap, CSS framework, it's pretty much like that. It just makes it a little bit easy to build websites and, build your, user interface. And we did one internally for for our websites, and then we brainstorm open source that with the help of, like, AT and T and others, which is a US web design system that, you know, a big part of that is making sure that accessibility
is, like, up and forward and center. And the that that US web design project, is that then, is that, like, an open source initiative? Is that something folks can just like anybody out there can use and contribute to?
Yep. And we have tons of people who already just uses it for their websites all across the federal government. And, it's open. You can go to designsystem.digital.gov to go, learn more about it. And a lot of our projects from, you know, the work that we do at the VA even down to NASA uses it. Oh, wow. That's that's, quite a wide, berth of folks
getting involved with it. Yep. I, also, like, in thinking about accessibility, I I also get the sense that having it in mind early on in a project seems to be a thing that's desirable, whether it's reading the, you know, United Kingdom's service manual stating something like, think about accessibility from the start, or, from The US web design system that we've been talking about for a moment, which is quoted as saying accessibility is fundamental. With that in mind, like, do those intentions then shape how y'all at USDS put projects and teams together?
Yep. So on every project and, team that we have, there's a designer there who is super focused on that, and we do a lot of user research. So we are able to see those problems so far too. And because we have designers on every single team who can make sure that everything's five way compliant, like, it does, like, it does shape how we make sure that how we put teams together. And, again, a large part of this that we do is user research. Right? Go to the teams, talk to the users and see and how, you know, we could best serve them. And, we've mentioned the idea of being, five zero eight compliant a couple of times.
Could you give, the audience maybe a a little bit of an idea of, like, what that what that means as far as five zero eight compliance? And is there anything on the on the private sector side that kinda compares to that? One of the things that
that five zero eight compliant does is just ensures that we aren't, like you said earlier, just building it for a target audience and that we are building it for everybody. And it's just a law that congress set up, I believe, couple of decades ago just to make sure that all federal websites are accessible by everybody.
And if if there was a one piece of advice you could give somebody starting a project that has that intention of, like, I wanna make sure that this project does respect, those those sorts of standards, as they're getting going, what what advice would you would you give that person?
I'll definitely tell them, to check out section five zero eight dot gov, and you can learn way more, about how to, make your website more accessible by people with disabilities. And, also, the other thing I would say is, you know, for especially in the private industry or in other government agencies, talk to your users. You know, you may actually know that your users are having difficulty accessing your website, so just go out there and and try and talk to as much of your users as possible.
Awesome. I I I'm sure that there's folks out there that'll, appreciate those insights as they, kinda figure out how their their own work day to day is gonna happen. I'd like to now, go ahead and, talk a little bit about, the idea of partners and and how business rules can become code. And, to start that off, as you're starting a new project, Let's say you're working with an an agency, perhaps maybe even for the first time. There's probably a set of interactions that happen. Could you talk to us a little bit about what those are like getting started? Yep. So as we start,
part of our project selection criteria is making sure that we pick projects such as a group, greatest goods for the most amount of people in need. And that's where we start our base at. Right? So we get a lot of offers to help with stuff, but then it just doesn't fit kind of our our project selection criteria. And how those initial interactions are like is once we go in the ground floor, one of the things that that we need is air cover. So we'll probably talk to a deputy secretary or secretary or maybe on the secretary or CIO or somebody, kind of at that that top level of the organization hierarchy. And make sure we have the air cover and then have a project, like, scoped out for us. We just don't wanna be there because you want us there. Right? Like like, have a a particular project scoped out, for us to do. And so that the, initial interactions are once we have that air cover, we do what is called a discovery sprint. And over the next two weeks, we'll just kind of talk to people on the ground and everybody with an organization to kind of learn more about this, because we don't know what we don't know. So the best thing that we could do is just go talk to all the stakeholders and people involved in the project and just learn as much as we can. And then from there, we we deliver a report and kind of go and figure out, like, is it something that we could do? Or sometimes this is that person who's on the the, you know, ground level, you know, in the trenches doing the work who has a great idea. Now we are able to just empower them and put them in contact with the deputy secretary and say, like, hey. You should listen to this person because they know exactly what they're talking about and what they're doing. And, you know, part of the reason why air cover is so important and how we why we try to go at the top of the hierarchy and authorization all the way to, to in between and everywhere, in between is because, you know, sometimes things go wrong. Right? Sometimes we're on the Ground Floor and and somebody's like, I can't give you access to that data. And if you go, like, oh, no. The CIO said, like, it's okay to give us access to that. So that's why the air cover is really, really important for us to have. One thing I I think I heard you you mentioned ex explanation was this idea that there's some criteria
about whether or not your organization considers the work the sort that you'd like to engage with. Could you talk a little bit about the the process behind that sort of determination a little bit? Yeah. So,
all the leadership at USCIS sort of gets together, and we just talk about it. And, we'll have, like, an initial conversation with the the person who acts and say, okay. What is the problem that you're actually trying to solve? And then we'll just have a, in-depth conversation about that problem trying to solve. And sometimes it may just be solved in that simple phone call. Right? Sometimes it's just, yeah, you're trying to get the CICD pipeline set up, like, get, you know, use Jenkins or something. And sometimes it gets more complicated. We actually have to go in and and figure out,
what's what's the ground truth. I I would venture to guess along the way that there's probably a non zero number of occasions where, folks you have to work with or the organizations themselves, can be a bit difficult, for lack of a better word, to, collaborate with. Are there strategies that you found effective at addressing those kinds of situations?
Outside of, you know, executive air cover, making sure that we have, like, that person who can, like, vouch for us and say, like, no. No. These people are supposed to be here. I think one of the biggest things that we do is we just listen to the partners and stakeholders, and we try to make sure to understand where they're coming from and and try to say, like, hey. We're here to help you. We're not here to, you know, tell you that you're doing the wrong and that we're we're better than you or anything like that. Like, no. We're just simply brought in to help and see how we can make this better. Because one thing I definitely learned, working on multiple different agencies is everybody at each agency really, really does care. And sometimes it's just really hard for them to, you know, share that, out to to the rest of, like, the organization. And one thing that we come with is, like, because of this executive air cover, we can actually get those voices heard to a deputy secretary or under secretary. So that's one way we found it to be in, to work in those difficult to collaborate situations. And, you know, just to tell them that we're temporary. Right? We're not here to take your job. Right? At USGS, we have tour of duty models. So we're here from our shortest three months up to four years. And,
we we're not trying to take your jobs. We're not trying to take over the project. We we just simply want to help. So you mentioned that a a significant part of that is is getting that, it sounds like kinda like buy in from from that higher level executive. What does that usually look like? What are those interactions tend to be like as you try to try to get that buy in? Usually, just a a couple of meetings. Right?
And just saying, like, hey. Yes. We do have, you know, so, like, for instance, at some agencies, there's no engineers. So they actually can't tell if, like, a vendor or contractor is telling them the truth or not. And one of the things we can go and say, hey. We have a ton of engineers, and we can go and actually sit with you and tell you, like, no. This is wrong and this is right and just help you through that. So a lot of it, it looks like it usually just comes through our administrative Matt Cutts, and then he'll, like, kind of, you know, determine, like, if it's, like, something that that that we should do or not.
And I I believe I I also heard you describe the the tour of duty model, in there as far as the, like, the basically, the fact that you're there on a temporary basis. How does that impact, like, the way you both, like, shape that relationship and and and the project there, knowing that there's some sort of date where you've I guess there I would imagine there's a handoff of some sort that happens.
Yep. So we we try not to be bold bearing because of this tour of duty model. And how much these relationships is because I think of this tour of duty model that we have, like, it it can give a sense of urgency to the project. Right? So because we're not here for many years. Right? Let's try and figure out how we can actually start the process of this. Right? So one of the things that we've been successful in is moving folks and agencies from a waterfall model where they try to build requirements over two years and then they hand it to a vendor, which then takes another two years to an agile, method, right, where we could kind of build this piece by piece. And as we talk to the users, we can, you know, we can go in and and switch gears as as we get the user feedback to things that that that we found aren't working as well.
And I imagine that, once the the tour of duty, as we've been putting it, starts and you start to work with your partner on putting a solution together, that you can encounter some pretty complex requirements and, business rules, that then ostensibly has to be represented by some amount of code. How do you folks at USDS tend to approach
addressing those complexities and and that kind of translation layer that has to happen? No. The best way we could do it is by listening. So I remember being in the conversation and understanding why FAFSA was super complicated. And then we actually talked to the engineers on the ground. There's a ton of business rules and tons of business logic that actually goes into fast run how they make determinations. So the the best way we've learned is just by just listening to the people who have twenty years of experience on the ground. Right? And then saying, okay, how can we make this application simpler while still understanding those business rules? And sometimes some of those rules are policies, and we can actually talk to the lawyers at the agency and say, hey, this policy was done three decades ago. Does it still make sense to be using this today? And that way we could try to reduce some of these business rules as well. That that's an interesting comment you made there at the end.
Have you observed agencies making, policy changes in in a reaction to a a project with you folks? Yep.
So one of the things that we have is a DITAP program where we help, train on some of the procurement folks there in a way that allows them to do Azure con contracts a little bit better. And, you know, that that DITAP program changed federal policy.
Oh, well, that that's pretty cool.
But I I do find that yeah. So, like, for instance, there was a policy where, at a particular agency, they needed an alert box to pop up that lets you know that you're in a government website at all times. And, we actually talked to everybody and got them down to, like, you don't need this big JavaScript alert. They don't need the JavaScript to hurt to pop up every time someone's trying to log into a system that you're logging into a government system. And we said, like, okay. Show us that policy in my brain, and then we found the policy. And it just says, like, it has to be there somewhere. So just put that, you know, near the login screen and not this JavaScript pop up other than bad for user experience for everybody.
At times, the rules and requirements we mentioned before could shift and change, as you might imagine.
Are there aspects of your approach to engineering that help, alleviate those impacts? So, like, in the private industry, we have the agile development for the software divide, development cycle. That government is just not on the the curve yet. So we try to implement that so that way we can meet these, changes as they happen, and we don't have to wait for all the full requirements where they would spend the the two years upfront, and I was talking about before. And then by time it's two years, congress may have changed the laws. Right? So nine year projects already, you know, behind this on the law itself. So we try and go in and we say, okay. Let's just do these until maybe both try four weeks sprints because they're not used to they're used to, like, six months releases. So we'll try, alright, let's try four weeks sprints, then we can slowly work it down to three weeks and two weeks sprints. And that way, agile requirements come down and we talk to users and those requirements we change as we talk to the users, we can just shift really quickly in the next sprint.
And, you you mentioned, using some things from, like, the the the agile approach or or framework, to acting. I I believe you mentioned that, for example, like, sprint length. Are there other aspects of that framework of doing things that you found that are easier to get organizations to to, take on themselves and or things that are harder? I definitely found just getting people to
release things a little bit difficult. Right? Because the usage is releasing a whole thing and not just an MVP. Right? Every feature has to be be in it day one. But, like, but what we found is as we can show them that we can release slowly and iterate and keep iterating on it, we have been we have been successful in that. Right? That we could show them that it's an MVP. We're gonna release it out to users. Let users use MVP. We're gonna just take a small piece of this program, lease it out to the public, and then from there, see how the users interact and then make iterated iterated changes based upon that.
In in your experience there, I I I noticed that you mentioned, like, you you kinda have to show them that that it works. Are there things that organizations, like, tend to look forward to see as, like, I don't know, proof for lack of a better a better term that the approach is is more effective?
So one of it is so, health and human services that's in for Medicaid and Medicare, they have this mainframe for Medicare payment processing. It's in sixty year old system, you know, Britain and Cobo, and they've been trying to modernize it for decades at this point. And one of the things that we came in is we said, alright. We're We're not gonna try and modernize the entire thing all at once. Right? There's a 60 year old code, 60 year old code, and it's been there for a while. Like, there's tons of, logic and business rules and things like that. How about we just take a small piece of it, right, and move that to the cloud? And let's see how that works. And we were successful doing that, taking that small piece of it, moving into the cloud. And now that helps build trust that health and human services that okay. Like, maybe we actually can modernize this if we just do it kind of slowly and piece by piece and move it all to the cloud eventually. So that's one of the perks that we found that works. It's just kind of just taking a small piece of something and then just moving it to the cloud can have, like, tremendous, you know, impact on an agency to help them, see that, that it is possible to move this, you know, six year old mainframe COBOL program to the cloud.
Okay. I I think what I'm hearing from you there is that are you saying that, like, once you've shown them that you can deliver, like, a real world thing, that that confidence seems to grow? Yep. And other things that we do is, we build prototypes. Right? So we show them, like, you know,
hey. You know, you said this thing could take two years, but we pretty much did 80% of it over the weekend. Right? And it's a prototype for it. And that's been really, really successful and showing that it is possible to move the needle forward.
It's it's also interesting that you mentioned, like, prototyping as a as a phase, possibly that that you might engage with there. What what would you say that, like, a prototyping phase is like for a for a project over over their USDS?
Yep. So first, we start out by talking to all the users and figuring out, okay, what part of the system are you having problems with? Then we'll it depends on if it's a fresh brand new project or it's like it's a kind of project, a bioticket, like, it's a fresh brand new one that that we're launching. We'll talk to users and kind of get by when they come to, let's say, www.example.gov, what are you trying to get out of it? Right? Like, what is your end goal here? And then we'll we'll start sometimes it's just on paper. Right? Sometimes it prototypal just put them put a paper just like a thing drawn up and ask them, like, hey. Okay. What would you do here? What would you do here? What would you do here? And then, and then maybe we'll make a digital version of that and then put them in front of users and and to see how they interact with that. And that's usually how we started. We just keep going back for user feedback, as we continuously, you know, improve the the the system that that we are currently working on. So, now that we've, talked a little bit about,
kinda your relationship with partners and the idea of, like, translating business rules into code and kind of the the things around those topics, I'd like to have us, switch over to our third topic for this conversation, which is focused on mentoring and developing engineers. Because as you might imagine, what one aspect of building an engineering team is figuring out how to empower members of that team to to grow and develop. You as as an engineering leader, and quite a senior one, how do you prefer to go about that sort of thing?
Yep. So part of how, we empower them is so most engineers come at a just GS 15 level, which is the highest you can, go in the government pay scale outside of, like, the SCS role. And that helps us have a seat at the table. But one of the things that we do is, just, you know, we're allowed to have a seat at those table at those deputy secretary meetings. Right? So I don't have to be at those deputy secretary meetings. I can another engineer can. And, you know, like, trust. So once they come on board here, like like, we explicitly trust them. Right? That, like, I'm not gonna sit there and say you should do it my way. Like like, we explicitly trust everybody to go out and solve these these tough technical problems. And I I would imagine in the environment
y'all work in that, there's probably a considerable amount of diversity and technologies used and and tools needed for different projects. And I imagine that it's probably nigh impossible to make sure you have every single thing covered by by staff, meaning that, like, probably folks have to learn new things as they go on to different tours of duty. Other processes or things that, folks there try to do in order to, like, get up to speed, for those sorts of things? Yeah. So for that Medicare project I was looking on earlier, with the,
putting things in the cloud, we had an engineer who learned COBOL just so they can do that, and he bought a book on Amazon, just so they can learn COBOL. So, yeah, one of the things that we look for is people's ability to just adapt the situation and learn on the ground. So for example, I love Python, but you may go to an agency and they're Ruby on Rails shop. And I have to be comfortable enough that, okay, like, I'm willing to do Ruby on Rails because I I don't want to change all the engineers from using Ruby on Rails to Python. Right? Because I prefer it. Right? And that's that's a huge knowledge gap, and we had to do a ton of training. And then we have to rewrite the entire site, but, like, when I could just come in and help out and just jump in and on some roofing on rails code. So one of the things we definitely look at is for people's ability to kind of jump around and and be willing to learn and adapt the situation at hand. And, do folks in in the,
engineering practice there at USDS engage in mentoring at all? And if so, what does that look like for you folks? Yep. So we have a weekly engineering COP meeting where we're able to
talk to one another and figure out, like, you know, for example, we have site reliability engineers, and some engineers aren't, like, as, as up to date in site reliability engineering. So they can, talk to that that engineer and just learn and mentor them. One of the things as, I mentioned before, the tour of duty model is so, you know, I'm in my, fourth year now, so I have to eventually roll off in April, but I plan to, like, step down and surrender in some time in January and February. So what I'm gonna do is talk to the the community, send an email in August saying, like, hey. If you would like to be director of engineering, you can come shadow me, go over this, and some meetings, and, like, really, sit down with me over the next couple of months. So that way, as, like, you know, I prepared to handle this role, you know, I can have a bunch of engineers who can learn, from me. And that way, I don't have to then we make the process fair. Right? And that way, I can show them, like, okay. Before you just jump in and apply, this is actually what the job is. That's, that's really cool. I I did not realize that there were folks
that got to, to to shout out someone at your level, there in the agency. That's really neat. Yep. And I have tons of one on ones with people,
just so I could kind of ensure that that, like, they're happy or just any questions I can ask for them. And sometimes, you know, they'll ask me, like, hey. I have I'm having a certain problem at this particular agency. Since you've been on so many different agencies, what what would be something, like, you would recommend, or, like, who can I speak to more about this? And, you know, always willing to help people in that regard too as well. Since we're on the topic of mentoring,
I thought perhaps we could give some set of our listeners the opportunity to get a tiny amount of free mentorship from you. To that end, if if you could give any advice to an engineer, either, like, just starting out or kinda early on in their career, they're, like, looking at what to do, what would that advice be? Part of the advice I would definitely say is, you know, don't give up. A lot of things seem confused like, really confusing.
But eventually, one day, it's all just gonna click. Right? Another thing, especially, that helped me, especially when, as I was, you know, becoming more of a web developer, was just going to hackathons and meeting community and seeing what they're doing. Go to meetups. Go to your local meetups. Just just keep meeting people, network, and just keep learning. Don't stop. And, like, again, I it may seem very complicated at first, but it'll all make sense and click one day.
Since you mentioned that meetups there at the end, this may be geographically limited to who this is helpful for. But, are there any, meetups that you've observed that are, like, particularly
good to go to? Yeah. So Code for America has tons of meetups all around the country. So, you know, they have a brigade, that people can, go to their meetups, and it's all around the country. And that's one I definitely recommend. They're doing really, really great work.
And, I believe at the, kinda in your introduction, I think, is what I'm remembering that you said this. You mentioned that you yourself are kind of part of that, committee of folks that, help, like, figure out who who is, like, a good fit to to hop on and and join, USDS. Am I remembering that correctly? Yep. So in in your in your work with that, what kind of traits do you look for for a person that like, let's say there's, like, a listener out there that's, like, heard this conversation, and they're like, yeah. Like, I wanna do this. Like, what what kind of traits would you think that they would be best for them to, like, cultivate to be a, a best fit?
You know, one of the things we look forward is mid to senior level folks, but, but we always hiring, like, exceptional engineers. So, you know, we had to hack the Pentagon, and we had an, and from that hack the Pentagon, we hired an 18 year old, just for the summer to come in because they they was able to do so exceptional. But for us, one of the things that we look for is just being flexible, independent, you know, confident, but not cocky, and a team player overall and, you know, someone that's willing to help fight through the bureaucracy. And,
desire to serve is one of the the huge things that we look for. You mentioned the idea of of kinda like being a a team player. What what what does that mean in the context of
of of USDS? Like, how how would you describe that? Just being able to work with all different types of skill sets and people and, you know, I think you mentioned earlier before that some people could be difficult to work with and just making sure that that that, you know, they're not coming on board to yell at people. Right? Just being we're all here together and we'll everybody in the federal government is trying to, you know, do the the same goal is by giving, you know, by helping use design technology to give people the services that we have promised them in congress. Right? So we're all here to do that.
Now let's say that some intrepid member of the audience has heard all of this, and they've decided that's me. I'm that future USDS'er. How would you suggest they go about registering that interest?
So they could definitely go to usds.gov/supply, and we're always hiring because we have that to our duty model. So we're constantly hiring, and we're looking for, you know, engineers, designers, procurement people, product, managers. We have a position here that we like to internally call bureaucracy hackers. You know, people who work in government for ten, fifteen years ain't gonna help us, you know, people who came from privacy navigate the bureaucracy. What was it for for talent, recruiters. But, yep, I would tell them, you know, this work is really, really impactful. And I came here. I moved down here with my family three years ago, from New York City, and it was a big move. It was very scary. I won't lie. But if I had to do it all over again, I would do it again a 100 times over because because the work that that you are able to do here is just really amazing.
You know, I I I really appreciate your, willingness to show some vulnerability there. I I don't know that I've heard, much better as far as, like, pitches for a a role go. I I really appreciate you sharing that. Yeah.
So, like, this this I never did Civic Tech before this, and, like, I think now, this job has ruined me. Right? Like, I feel like I have to do Civic Tech after this. I can't go back to, you know, doing, like, Uber for dog walkers or something. I have to be it has to be Civic Tech, and being able to make that impact. Nothing like I said before, bureaucracy is hard. But, you know, just when you know at the end of that, that lane in the tunnel that you are really making a difference in someone's life. And anywhere you go in the federal agency, you are helping potentially helping millions and millions of people. And I don't think there's no greater feeling than that. David, again, thank you so much for taking the time out of your day to come and share your your thoughts and expertise with us here on Civic Tech Chat.
As is tradition, on these episodes, we like to give the guests the opportunity to set us up with whatever concluding thoughts, they'd like to leave us with as we depart the episode. So for you, David, what would those thoughts be?
So back in 2016, I built a site, and I I showcased it out to the USCS. And it uses the civil rights data collection set. And what that basically is is every two years, department education will go out and ask schools for information about students and just the school in general. So and that information is broken down by total enrolled students, by gender, and race. And one of the cool things that they have about it is, that breaks it down further. Right? So you could tell by race or ethnicity who was suspended and how many times, and then they break it down by how many students are in gifted program. So moving down in DC, my son was around two or three years old at the time, so we knew he was gonna have to put him in school. So we knew he was gonna have to move if we stayed down here and figure out the perfect school for him. And I was at the prime education at the time, and they asked us for our help on, like, how should they release this civil rights collection data set. And before they was doing it by CDs, and we was just like, well, first not by CDs anymore. And maybe you could put, it just on a CSV and and that way people can download it and they could throw it into Python and R if they want. So I ended up using this data set to find a good school for my son and what musical formulas talked to my wife. Musical for, schools that was diverse from a lot of times to go to a diverse school. And we was looking for schools that, while being diverse, didn't allow equally allowed every, ethnicity and race of students to be into the gifted programs or and a school that didn't have, like, a this portion of, like, one particular group of students getting, getting suspended. So we found that perfect school, using this data, and it was pretty cool because I ended up being able to showcase this to the deputy secretary of education at the time, James Cole. And I'm really got to sit down and and share with him, like, this is why opening data is important because people like me and and, you know, this was just something I built internally. It was built on Node. Js and Postgres. And and and from that, what ended up happening was so my son went to school. He just graduated kindergarten a couple weeks ago. And before he graduated, you know, they gave him a letter. He's been put into the advanced reading program, which is, like, really exciting because as we know, if if you get put in these programs early on, like like, it it it enables you to be more successful in the future. So I was really excited, and this data really helped pick that perfect school for my son. And, you know, all I wanted was just for him to go to a school where he had an equal as a black and brown student, where he had equal opportunity to, the same opportunities everybody else has in the school. And so over the weekend, I went to see how that changed because I knew this, the CRDC data comes out every two years. So I want to see how that data changed compared to before. Like, is the school same, like, as, like, when we first recently picked it? And, you know, looked at the data compared to they are the same. But then over, I was just like, well, you know, I use this for my wife and I, right, to find a perfect school, but I'm sure everybody else would love to just look at this and at a point. So I ended up releasing it, and it's on schooldiversityschooldiversityreport.com. And not anybody can try and find that good diverse school for their children and hopefully, you know, get hopefully for them, it works out the same way it worked out for my son. And I do think that that dataset did help. So I really think, you know, as I'm monologue in here, my closing thoughts, like, especially for, you know, the government listeners, government folks who are your listeners, like, open source and data is, like, really important. And, like, people like me, I didn't even know about this data. So even promoting the data is important. If I didn't know about this data and it really helped me pick the good school for my son. I guess the monologue could have been a little bit better.
I think that that was rather good. It's wow. Like, the the the way you managed to use your skills and and, like, the idea that his day was open to empower your son and then also to help empower others is is remarkable.
I I know there's gonna be folks out there that are gonna be inspired by that story. Yep. And, for folks who just wanna go, you can go to school diversity report, and and you can search it by ZIP code or your school name. It's easier by ZIP code to find a school, and now we could just pull up a a report of it. But my inspiration for building it was, you know, you know, just making sure that my son had a fair equal opportunity as everybody else and,
in whatever school we put him in. Well, I I really appreciate you you sharing that story with us and also letting folks know, where they too can can take a look at that at that tool and perhaps,
help their kids out as well. It's, all open source too. So you can find them at GitHub at githome github.com/davideholmes, slash c r d c. I originally built this in 2016 over a 20 project here at USDS over a couple days. So it's not the best code, but it certainly works. But if anybody wants to improve, they're more than welcome to submit full requests.
Excellent. And I'll, I'll make sure to, include links to, both the the, the the site and the repo that you just mentioned, for folks that want to explore and and maybe, start submitting those PRs for you. Yep. Awesome. I do wanna thank you again for taking the time to, be on the program. I I have no doubt that the listeners out there are gonna enjoy getting to hear your insights, lessons learned, and just getting to learn from, your experience.
Yep. And thank you for having me.
You can follow us on Twitter using the handle at civic tech chat. Visit us on the web at civic tech dot chat. Or subscribe to us for content updates wherever it is you download your podcasts.
