Nava

Last week: Code for America . This week: onsite meetings at Centers for Medicare & Medicaid Services One thing is clear: there is real momentum across Federal Health IT. Themes that came out of CfA and the CMS IT Strategy Forum - trusted data, enterprise security, digital experience, and shared platforms, are actively shaping conversations and the investments at the program level. Nava being a Public Benefits Corporation, this is exactly the kind of mission-driven work we care about the most. It’s not just delivery or contracts. The people on the other side of these systems are real and millions of them depend on CMS every day. The energy is real and proud to be apart of the work. Olufunke Adefemi, MPH, PMP Sachin Nagar Nate Mudd Alex Prokop Sarah White Michelle Thong Margaret Spring Romina Pinili

📚 As a product manager working with government, I am often thinking about good service design, translating policy to delivery, and blending internet era methodologies with public sector values. This work is such a wonderful stew of ideas, skills, and people. Here's my spring reading list, adding more depth of flavor to the stew: 1. The SpecOps Method by Mark Headd (just started, love a book about mainframes!) 2. The Decision Stack by Martin Eriksson (the framework I didn't know I needed) 3. Leadership Unblocked by Muriel Maignan Wilkins (turns out I had some unblocking to do) 4. Crisis Engineering by Marina Nitze Mikey Dickerson and Matthew Weaver (been thinking about this one a lot and loved the inside baseball on healthcare.gov ) 5. Timeless Sensemaking for Modern Sensemakers by Abby Covert (loved her first book and can't wait to dig into this one) What's on your spring list? I'm always looking for the next thing to throw in the stew. 🍲

A lot of AI tools in social services get announced. Fewer get actually piloted. Even fewer share honest results. My colleagues in Nava Labs are doing the third thing. Next week - on Wednesday, May 20 at 2pm EST / 11am PST, they're sharing what happened when they put the Referral Generator in front of real Goodwill caseworkers in Texas and Pennsylvania. The tool helps staff connect clients to health and social services. It searches programs, surfaces matches, and generates a personalized action plan the client can take home. Free. Virtual. May 20 at 2 PM EST. https://lnkd.in/eXu4VaHW

Building AI for the public sector forces you to confront the reality of edge cases. In consumer tech, a model dropping a variable means a weird product recommendation. In GovTech, it means a citizen might not get their housing assistance approved. That shifts the entire engineering paradigm. We cannot adopt shiny new frameworks just because they look impressive in a demo video. We have to ask how they fail, why they fail, and how we recover when they do. My approach is rooted in defensive engineering. I assume the model will drift and the prompt will degrade over time. Because of that, I build strict verification layers and deterministic guardrails around the outputs. Our mandate is not to be innovative for the sake of it. Our mandate is to serve the public reliably. Do your engineering practices reflect the gravity of the systems you build? #CIVICTECH #PUBLICSERVICE #RELIABILITYENGINEERING #TECHLEADERSHIP

A government partner told us they could only use OpenAI because of federal guidance. Another had a volume discount with Anthropic. A third was evaluating Gemini. We needed to support all three without maintaining three separate pipelines. Our architecture: a factory pattern with a common interface. Every provider client implements the same method. Switching providers is a configuration change, not a code change. No engineer intervention. No redeployment. This matters beyond technical elegance: - Provider outages happen. When one API goes down, we switch to another. The pipeline keeps running. - Models have different strengths. Some excel at structured extraction. Others handle long documents better. Others are more cost-effective for simple stages. - Government procurement is unpredictable. Telling an agency "you must use Provider X" is a non-starter when they have existing contracts, security requirements, and authorization boundaries. Vendor lock-in is always a choice. In AI applications, it's a particularly risky one. The model landscape shifts every quarter. The provider that's best today may not be best in six months. Build for portability from day one. #AI #MultiProvider #Architecture #LLM #CloudStrategy

Stop optimizing for 100 percent test coverage. It feels good to see a "green bar" hit 90 or 100 percent. It looks great in a management report and provides a warm sense of security. But in the trenches, we know the truth. High coverage does not equal high quality. RESEARCH SHOWS THE GAP A landmark study by Inozemtseva and Holmes found only a low to moderate correlation between statement coverage and actual fault detection. You can execute every single branch of your code and still miss the logic errors that crash your system. Coverage tells you which lines were touched, not which behaviors were actually verified. THE COST OF THE ILLUSION When we mandate high coverage numbers, we unintentionally encourage test bloat. Engineers start writing "change detector" tests that mirror the implementation line by line. These tests do not catch bugs. They just make refactoring a nightmare because the tests break the moment you move a single internal method. A BETTER SIGNAL I have moved my focus toward mutation testing signals and refactoring resistance. If I can change the internal logic of a function and the tests still pass, the test suite is weak. It does not matter what the coverage percentage says. Quality tests drive engineering outcomes. High test quantity just drives up maintenance costs and drains team morale. In the GovTech space, we cannot afford the overhead of bloated, useless code. We need tests that provide a high-fidelity signal so we can modernize systems safely. Stop measuring how much code you touched. Start measuring how much of your behavior is actually protected. Are you measuring the strength of your safety net, or just the size of the holes? #SoftwareEngineering #GovTech #SoftwareTesting #CleanCode #QualityEngineering

Nava is on NASPO! This might not mean a lot to most of you, but it means a lot to me. We see urgent challenges all the time – production systems that need stabilization, backlogs that need immediate work, legislation that has cascading operational impacts. We also see that navigating procurement is a huge struggle, and the states that have the least capacity often have the most need for support. It took us awhile, but I'm very excited to have joined the National Association of State Procurement Officials (NASPO) ValuePoint’s nationwide Cloud and Software Solutions cooperative purchasing agreement. This is a ten year contract period that enables us to more rapidly deploy fast, secure, and most importantly, *open* solutions that can meet agencies where they're at while not locking agencies in to proprietary traps. On our side, we're excited to be working with states on preparing Participating Addenda, and are committed to moving quickly ahead of this contract period beginning in September. https://lnkd.in/gDAT_3_Z

It all comes down to finding people who care. This is one of my biggest takeaways from the past five years, where I’ve helped build paid family medical leave programs for states across the nation. When I started at Nava, we were working on our first prime contract helping launch a brand new paid leave program for the Commonwealth of Massachusetts. Today, we’ve helped distribute nearly $5 billion to more than a half million families and are building paid leave programs in three states. Our secret sauce: getting the right people in the room. Our talent model starts with cultivating a pool of paid leave delivery experts. These staff know the ins and outs of the program, and have been in the trenches of building paid leave – nearly 30% of our Nava staff have worked directly on paid leave programs at some point. We also learned to structure our scrum teams around the program itself. Based on the concept of team topologies, we now align scrum teams around the applicant, employer, staff and payments experiences, each with their own mix of skills and product roadmaps. Finally, so much boils down to making sure we hire people who align with our mission at Nava. I’ve spent my career in public service learning from incredible leaders across City of New York , and received training on the social determinants of public health from some of the best practitioners out there at Columbia University Mailman School of Public Health . I’m proud I get to apply my experience, skills, and talent and be part of building paid leave programs that offer relief for people during their most vulnerable times in their life, from birth to death. At Nava, we hire people who feel the same. And that's ultimately the winning strategy. Read more about our work building paid leave here: https://lnkd.in/g4dFgBiw

Jennifer Pahlka 's take here resonates with my last twelve years of operating experience in the field. The fundamentals and first principles of public benefit technology haven't changed (start with user needs and work backwards to solutions; don't use a complex, brittle solution when a simple, reliable solution will do; etc.), but the landscape of delivery possibilities, technology risks, and tradeoffs in service of outcomes is very different now. If more public benefit technologists embrace working the (very frustrating, complex, slow) H2+ class of problems, we will have a better chance of the deeper system reforms needed to deliver outcomes quickly and adapt at the pace of relevance. https://lnkd.in/g8XZ3MSi