Breakout Consulting Group (BCG)

[stevevance]

About the group

We are here to help you start or run an effective breakout group.

Describe your breakout group, how it started, what happened in the middle, what your outcome was. Then be ready to answer questions on struggles, successes, and learning how to manage with people.

Group leaders

• Claire Micklin
• Steven Vance

Who we're looking for

People who are running breakout groups, or people who want to run breakout groups.

Tools

We are using our brains.

Relevant Links

None at this time

Where we meet

We can meet wherever, or we can come to your breakout group.

[stevevance]

Meeting No. 1

Steven Cutter - "What problems (like labor and environmental) can we solve with better ride-share companies?" [email protected]

What do you want to accomplish with the breakout group?

• Starting a green ride-share company
• Drivers get equity and residual income - also a pension plan
• Eco-friendly cars

I want to make this an open source solution.

L3C, hybrid for-profit and non-profit - "for-profit social venture" - fiduciary responsibility to our mission before our shareholders.

Launch in Chicago, try to solve as many problems as we can with other cities.

Do you need help with the actual idea, or getting people to join your group?

I don't know all the problems that the city has. I want to come here and see what the biggest problems are that should be solved. Each area that we go into we can survey to find out what the biggest environmental problems are.

[stevevance]

Claire and I consulted five clients on March 7, 2017.

