Lessons Learned from Brigade, Year One: Don’t Do This!

Posted on Feb 27, 2013 by Kevin Curry

Tags: Brigade and News

Recently I reported on the things that worked in Brigade’s first year. I wanted to follow up with this report on what didn’t work and lessons learned over our past year of civic hacking. Next month, in the final installment of this series, I’ll comment on how these lessons are informing our direction and taking us forward.

Lessons Learned:

1. DON’T Give Away Free Puppies

2012 Fellow Emily Wright Moore once quipped, “to a city, a free app is like a free puppy.” She meant that the costs for a “free” app are like the care, feeding and vet bills of the “free” puppy. They add up over a lifetime. Deploying apps is easy and that’s great because we can easily syndicate & maintain capabilities. Relevance, however, can’t be an afterthought of app deployment. You have to first figure out basic order of business. Let’s even assume supply & demand are given, that benefit outweighs cost by whatever form of currency, and that you just need to execute. This is a HUGE set of assumptions granted in order to illustrate all of the other considerations that remain: Who is the project owner and for how long? Who makes decisions and how? How does the app align with other information systems in a process? Does the app have a community of support behind it? Who will pick up the phone and answer email when people have questions and problems? These are all important to consider before you give your city a “free” app.

2. DON’T Over-promise or Hype Expectations

I’ve done it. We’ve all have. We’re passionate. We get excited. We are driven to share stories about good things. But expectations are too easily inflated and we should actively manage them. When you first meet with someone in government, for example, set the expectation that the engagement begins with basic awareness and moves through discovery before it proceeds into action. If we are active early it’s because that’s how we discover. Hackathons, for example, aren’t about promising new apps after 48 hours of caffeine. Hackathons about promising connections and possible solutions. Don’t start by making early promises to deliver on early assumptions. As relationships form, agree on a set number of priorities and be mindful of sticking with them (See also: Brigade DO #4). Set modest objectives and achievable goals in defined periods. Meet objectives, reach goal(s), assess improvement areas. Repeat.

3. DON’T Meet Without Purpose

Every meeting should have consistent format and a purposeful agenda, even if the agenda is to hangout and hack. You don’t have to be rigid to be structured. You might rotate your weekly meetup format among a hack night, invited guests, and demo nights, to name a few. It also doesn’t hurt if your agenda is simple and always the same: 1) round the room “stand up” to intro new members and check in with project reps and 2) break up into project teams & hack. You’re letting people know how to use the time.

It’s not that there is anything wrong with not having an agenda to hangout and it’s ok to not have an agenda every once in a while for a Brigade meetup. I have friends who organize events where agendas are outright prohibited and I respect that. I get it. But we’ve found that for the Brigade and civic hacking with purpose to thrive, purposeful meetings are key.

4. DON’T Overfeed the Good Idea Fairy

At some point you need to stop generating new ideas and act on one. It doesn’t mean you won’t ever generate new ideas again. It just means that you make a conscious, deliberate decision to stop ideating and start producing. See also Brigade DO #4.

5. DON’T Assume Public by Default

This lesson isn’t about secrecy. It’s about awareness and trust. We had a couple of situations where key folks were not aware of the public channels connected to our campaign activities. In our heads-down pursuit of interaction through open, public forums and actions to generate local awareness we put those folks in — surprise! — difficult positions. Mistakes happen in the CC line. The lesson here is that you should always let people know the moment they are included a public conversation. In email, use the convention of declaring new participants in the first line of a reply whenever the distribution expands, especially when lists are included ex: “Copying in Sally from Parks & Rec.” or “CC brigade@codeforamerica.org.” Add “this is a public forum” or “this is a private forum” when copying in lists.

Do you have anything to add to this list? Let me know on Twitter — I’m @kmcurry.

Archived post

Code for America recently moved its blog to a new home. We didn't want to leave anything behind, so we moved this post by Kevin right here. We hope you enjoy it.