What I Learned About Public Engagement While Designing a Data SystemPublic agencies and nonprofits invest a lot of time and money in public engagement. We host listening sessions. We run workshops. We collect comments and publish summaries. And still, many people walk away feeling that the process didn’t really shape the outcome. Often, the problem isn’t the intention. It’s that most public engagement processes aren’t designed to learn. I noticed this more clearly when I stepped outside the traditional policy world. About five years ago, I got lucky to lead a team developing California’s Homeless Data Integration System (HDIS). I came in as a policy and government technology person — not a software developer. My IT colleagues suggested we use an Agile approach. I knew the method in theory, but I had never actually worked within it. A few weeks in, working with a Scrum master and learning a whole new vocabulary, I started asking myself: Why don’t we work this way in policy, especially when we do public engagement? Part of the answer, I think, is accountability. In software, when you click a button, something has to happen on the screen. The feedback is immediate. In policy, we design programs and may (or may not) see results years or even decades later. What stood out to me in Agile wasn’t speed. It was the discipline around learning and transparency. Every request had to be tied to a real user, a clear purpose, and a decision it would inform. We couldn’t say, “People want this.” We had to say who wanted it, why, and what would change if we built it.
Equally important were the regular debriefs (retrospectives) where the team openly discussed what worked, what didn’t, and what to try next. These weren’t blame sessions. They were structured moments to reflect, adjust, and move forward with more clarity. That kind of structure is rare in the policy world. Most public engagement asks communities to “share their thoughts” without being clear about how that input will be used, what constraints exist, or what decisions are actually on the table. We collect input, but we rarely show how it shaped tradeoffs, or why it didn’t. This is where engagement starts to feel performative. Agile didn’t make our work faster. But, it made it more honest about constraints, decisions, and learning along the way. That honesty is what many engagement and planning processes are missing. None of this requires turning government or non-profits into a tech company. It requires treating public engagement as a learning system, not a box to check. For those of us focused on community impact measurement, this shift matters. Impact doesn’t come from how many meetings we hold. It comes from whether engagement actually shapes decisions, builds trust, and improves outcomes over time.
This piece kicks off a short series exploring what policy and planning can learn from Agile—not as a methodology, but as a design mindset.
|
