On Volunteering as The Second Mountain With Mike Foreman

U.S. Digital Response
U.S. Digital Response
7 min readJul 28, 2022


By: Barbara Niveyro

Mike Foreman was inspired by his grandmother — who was a programmer for the United States Army Corps of Engineers — to choose his career path. After working for decades in leading roles as a VP of engineering with corporations and the government, he retired a few years ago. That’s when he discovered his new career path, his “second mountain,” volunteering with USDR.

Barbara Niveyro, USDR: Thank you, Mike, for spending this time with us. Just to break the ice, can you tell us a little bit about yourself? What’s your background?

Mike Foreman: My grandmother was a programmer for the United States Army Corps of Engineers in the 50's, so she was one of the first programmers in the world. I got interested in it then, and worked to earn a degree in computer science from Virginia Tech and an MBA in finance from the University of Maryland. I’ve worked for lots of big companies, and about a dozen startups, including one that started in my basement. I’ve done public sector systems, accounting systems for federal, state and local governments, and a lot of high-tech startups. I’ve been a VP (software engineering, Product Operations, R&D) for about 10 or 12 companies. Now I’m pretty much retired. The last big role I worked was for a company called Blackboard, which has a big learning management system that is used by a lot of colleges and universities.

BN: How did you get involved with USDR?

MF: I got involved with USDR because I read a great book by one of my favorite authors, David Brooks from the New York Times. He wrote this book titled The Second Mountain. It is about after you’ve had a successful career, what do you do next? You do things to help the community and help people. And then I read an article about how USDR had been helping the City of New York to do public sector work, and they were looking for volunteers. So I signed up and I’ve been working there now for about two years: victim services projects in California, and as a project lead for the poll worker system for a year and a half.

Mike participated in USDR’s recent series exploring how the Poll Worker Management tool was built

BN: What was your expectation when you joined USDR as a volunteer and when you joined as a project lead for the poll workers system?

MF: My expectation was that we’d be able to make a difference. Generally, the election departments are underfunded and under-appreciated, and now many of them are under attack, and they are struggling. So anything we can do to help them is a good thing. The organization’s vision for poll workers is that we can make a difference across the country because almost all counties, which run their own elections, are underfunded and understaffed. There are very few good solutions in the marketplace that they can buy and even fewer they can afford. Working at USDR we have pretty much a team culture, we all have fun and work hard, and we get great feedback from our partners. Typically, volunteers work for about six months. So there’s always a lot of turnover on the teams and some of us have been sticking with it for a while, like myself.

BN: If you had to define the three main goals of the poll workers team, what would they be?

MF: Our biggest goal is to be able to scale the poll worker system, to hundreds of partner sites in a manner that we can support and will make a huge difference across the country. We are nonpartisan, which means that we don’t belong to a specific party, and have around 12 to 15 partners that we support right now with a team of about six people. And there are potentially a thousand or a little over a thousand counties that would be good partners for us to work with. We initially want to be able to scale to a hundred. So our goal is to make the system self-supporting and to train the local election departments.

BN: What are some of the tools that you work with?

MF: The primary tool is Airtable, which is a low code development environment. We’re finding that our partners that initially use the poll worker system can also build their own add-on systems in a matter of days to do all kinds of things. So we’re not only helping with the election management of poll workers, but we’re helping seed the ability of the election departments to innovate and create their own solutions that they can maintain themselves.

BN: What are the main partners that you are interacting with?

MF: The main partners that the poll worker system interacts with are counties. USDR overall interacts to some degree with the Federal government, but mostly with state, county, city & territory governments.

BN: And internally, for USDR, how are the teams organized?

MF: Teams often have a project lead and one or more volunteers that we match from a pool of people that have volunteered. There are a couple of people that are available during the day. We have volunteers working full-time and they volunteer their time in the evenings. Generally, I staff the poll workers projects with whoever’s available, interested, and is a good fit, depending on the complexity of the application. There are a couple of core staff & volunteers on the project. Melissa House, who’s now a USDR staff partner engineer, and I are pretty much leading the technical side. And we have five or six engineers who come in and volunteer as needed.

BN: Can you share a challenge that the team recently had? How did you figure it out?

MF: We learned that the Airtable low code development environment was pretty easy to learn. Anybody that has a software engineering background will pick up the technology in less than three days. But there are a lot of routine software engineering practices that have not yet been developed — we have to create workarounds and processes to make up for some of the current deficiencies. However, the Airtable team is also continually improving. It is also very important for us to conduct a good requirements analysis. We document requirements, but we generally don’t produce a lot in the way of development or software documentation that you would see on a typical project. We’ve moved too fast for that. Sometimes we bring up a partner and get them running in two weeks. One thing we always do is that we document everything in the code and add user help and hints in the user interface itself.

BN: When it comes to volunteering, a lot of people tend to believe that they will provide their time to benefit a person or a community, but they don’t know how rewarding the experience is for themselves. What were some things you learned through the process of volunteering?

MF: Working for a large organization where you’re building a software product, the development engineers work for a long time, and when a product finally goes out, you usually don’t hear from the customers. You don’t get any good direct user feedback as a software engineer in a large organization. When you’re working as a volunteer you’re dealing with the end users, which you would normally never get to work with. You get to learn what their problems are, and how they work. It is most rewarding when you solve their problems and save people thousands of hours of work. It’s just unbelievable how rewarding it is. And every time you talk to them they’re just profusely thanking you all the time for just making their lives a little bit easier.

BN: What would you recommend to someone that is looking to volunteer for the first time?

MF: It depends on what project they’re volunteering for. If they’re volunteering at USDR, we have lots of different projects. Generally, engineering & product-focused volunteers build low-code development environments for rapid deployment and we’ve picked Airtable as our primary one as it has a good pricing model for public sector systems. We build React apps and other software apps as well. When we interview people to be volunteers, we look for them to be able to collaborate & work alongside partners who may not know what they need. They can describe their problems and you have to interpret their problems and figure out a technical solution for them. So you have to be a little bit of a business analyst and a little bit of a requirements analyst. USDR’s pool of volunteers has a range of skills from UX design to content strategy to engineering to user research, though if interested, you have opportunities to do everything from frontend design, implementation, and training. And generally, you have to do the whole thing in a matter of weeks. So we look for multitalented, multi-skilled, experienced people able to jump into new environments.

BN: And what about a suggestion for someone that is trying to volunteer, just in general, not necessarily for USDR?

MF: I would advise them to go for it. Do your best and don’t hesitate to volunteer for any project. Just be honest and upfront about what you know; what you don’t know; what you think you’re not good at; what you would like to do; and how many hours per week you can spend volunteering. So I would advise people to go ahead and try it because we always need more volunteers. And if you like it, you will do it longer. With USDR just raise your hand and say how you would like to help and we’ll do our best to find a place for you.

Interested in using your skills to help people in your community?

From content strategists to software engineers, there’s a spot for you at USDR. Learn more about USDR or sign up to volunteer your time at www.usdigitalresponse.org/volunteers.

Have more questions? Watch a recording of a past Volunteer Info Session or register to attend an upcoming session.



U.S. Digital Response
U.S. Digital Response

Connecting governments and nonprofits with pro bono technologists and assistance to quickly respond to the critical needs of the public.