How You Lead a Brigade

Organizing a Brigade Governance
#1

Hi all,

I’m looking to understand better how a brigade can and should be lead. What models people have used, what worked about them, and what didn’t work about them.

Personally, I built out (kind of overkill) role documents earlier this year (http://codeforfoco.org/roles) and am realizing that they weren’t useful because I didn’t believe in them enough to use them day-to-day.

I’ve been thinking lately that I want something that is closer to a “Leadership board” which would serve a twin purpose of advising the “co-captains” and building partnerships with people in the community.

Anyway, anything you’re working on, tried, or want to try is what I want to talk about here. Thanks!

1 Like
#2

I don’t have advice, @davidbhayes, but I wanted to comment that this is something I worry about a lot too.

We made roles, but we didn’t have any accountability. If someone isn’t doing their volunteer “job” do you “fire” them? It’s confusing and hard to ask things of people because we (at Code for Nashville) aren’t really giving them anything tangible in exchange (or at least we haven’t defined / acknowledged what they’re getting).

This is just one perspective and one side of the issue, but generally, I’m looking for a model that is effective and collaborative.

2 Likes
#3

David,

After being a Captain or Co-Captain for ~5 years (!), I think that models of how leadership responsibilities are delegated and assigned in each brigade, will vary, based on the size of the brigade, number of people in leadership positions, their personality styles, their interest areas and skills, how much time they have, and even how your civic tech ecosystem/scene works locally (e.g. you may not spend as much time on recruitment if you have steady flow of newcomers).

No matter what, I’d strongly encourage you to have more than 1 person do the primary Captain/leadership tasks: onboarding/introducing people at meetings/hack nights, facilitating the overall hack nights (the structure/agenda of the meeting, taking notes at the meeting, deciding to and arranging any presentations, securing the space, etc), newsletters/social media/outreach/attending other ally organizations meetings or being the contact person for governments; that will quickly lead to burnout and/or stunt the growth of the brigade because one person can’t or shouldn’t do it all.

I’ve had some luck of:
individually asking a regular attendee before a meeting
or just aloud at the beginning of a meeting:
to complete a concrete, fixed-length task (take meeting notes tonight, take aside these 2 new attendees at this meeting and introduce Open Cleveland and civic hacking/open data to them) but some have politely declined when I asked them to the next time because often, their interest areas/motivation to be a part of Open Cleveland wasn’t strong enough or match up with their motivation to be a part of the brigade (e.g. to build their programming skills in a setting that would be positive to the public);
or more often than not, they didn’t have the time to commit on an ongoing basis.

I think mentioning the fixed-length portion is particularly effective initially because it prevents the attendee from thinking “what am i getting myself into (a long commitment?!)” and sometimes their small work creates instantly visible results (an agenda!) at the end of it.

1 Like
#4

One recommendation I’d offer is that it’s a great idea to define roles and then promote them outside your hack nights. A lot of the folks you want to recruit for leadership roles might not see showing up at hack nights to find a project to work on applicable to their skills/interests/time. For example, they might be in leadership roles at other groups/orgs and find your mission a change their ready for. Look at defined leadership roles as additional doors for entering the movement, rather than a new rung on the hack night ladder. Post a bunch at once and get some local press to write about them, send them to other community leaders, etc.

Also I’d err on the side of keeping the role descriptions short and broad, recognizing that roles will shift as soon as a real person joins a real team. Think one-sentence mission statement and a couple example activities rather than an exhaustive list of responsibilities. “Help us _____ by doing things like ___ and ___”

1 Like
#5

Thanks for all the thoughts so far :slight_smile:

I’d really love to hear from more people on this topic. Esp insights about either how you’re currently “leading,” “being led,” and how you feel that system is going.

Also I keep thinking it’s funny that Discourse lets me mark one of these answers as the “solution.” While all contributions so far are great and helpful, I don’t think my theoretical and broad-ranging question really fits the “single answer” framework that suggests :nerd_face:

2 Likes