So You Think You Want to Run a Hackathon? Think Again.
Laurenellen McCann!!
932

On Participat*ing*

This is the first post of a brand new blog I’ve started on buildwith.org exploring best practices and picking apart the challenges to community collaboration in tech and governance. #BetterTogether.

I first wrote the phrase “build with, not for” about a year ago today. It was a parting thought from a longer piece (So You Think You Want to Run a Hackathon? Think Again.) critiquing the-default-to-hackathon impulse that still seems to take hold whenever a government or non-profit or other sort of institution is confronted by the simultaneous desire to do something with tech and to build community.

“Build community.”

Over the last decade, spurred by the rise of certain technologies (social media! smartphones! internet!?!?) and the popularity of populism (*~*crowdfunding*~*), “community building” has taken on the air of a finite project, a Thing that organizations in and out of the tech world can report having Done if they host a happy hour, build an email list, slap up a social media account, or run a hackathon.

But we know that communities and their construction are far more complicated than that.

Communities are, and operate through, relationships.

Relationships, social capital: if “community building” is meaningful as a practice, it is as the practice of forging, supporting, and stewarding relationships not just between an organization and a buncha individuals, but between those individuals. (This is one of the biggest differences between a “community” and a traditional “audience” — which will come into play in a later post when we examine common strategic missteps non-profits and governments make.)

Relationships take time. And work. Being their steward and spurer requires less the skill of reading a recipe* and more the skill to…improvise. It’s the skill of being present enough with the group of people you’re trying to engage that you see the communities they already participate in and find opportunities to work in partnership. It’s the skill of listening and stepping back before volunteering to create something new. (Sound familiar?)

It’s the skill of participating.

If you don’t participate in the lives of those you seek to organize, you can’t form relationships to these people and you can’t inspire them to form relationships to each other. No relationships? No community. It’s that simple.

Over the next little while on my new blog over at buildwith.org, I’m going to dig further into these issues, examining relationship and community building as they relate to civic engagement, with a particular eye to challenges and best practices relevant to technology and governance. (Separately and together.) The nuts and bolts of building with, not for.

To kick things off, I want to return to my piece from last year and share with you the reflection that got me started on my own journey with co-design:

In the civic tech space, we talk a lot about “open source” — code made available for anyone’s reuse and remixing, with the knowledge that opening up to the contributions of many can allow for the discovery of problems, patterns, new ideas, and opportunities that one alone might miss.
Open format events are like open source social code — rough rubrics that can be “forked” (borrowed and altered) to mobilize people around technology.
But you have to be smart about it.
Dragging and dropping a format for community-building without first evaluating the context in which you’re organizing and who you’re organizing for is a recipe for exclusion and redundancy. The reason we didn’t jump into a hackathon at the Funk Parade was because we knew, after evaluating our criteria for a “good” event in that context and the people we wanted to bring together, that a hackathon wasn’t the right fit — but that didn’t mean that we couldn’t do anything technical. It was just a design challenge, prompting us to ask in real terms (not aspirational) what structures we needed to borrow, what attributes we had to re-imagine (and, worst-comes-to-worst, create)that would allow us to bring together the most diverse group of DC-ers possible.
Diversity is about a lot more than race and gender. It’s about age, class, background, profession, sexuality, neighborhood, World Cup team…the many ways in which people identify and are identified. When we willfully ignore diversity in the design of our technology, our social spaces, and our “community meet-ups”, we trivialize a future where universal technology access is meaningful and dynamic — not just about literally having access to tools.
So here’s my plea for “building community” around civic tech, whether in the context of an event, a new project, or something else all together:
Build with, not for.
Be honest about the in-groups you’re dealing with, invest time in thinking about the impact of place (online and off) on who gets to engage and how, and borrow liberally and often from ideas you see working. (Actually working, that is.)
In creating The Tech Embassy, we had the luxury of knowing many of the alternative structures that we could borrow from. But now, you do, too.
[Full text here.]

Onward and upward, cuties.

// L(e)

*Three hackathons, a dash of happy hour, a pinch of salt, and call me in the morning.


Interested in continuing to dig into the practice of community collaboration in tech & gov? Check out my new blog on buildwith.org.