• Emily, Ben - wanted info on best practices in communicating with group members, efficient onboarding
• Jack - wanted advice on how to structure/pitch their breakout group (How much does Chicago have invested into Dakota Access Pipeline #94)
• Matthew - wondering how to start a breakout group, wondering if their idea is appropriate for CHN
• Reynard - wanted advice on how to deal with someone who comes and tries to change the group's work method - how do you ask this person to stop, and be part of the team rather than control how the team is working? how do you establish norms and group etiquette?

Efficient onboarding

The problem is that sometimes you spend a lot of time introducing new people to the Breakout Group topic and history, and these people don't return. Thus, it seemed like you wasted your time. It definitely wasn't a waste of the new person's time because they need to know whether the group is something they want to return to.

One method I've used is that after a couple of meetings you understand what info people are looking about your BG and you can document this on a GitHub repository wiki.

After they've read it...

• Ask the new people to read it over and propose to you, the BG leader, their idea for contributing.
• Get them to ask you how you want them to contribute (what do you need done).

What do people usually want to know about a Breakout Group they're considering joining?

The document (a README, per se) could describe:

• who's in the group
• who is the group's focus/target
• who the group's leaders are, or who the group's managers are
• what are the goals of the group
• how the group communicates (online, phone, only in person)
• what data and information the group is consuming
• what research the group has done
• what tools/methods/tech the group is using
• what tools/methods/tech the group wants to use, or wants advice on using
• which experts and impacted population has the group contacted

[vingkan]

I consulted BCG last week for my breakout group, Fantasy Civics #82 because I was having a hard time getting people to join my sessions. Fantasy Civics is an online game that encourages players to learn about Chicago wards and aldermen in a format similar to Fantasy Football. My main takeaways from the BCG session are:

• Need to revise my breakout pitch to address two concerns: (1) many ChiHackNight attendees aren't familiar with how Fantasy Football is played and (2) it is not clear what kind of people should come to the breakout group.
• The most important area for growth for this project is to improve the website and game copy. We need help to write short explanations of how to play the game and integrate it into the game process so that users learn the rules naturally.
• Invite ChiHackNight participants to come play the game, some people think the group is only for people who are building the game, but what we really want are small groups of people who can play the game, help spot bugs, and give feedback.

I highly recommend BCG, their capacity for sticky note innovation is unmatched.

[derekeder]

I was going through my email and came across this great writeup from @jpvelez in Oct 2012:

Launching an app

1. You need data, and people who can code.

Getting data has probably been covered elsewhere.

• My approach to getting tech folks involved has been to have a weekly open gov hack night + massive networking in the local tech community combined with personal outreach to people. Having a weekly space is great because it becomes a hub - people know they can always show up, people meet, ideas bubble up, projects emerge, non-technical civic-minded types from local gov + nonprofits + foundation start to take note.

• Helps to always have the hack night at the same place to reduce overhead. Also, good to keep things technical and work-focused. Too many non-coders and too much chatting and you lose the momentum of getting things done. Eventually, fewer people show up. The point is not to exclude non-coders. You need to be welcoming to interested people, and integrate them. But it's important to get the right ratio of technical to non-technical. Also, the point is not to prevent talking. People show up for other people, after all. And if you have no ice breakers, no connections form. One thing that's working for us is doing introductions and then getting to work.

• Keep things informal. It's really hard to herd the cats with volunteering, especially at first. Instead of trying to organize teams around project from the get go, I figured it would be easier simply to provide a place to work. At our hack night, it's totally cool for people to just work on personal projects. Most people do. But teams have also formed organically around projects. I've explicitly avoided micromanaging these or trying too hard to push them along. Better to be supportive and keep things light. If volunteer hacking starts to feel like work, people will stop doing it. (Maybe this puts a limit on the size / ambition of projects that are possible. Open City is a pretty tight-knit group, so we've been able to pull off some biggish projects. But you shouldn't expect the brigade as whole to just pump out big projects. The people who are interested in that and who will work well together will find each other over time.)

• That said, it's not a bad idea to keep a list of projects people are working on. But the basic theme is avoid biting off more than you can chew, and avoid excessive process. Keep things leans and just start working - you'll figure out what process / tools you need along the way. Less talking, more doing. Don't fret over organizational before there's stuff to organize.

• Lastly, it's a good idea to attract talent. Get a handful of really good coders / designers to show up and not only will the quality of projects be higher, but they will attract other people for you, and raise the quality level of everyone who shows up.

2. You need a need. This is vastly more important and more difficult than data or coding talent. The bulk of civic apps arise out of "hey wouldn't it be cool if we did x" and not "person y has a problem, how can we fix it?"

There's nothing wrong with making apps based on the possibilities of data and not the pinpoints of a problem. Many of the apps Open City has made fit that description. But to have impact, you need adoption. To have adoption, you need
to 1. actually address a real problem, 2. design for that problem (the app isn't always going to be the first napkin sketch, and the solution isn't always an app).

To have adoption (user acquisition and retention,) you also need marketing. Civic hackers usually don't have the energy of interest to do this, and that's why the bulk of civic apps don't reach their audience.

In Chicago, we're trying to hack the adoption problem by getting city folks in the room. That leads me to the next bit:

Organizing around an app

1. It's super important to meet people in government and nonprofits. Make friends, get them to talk shop. The more you understand about the systems, pressures, and incentives they face, the better you can spot problems to work on. Also, the better can navigate their politics, which is important for implementation.

This isn't as hard as it sounds. Civic tech is sexy; sell it. (It helps to have a couple of local civic apps you can point to.) One of the organizers, preferably a charismatic people-person should be in charge of outreach to gov/nonprofits/foundations. This really just means having lunch / coffee with humans.

Once you identify a workable (read: small) problem or idea, invite them to pitch it to the hack night. My theory - this is still just a theory that I'm trying to validate - it's that it's easier to get volunteers interested in a project - and keep them motivated - if they're offered the opportunity of working with the City itself, and of solving an actual problem.

2. Keep it simple, stupid. Once you've got a real person with a need, start with a simple, lightweight project. (If it actually meets the need, redeploying an app might fit the bill.)

Use tech that isn't a pain in the ass the set up. We use Google Fusion tables a lot because you don't have to deal with the hassles of setting up fancier database, and because it integrates directly with Google maps. We've also built a map template on top of it, which has itself become a useful, reusable building block for lots of projects. As a result, we can pump out interactive maps in mere days. Steal it.

3. Get your partners to market the app for you. Trying to get a press for your app is always a good way to get eyeballs. It's worked for Open City. But it's not really enough.

If you're working with a community organization, get them to tell their members / community people / other nonprofits about the app.
If you're working with the city get them to use their PR/twitter machine. Better, get them to link to your app from their website. Best, get your app on the city's domain. That's where the eyeballs are, for many apps anyway. People at the city will be super risk adverse if you pitch this. I don't have many lessons to share here, because I'm working through this right now:

4. Case study: working with the city. To illustrate, we're currently working to get this flu shot clinic map on the City of Chicago's website. Nothing has been inked so please keep this on the DL. Chicago's Dept. of Public Health does free flu shots every year. We invited them to a hack night to pitch ideas, they asked for a map of the flu shot clinics. Tom Kompare, one of our members, took the initiative and JFDI.

However, I didn't want this to be yet another app that only civic nerds get excited about and nobody else sees - especially since there are ads all over Chicago's buses right now that say "GET A FLU SHOT www.cityofchicago.org/flu"

If you go to that url right now, instead of having a user-friendly tool that tells you how to GET A FLU SHOT, you have a wall of text.

So I get a meeting with the Commissioner of Public Health the following week. This was only possible because I already knew him (note the importance of relationships.) I showed him what we had built in response to his pitch, suggested we put it on the city's website to take advantage of their marketing push, and he was all about it.

I knew there would be a number of issues to resolve to make this work - app (co-)branding, hosting, who owns the code, who controls the code, legal boilerplate from the city making it clear they didn't build the app / weren't liable, etc.

So I made a list of all these issues, and we got someone from the Mayor's office to come to the meeting too. This guy is great and knows lots of people throughout government. So during the meeting we went through every issue and either resolved it or figure out how to resolve it and assigned that task to somebody in the room. And we set an (aspirational) launch deadline. All of the subsequent work has been done in an immense email thread. Hopefully the app will launch in the next couple of weeks.

No doubt we could be using a better process for all this, but I figured the best way to figure out a good, replicable process for these types of collaborations was to just starting doing it.

Here are some lessons thus far:

• It really helped to have a very simple app.
• You need a Department head (or someone from the Mayor's office, depending on the project) to sign off on this, and tell his people what their roles are. It was super helpful to have a Commissioner who is really interested in how his Department can use tech.
• You need a project manager, preferably not the developers. I've been acting as a go-between Tom, the developer, and the folks we're working with at the city to get data for the map, figure out how we're going to integrate it, and figure out legal issues. Things will take way longer than you want, so it's super important to have someone who is going to keep everyone in the loop, call people, and generally prod things along. By the way - email sucks, pick up the phone.
• You probably need a written statement of work, a kickoff meeting, and a project manager inside the city, though keep in mind that the more you complicate things the harder it is to get stuff done, esp. with volunteers.
• Do things fast. You do something simple so it actually get done, but also so you can turn it around quickly. Quick wins are incredibly important. Do a couple of these collaborations successfully, and it'll be much easier to do more.

[derekeder]

@stevevance @matiaskitty do you have any plans to do anything with this reasearch? a summary/write-up would be awesome and very useful for folks

[matiaskitty]

This are my much belated notes/insights on BCG's session with @vingkan

1. It helps to have a clear, succinct goal for the an app. Once you have that, pitching the app becomes easier. You are also answering part of the "Why should I join this breakout group?" question.
2. Define what engagement means with your particular app - in Fantasy Civics' case, do you want people to play a certain number of games? check out the aldermen's stats? Why do you want them to do this?
3. Decide what story you're telling. Apps (games included!) with stories are more shareable and memorable. Story elements in Fantasy Civics could include giving aldermen specific characteristics, or adding bio information or providing some explanation for why an aldermen "won".
4. Add in educational components to help tie the process of interacting with the game together. Since your goal is to educate people about their aldermen, add some educational elements to sneak in some learning while people are having fun playing your game. You'll have to decide what you want people to know about aldermen.
5. You could use these Game Usability Heuristics to evaluate the playability your game. The heuristics are on page 1511.

[stevevance]

Recap after meeting with Jamie.

Jamie is new to hack night. He wants to highlight the vacant storefronts in his neighborhood and learn from his neighbors what kinds of businesses they would like to see. Jamie had an idea or two on how to use technology to do this.

Starting a new group

• Newcomers should gain some longevity in the group (this can be a couple visits but you have to stick around for the breakout groups) to meet a couple of people.
• Join and observe some breakout groups.
• While you're doing that, perfect your pitch by yourself, with your partner, a colleague, really anyone at this point.
• Figure out how you might want to structure (do you want to lead a group, co-lead a group, and what kinds of professions or contributors do you want).
• Prepare an agenda on how your first meeting should go (introduce yourself, ask people about their experiences with this problem, and have some guided questions that you don't know the answer to).
• You will probably not have a successful group (that creates something you want to share in the end) if you dictate terms and don't accept contributions and ideas.

For those who are unsure what the group's outcome should be, start a breakout groups about an idea, instead of an app or website. Invite people to help you design the outcome together.