Leading the Field: Ron Bronson

For our “Leading the Field” Q&A series, we’re speaking with leaders in the civic/gov tech space who are driving important change to make government work by the people, for the people, in the digital age. In advance of our upcoming Summit, we’re talking to some of the speakers to hear more about their journeys in civic tech. This week, we spoke with Ron Bronson, the former Head of Design at 18F. At Code for America, we welcome a broad diversity of viewpoints—and we strive to let people speak in their own words about their own unique experiences. With that in mind, the following has received only minor edits for length and clarity, and the views expressed here reflect those of the author.

Can you tell us a little about what first drew you into working in civic tech?

I didn’t seek out civic tech as a practice, as much as it kind of happened organically. I spent years working on large websites, mostly in university settings in my early career. Then I took a leadership role once for a state community college system, which was my first non-campus job. Once I got a handle on that, it was clear to me that I liked being at the level of the work and from there, I ended up in local government. What drew me to the work was having an impact everyday on the people who are your neighbors—the federal government made that a bit more challenging, but having an org like 18F where all the people were from virtually every nook and cranny of the US helped us to still embody that same spirit.

You call yourself an “interaction engineer.” What does that mean to you, and how does it change the way you approach systems design?

You know, I could just as easily call myself a software plumber instead of an interaction engineer. As someone who thinks of his work as “critical service design,” what I’m asking is: Where are the fissures? What are we breaking? Can we shore up things? Building new stuff is great, but what I think gets overlooked is repair. I’m not talking about bugs; I’m talking about edge cases. My background is somewhere between information architecture/content strategy, and service design, but spending the last few years leading design, and also teaching, has left me with a different lens of how I view the design work. 

Craft is unfairly perceived as slowing things down, especially when you’re doing research and asking questions. So often the role of design is justifying itself—and that feels weird to me. Not from a pixel perspective, folks are fine with that part. But all the other things we do—content, research, the middle layers—that’s the real work in my estimation.

Interaction engineering is as much a statement as it is a practice. It’s saying: What things do we value and can we call that a practice? UX has been watered down, interaction design gets boxed in by toolkits, and “customer experience” wants to subsume us all. I started using nomenclature that felt closer to what I think the real work is. I’m not convinced this is it, but it’s worth having those conversations in the field. 

I value all the disciplines mightily, and one of the things I’m most proud of during my time at 18F is how successful we were at growing the design practice and pushing the boundaries a bit to find roles that fit the needs of our stakeholders at partner agencies. Now that I’m back on the “outside” again, I’m curious about the ways that we can make design be seen as truly integral rather than something to delegate and outsource—or worse, ignore. 

Building new stuff is great, but what I think gets overlooked is repair. I’m not talking about bugs; I’m talking about edge cases.

You’ve recently transitioned from working in the federal government to doing more local work. How do you apply the learnings from the former setting to the latter?

These days, most of my local work is through volunteer efforts, but last year I had the chance to teach a design studio at the University of Michigan. During that, our class worked on a project with the state of Michigan growth office, so it was truly a worlds-colliding moment for me bringing all my experience into the classroom in this way.  It was a really interesting opportunity to take the learnings we’d been deploying and bring them to the classroom for non-technical stakeholders. The lesson was that a lot of these practices involve working in the open, thinking holistically about what your residents need, asking questions, and doing iterative work and improving on it. That applies no matter what level of government you’re at. 

Has there been a project that’s really excited you lately?

A month ago, I launched an all-volunteer digital service sprint called the Portland Digital Corps. Our goal is mostly a short-term effort to help do some good for non-profits and agencies around the state. The response has been surprisingly overwhelming, with lots of people volunteering to help out. I really thought it’d be me and a dozen people, but it’s been invigorating to see how many people in the community working in tech are seeking ways to give back. And it’s not all people in career transitions—more than half of them are still employed but just like the idea of participating. 

You’re speaking at Summit this year. How does your session “You can carry on where 18F left off” speak to the theme: designing for change, delivering for the future?

Being in the weeds of the work, it wasn’t clear to us all the time how many people really appreciated not just the work that 18F did, but also the shareable outputs of our work, like the guides we produced. I’m excited to be able to share that with people while 18F is “gone.” The ideals and practices are things that we can adopt in our work wherever we are—working in the open, admitting when we’re wrong and how we’re doing better, improving stuff iteratively, documenting our lessons, and being willing to share what we’re learning with others. 

Want to hear more about Ron’s work? He’s presenting a breakout session at Code for America Summit, happening May 29-30 in Washington, D.C. Find out more about Summit and get your tickets today.