Working Groups - does your brigade have them?


Does your brigade have working groups? If so, how do they work and how useful are they? I was inspired by Code for SF’s Data Science Working Group and their User Research Working Group.


OpenOakland represent! We’ve got just one at the moment:


Code for Philly has talked about it for a while but nothing has ever formally materialized. The closest thing to it is our hosting ops team.

It would be great if there were a tried model to follow for how a brigade could formalize a working group with volunteer leadership. I feel like there’s a lot of untapped potential in using working groups to give some members express authority to take charge and drive forward within focus areas.

What’s the right amount and form of structure to empower and support working groups without making it laborious process?


We’ve been lucky at Code for SF that both working groups have had strong and consistent leadership to steward them.

To offer a counter example, we attempted to launch a resiliency working group this past year, but it never quite took off aside from the one project that came out of it (which is still on-going). I think the difference with that one is that we attempted to create the group rather than a member leader coming up with the idea.


What’s the right amount and form of structure to empower and support working groups without making it laborious process?
Yes, I’ve been trying to figure this out as well!

As a captain; I mention our groups and projects to attendees at meetings/hack nights just before we break off into groups into free-form hacking/discussion.

Currently, the ‘groups’ consist of just public transportation (PT) who are also advocates of public transportation (PT) and are involved in those advocacy groups and have their ears to the ground with it. We don’t have any PT projects at the moment because we haven’t identified any attainable projects with our current capacity (several of our more technically skilled brigaders have moved away or haven’t attended as much recently), there’s a funding crises with our PT here in Cleveland and they’ve been focused on that, and our limited tech expertise (our have left they throw around ideas of potential projects and So, they primarily keep each other abreast of new updates of the PT scene locally, and more importantly (and beneficial to the brigade) explain the local context/conditions (politics, data sources) of our PT to new attendees.


We have projects with champions but no working groups.


For sake of clarity, we should clarify the difference between Working Groups vs Project groups.

I guess Working Groups are more general. Like @tdooner mentioned OpenOakland has a CUT group that isn’t tied to a particular project.

I believe (maybe it’s just me) our brigade is thinking about whether or not we should have an events working group considering how certain events for our brigade (CityCamp, NDoCH) are annual events, and up to now we’ve just been randomly asking brigade members to volunteer. I believe this puts a lot of burden on people to step up without enough “prior warning”. Also an events working group could provide more infrastructure to have more regular events outside of hacknight and events that are more open to the general public.


@jjia25 I like the idea of an “events” working group. Maybe “Events Committee” is more accurate? Working groups I see as topical to civic tech and could result in projects, whereas an events committee is more tied to the running of the brigade. I’m inspired by @jhibbets’ description of their events group and the number of large events they hold throughout the year (from the NDoCH planning webinar).


Yeah I’m not super particular about the jargon to call one group of people vs another.

Even though OO has a Steering Committee (feel uncomfortable being called a captain at times!), I would love to brainstorm ways to hand-off a lot of the organizing work to our members and have as much horizontalism as possible with running the organization.


Another good example of a working group every brigade should have is devops – centralizing the ongoing management of deployed brigade projects so things don’t have to go offline as soon as the original person who built any given thing eventually rolls off