Note from the publisher: You have managed to find some of our old content and it may be outdated and/or incorrect. Try searching in our docs or on the blog for current information.

We’ve recently been exploring signals around engineering productivity in order to share metrics teams can look at to know if they are on the right track (the results of our research here). We were surprised and deighted when our research revealed that Code For America was leading the pack in measures of engineering velocity. We spoke to two members of their team, John O’Duinn and Ben Sheldon, to learn more about how a non-profit focused on delivering services for the public sector is able to maintain incredible speed and engineering productivity.

O’Duinn, an infrastructure engineer, says of their work, “It’s not AI for robotic cars.” And it’s true: the products they build aren’t flashy. They don’t work in hot or trendy problem spaces, and they don’t necessarily use bleeding-edge technologies to solve problems. Their focus is helping people, creating value, and staying lean. “Our problem domain isn’t particularly clever,” says Sheldon, a senior software engineer there. “We help people navigate the food stamp application process [with our product, GetCalFresh], and it’s essentially a series of web forms that we help people fill out. It’s not a super hard computer science problem.”

So what’s their secret? We break it down into 3 main tenets: a commitment to best practices upfront to prevent future cleanup, an attitude of “anti-perfectionism” which in turn enables a tight feedback cycle, and absolute alignment on a shared common goal. By executing on these values, Code for America has been able to incrementally improve their process every day, leading to real change in their users’ lives.

In our conversation with Ben and John, we learned how their attitude toward, and processes around, building products can have more of an impact than using cutting-edge technology.

1. Build good systems upfront.

At Code for America, communication and context-sharing are baked into every part of their process. Daily standups and pair programming are both vital to their workflow, allowing them to ship code quickly with minimal risk. They aim to have two sets of eyes on every line of code that gets deployed. In service of this goal, they practice pair programming, in which developers work together to code a feature or a fix. This method not only produces better code, but because the code was written collaboratively, also eliminates the need for traditional code reviews. Additionally, they have 95% test coverage, which allows them to ship new code with very low risk. If tests are green, they merge and deploy: done. With these two practices in place, developers can focus their energy on building value rather than going back to fix unexpected bugs. This allows them to focus their daily standups on future-planning:

“A lot of our code review process is less around whether you’re going to break something and more around making sure other engineers know that this change is happening and have an opportunity to talk at a high level about architecture or where the codebase is going in the medium to long term.” –Ben

2. Enable tight feedback loops by embracing anti-perfectionism

One of the most inspiring things about Code for America’s process is all the ways in which they intentionally outsmart the perfectionist tendencies we all have as human beings. Because they are so aligned on their goal (see #3, below), they don’t want to waste any time not getting value to their users. We loved hearing about the many processes and safeguards in place (some intentional, some logistical) that, combined, push them to get the job done just well enough.

First, they are constantly prototyping new ideas as simply as possible:

“One of the things I view as a feature — not a bug — of the mindset here is that people will literally do whatever hacky duct tape approach they need to get a single person through, and they use that as a case study for how to start making it better. Hand-filling PDF forms? That is so not scalable! With the Irma hurricane shelter — they literally started off with, “Here’s a spreadsheet, anyone has access,” which is a recipe for total non-scaling disaster. But! as they started to streamline it and learn a bit, and they structured it more, they learned by the initial real data that came in. So it really is learning by doing live.” –John

Code for America employs many tactics to get as close to their users as they can. One of their most impressive team tactics involves a daily team-wide sprint: From 4-5pm each day, the entire engineering team looks at all food stamp applications that couldn’t be automatically submitted based on existing scripts. For the next hour, they do whatever it takes to submit every application before the 5pm cutoff. By getting their hands dirty, engineers discover exactly where their gaps are:

“At the end of the hour …we discovered seven people who were stuck with this particular problem. If we could fix something today to make it so that we didn’t have seven people stuck on those same problems tomorrow…that’s seven more people getting food. That’s why there’s a relentless focus on what little baby steps you make today.” –John

We admire their company-wide culture of low-fidelity experimentation: each team member is empowered to devise and test new creative solutions. It’s important not to be precious about anything– and this shows at every level, even in the openness to scrap the whole project and begin again if necessary. One amazing thing we learned is that each of their 3 main products has at some point been thrown out and started from scratch.

“There is definitely a willingness to start over. For GetCalFresh, I think we’re maybe on the third full redo of the application. So originally there was that first Typeform and glue thing. And then there was another kind of “bridge” app, where it was a little bit of Ruby on Rails and in Typeform. And then there was another full rewrite, which is what we’re developing now.” –Ben

Throughout this commitment to experimentation, they are also actively thinking about optimizing processes and creating habits that they can learn from. Since they want to keep growing their organization and solving new problems for people in need, it’s important to them to keep good notes, learn from their trials, and as a result, increase odds of new products surviving.

3. Absolute goal alignment

Code for America’s primary key for success in making real, measurable changes in their users’ lives. Because fiddling for too long on any one decision could mean someone doesn’t get access to food for the day, they are deeply motivated to get the job done and over the fence any way they can:

“You know, in other jobs, you have a lot of different hierarchies of needs, where [one can say], “Well, we have this customer segment and that customer segment and enterprise and they have an SLA, but these customers don’t.” But for us, it’s much more just like, “Somebody applied that needs food stamps. We want to make sure that we get their application to the county as quickly and in a high [enough] quality way that the county can process it quickly and that person can get food.” –Ben

Thanks to Ben and John of Code for America for showing us inside their organization. It was inspiring seeing their examples of how deep commitment to a shared goal can give you the push you need to do experiments, stay lean, learn quickly and stay user-focused.