How Solutions Engineers Think Holistically About Technical Challenges

A lot of hands touch each product, service, and policy that gets designed at Code for America. From client research to marketing, everything we create goes through a collaborative process full of feedback loops, iteration, and countless Zoom meetings. We want to hone in on one particular part of that process today: how solutions engineers ensure our technical problem solving and design processes reflect Code for America’s values. To learn more, we sat down with three of our solutions engineers: Melanie Gin, who works on the local initiatives team, Chris Correa, who works on the criminal justice team, and Alex Markello, who works on the safety net team.

To start: Can you explain what solutions engineering is, exactly? How is it different from traditional software engineering?

Alex: When I think of traditional software engineering, there’s an expectation that you’re going to create custom code from scratch to build an application or other technical solution. With solutions engineering, we’re going into existing environments where there’s already an entire technical architecture in place—so our job is to go in and figure out where and how to make changes. We have to learn that architecture inside and out so that we can figure out the technical feasibility of any improvement we might suggest and then build the team needed to make that happen (some of whom might be software engineers). Solutions engineering recognizes that we need to truly understand a partner’s business operations, development processes, and product management before we do any coding—because the biggest problem might not need a technical solution. It might be changing how a business process is executed. It’s a discipline that requires an open mind and a desire to look for a holistic solution as a strategic technical thought partner.

It sounds like this involves a lot of collaboration with other internal disciplines and external government stakeholders. What does that look like from each one of your respective positions?

Chris: Collaboration looks different for every project or engagement. On the Clear My Record team, solutions engineers are working really closely with the program staff at Code for America who have been building relationships with organizers and policy people and workers at state agencies. They bring solutions engineers into the conversations when there’s a technical challenge, and often we’ll come in at the same time as our data science colleagues. In the automatic record clearance space, a lot of the technical challenges we’re encountering are data spread problems. Things like eligibility determination, which means creating a rules engine to determine who’s eligible for expungement based on policy criteria, and entity resolution, which means how you’ll resolve issues where people are listed twice in a database. Solutions engineers can play a critical role in doing data mapping and figuring out how to get data from different technical systems to talk to each other. 

Melanie: Our Local Initiatives team is smaller—just eight people—and we work really collaboratively with city and county governments who are looking for help with projects where tech could make a big difference. A colleague on our programs team will often build the initial relationship with government leadership and staff, who work with us to identify programs and services that could benefit from technical solutions. I come in with a service designer to map out the journey that a client takes to access a government service. How do they hear about it? How do they apply and enroll? What are the technical systems currently in use for each of these steps? Let’s say for example that a city is offering a job skills training program for young people, and a person has to enroll in that program via a technical system, and then a government worker tracks their performance in another system. As we map the process, we would work with government staff and participants to identify existing pain points in that process, and to see where technical improvements could be most beneficial. And then our volunteer partnerships team, qualitative research, and I work together to help government staff to improve existing technical systems and integrate new products that reduce administrative burdens and improve service delivery for current and future residents. 

It’s a discipline that requires an open mind and a desire to look for a holistic solution as a strategic technical thought partner.

Alex: On the Safety Net team, the solutions engineers are working with program managers, service designers, UX designers, qualitative researchers and data scientists—but my greatest thought partner is usually the product manager. They’re crucial for scaling down tech requirements and finding the minimum viable product to test before making it bigger and better. In a vacuum, I could go into a system and find a million places to make improvements, but I’m relying on them to take in all the criteria the rest of our team members are surfacing (which includes my inputs on technical feasibility/scope), synthesize that data, and prioritize which changes we ought to make. The best criteria may be how many people a change would impact and if those people are part of a marginalized population we’re trying to center. For example, if we know that 50% of people applying for a safety net benefit are dropping off the application at an income-related question, we have to poke around and see if we can reword the question or rework the application flow. We take impact numbers into account when considering technical feasibility and resource requirements. Everyone puts their piece of the puzzle together. 

