Alex Soble

Fellows and Brigades

Cross-posted on the Code for America blog.

Code for America is many things: an international volunteer organization, a fellowship program, a permanent staff organized into teams, a peer network of government practitioners. How do all of these different parts work together as one Code for America?

I am curious about how two branches of Code for America in particular could work together: fellows and brigades. I started off in civic tech by attending Chi Hack Night brigade meetings as a volunteer. This year, I’m a Code for America fellow. Along the way, I’ve heard the notion that brigades redeploy fellowship apps in their own cities. But this model of collaboration never struck me as very compelling. As a fellow, I wasn’t sure how to approach working with Code for America volunteers until I met (or, more precisely, followed on the Internet) a person named Melody Kramer.

Melody works at 18F and has a long history in public media. She is currently a Niemen fellow thinking about public media membership. She has turned her fellowship into an open, collaborative project. What I find spectacular about Melody’s work is the way she first lays out the problem she’s working on, then invites her audience to become members of her project.

Even down to the little things. Melody opened up her logo design process to get feedback from her Twitter followers:

Could Code for America fellowship teams make their projects stronger by borrowing from Melody’s way of doing things? Would our projects be stronger if they were volunteer-driven? How deep could volunteer involvement in a fellowship project go?

  • Could brigade members help fellows conduct user research?

  • Could they help us make technical decisions?

  • Build out features or extensions to fellowship projects?

  • Help us with strategy and decision-making?

My theory is that brigades are the perfect complement to Code for America fellowship teams. They are talented, consistent, motivated, and local. We’d be overlooking an enormous gift if we failed to invest in team-building with our brigade partners. In what other job can you call on a volunteer corps and enlist their collective intelligence and talent to support the work?

Last Wednesday, I went to Code for San Francisco and asked its members for their help. Six or seven people gathered around to learn more about our project with the Somerville public schools: JavaScript developers, a web development student with a passion for education, and a growth marketer at a startup who’s excited about education technology.

We need good thinking about growth and marketing, because our city partners are interested in collaborating with other city governments to maintain the products we are building this year. Having Cody from Code for SF as a member of our team, with his background in growth marketing, would help us do that. We also need developers to help us handle feature requests and bug fixes. The day after Code for SF, one of the developers we met made the first external contribution to our code.

The next week, we went back to the Boston area. We went to a Code for Boston brigade hack night. We talked with a technical product manager, a marketing analyst, a developer and others about the direction of our project and how to make it stronger. It struck me that building a civic tech project is like shoveling snow out of a driveway: the more people and shovels involved, the faster the work goes.

shovels

Here is what I’ve learned so far about collaborating successfully with brigades:

  • Prepare. Start by assessing your team’s needs. Where do you need the most help? For a developer, this means going through the Issues section of your project on on GitHub and tagging strategic issues as help wanted. If you’re a designer, pick the weakest couple of wireframes to get feedback on. If you’re a planner or a writer, bring a rough draft that could use some work. Go to the hack night. This is important. It’s much easier to explain the complicated logistics of a fellowship year, the many partners involved, and your team’s current goals in person as opposed to over the web. (Fellows: remember to plan for self care. If you work all day, pitch your project at a brigade, and stay to talk with volunteers until 10pm, keep your schedule light for the next day and think about working from home in the morning.)

  • Ask for help. Asking for help is crucial. Talk about the weakest points in your project. Be honest about the things that are making you wonder and worry. You will never get help unless you ask for it, honestly and directly.

  • Find out how the brigade can help. Ask people what they are good at, and don’t assume that they need to be a coder to make a major contribution. Can a brigade member put you in touch with their neighborhood group or school or church? Help you with marketing or analysis or writing? For example, Kristen from Code for Boston edited this blog post with me. (She happens to be a professional writer and writes the Code for Boston blog.)

  • Follow-through. The work has just begun. If all goes well and you’ve matched the skill, now you have to spend time on the contribution. If it’s a pull request, review thoroughly and kindly. Taking the time to invest in someone else’s contribution has a multiplier effect.

  • These are beginning steps. The rest of the work is up to us and our brigade partners to imagine. We’ve answered a call to become members of a team. Let’s see if we can inspire others to do the same.