Can you tell us about a specific challenge you’ve encountered in your work and how you approached finding a solution?

Alex: On the Safety Net team, we’re often working with legacy systems, and it can be a pretty gnarly challenge at the beginning. It requires a lot of intense discovery and research work to see where all these systems are intertwined—and a lot of the time, this work doesn’t come with documentation. Sometimes the first step is finding that one person who’s worked at an agency for 30 years and has all the knowledge about systems and processes in their head. 

In a state we worked with recently, we worked to implement a new document uploader tool so that clients can submit verification information for their benefits applications from their phone or computer. On that project, our product engineering team (made up of traditional software engineers) created an internal tool for uploading documents that’s managed on our Code for America-run infrastructure—but then we needed to transfer those documents from our system to the state’s legacy system. This is a different situation than traditional new-product software engineering where you’re coding up a technical solution that doesn’t necessarily need integration points with old systems. In the end, we built a robotics process automation (RPA) bot to transfer the documents between systems, which took a lot of collaboration between our solutions engineer and the state IT team to implement a significant amount of custom configurations, and deal with new technical blockers that came up when we did that. The ideal solution would have been if the state’s technical system had an application programming interface (API) endpoint that we could hit to transfer the docs, and we’re hopeful to iterate on and modernize the solution with their teams as we continue our partnership work.

Melanie: I want to highlight the work of one of our Solutions Engineering colleagues, James Armes, who worked closely with product engineers to support GetCalFresh in updating its systems architecture. James and some of our product engineers recognized that completing a database migration to a commercial AWS platform would reduce costs, improve our security posture, and reduce the latency of page render. Over multiple weeks, our team collaborated directly with product engineering to implement this highly impactful change—resulting in latency reductions significant enough to be perceptible upon page load.  

Chris: A special thing about working on the Clear My Record team is that we’ve worked with over 20 states now and we can bring a national view to state-specific problems. It’s often that we encounter a court system that has similar challenges to another state, so we can share a prototype and show them a viable solution we know worked elsewhere. With a proof of concept, we can show them what’s possible and alleviate concerns about process change.  

With a proof of concept, we can show them what’s possible and alleviate concerns about process change.  

How do Code for America’s core values show up in your work?

Melanie: Often a local government will approach us and ask for support building a website or application for a service. I try to respond by listening first, asking: how did we get to that solution? What need will that product address and who is it for? Will implementing it reduce staff administrative burden and/or improve the experience of clients accessing a service? Sometimes technical solutions directly impact clients, and other times the impact is achieved indirectly—for example, a tech solution might reduce the time a caseworker spends on forms, and that frees up a few hours per week they can spend with clients. Before we build anything, I want to understand the perspectives of all the stakeholders who will be impacted by the ask: government leadership setting the vision, staff requesting the product, community organizations who are often providing the service, and people with lived experience. And finally, I want to understand the existing technical landscape and how each stakeholder utilizes systems to collaborate in the ecosystem.

Chris: Government agencies have resource constraints; we also know that sometimes it’s not a tech solution needed but a policy change. We’re acting very intentionally. We don’t go in with a predefined solution, we just want to find the most transformative change we can make—and if that requires technical capacity a government doesn’t have right now, we can come in and work with them on it.

I try to respond by listening first, asking: how did we get to that solution? What need will that product address and who is it for? Will implementing it reduce staff administrative burden and/or improve the experience of clients accessing a service?

What do you find most rewarding about your work as a solutions engineer?

Melanie: I really enjoy thinking about engineering through a human-centered lens, where personal impact is as important as technical impact. I’ve worked in software engineering in the past, where I was coding daily but didn’t have direct insight into user research. And I’ve worked in consulting, where I improved business processes but didn’t speak to the company’s clients. It’s refreshing and humbling  to speak with folks with lived experience who are directly impacted by the technology I’m working on.

Alex: For me, it’s all about impact. A technology solution could make a difference that impacts millions of people who are the most vulnerable in our country. That’s unbelievably rewarding.