Well Met: Upping Your Facilitation Game

Originally posted to the Truss blog

We talk a fair amount on this blog about how to have better meetings. And we should! Taking the time for some meetings will save time over all… but it’s a delicate matter and one of great responsibility. But let’s say you feel like you get it. You’re the person charged with meetings going well, and you know which agile ceremonies are worth having regularly, how to determine other things worth discussing synchronously, and how to create and stick to an agenda. But you get it, and you’re hungry for more. This post should help you get here by:

  • offering structure by which to share skills and…
  • suggesting when to deviate from (or go without) an agenda.

By including better facilitation practices in more aspects of your work, group dynamics will improve overall and everyone can focus on the actual work at hand.

Skill Shares

The more team members in a room know how to facilitate, the easier the conversation can be. Two ways to increase capacity in your organization are by mentorship and encouraging behavior which allows a group to facilitate itself.

We already talked a bit about how to mentor other facilitators in Well Met: The Facilitator, but it merits a deeper dive. To mentor other facilitators, first look for the helpers. Ask folks who see others raising their hands, help get a conversation on track, etc to review agendas with you. If they’re interested in trying out facilitation, backchannel while they or you facilitate, and debrief afterwards.

To get a group to be better at facilitating itself, ask folks to cue the person who comes after them in stack. Then, encourage people to self-regulate for time and how many points they make (one of the “Rules of 1”). Finally, work to get folks to cede the floor to someone who has spoken less than they have, often by prompting a quieter person with a question.

At Truss, we ran a quick 2-question survey to pair those interested in facilitating with those who already feel comfortable doing so. We stagger by skill level, so everyone has a chance to be in both a supporting and lead role.

internal facilitation survey screenshot.png

We are Very Serious People.

When to deviate from the agenda

In Well Met: The Meeting Itself, we talked about how to create an agenda and then facilitate from that arena. This is an important and useful thing to do for a good long while, if not indefinitely. However, if you find yourself thinking “oh, I know what would totally work better instead!” and you’ve built trust with the group, it’s time to deviate.

My agendas, while well planned, often get tossed out within 5 minutes of any meeting starting. It’s similar to agile practices in that way – the preceding research and planning gives a solid sense of what problems are being solved and awareness of the context; but flexibility to adapt (or throw out) a plan based on what is most needed in the moment of action to achieve those goals. Because you’ll have facilitated many different sessions at this point, and tried out a lot of different facilitation practices, your toolbox and skill will be substantial enough to try something that seems more appropriate in the moment than your plan.

Taking a self-assured, but mildly cavalier approach to this is one successful approach to getting group buy-in for these deviations. “Well, I thought we were going to do X, but now that’s not going to help us get where we need to be, so we’re going to do Y instead. Any concerns about that?” while making eye contact to assess before moving on works well. Also sometimes “Wow Past Me has some terrible ideas. We clearly don’t need this entire next section in order to achieve our goal. Let’s skip it and save some time, shall we?” This needs to always be coupled with a reminder of what the goal of the meeting is, to keep all conversations on track.

Sometimes, if sufficient trust has not been built up, people will take this opportunity to discuss how the discussion will happen. Time box this and move on when the time box is done.

Other times, in groups with a particularly high level of trust, I won’t even share my agenda, which gives me leeway to adapt without making excuses. That said, I will have absolutely made at least one agenda in advance.

Where we’re going we don’t need agendas

And then sometimes there’s so much confusion about a topic that the meeting itself is to resolve the confusion. In which case it’s highly unlikely you get to have a traditional agenda. If this is the case, have a solid sense of who needs to be there and how the conversation might start. You might discover other folks are needed partway through, or that someone could be using their time better elsewhere. Apply the “law of two feet” here and let folks leave if they’re not needed.

As your comfort in facilitation grows alongside your activity toolbox, your ability to adapt in the moment will likely increase. To gain the benefits of that increased skill, allow yourself more flexibility while building out a stronger overall capacity in your organization. By

  • offering structure by which to share skills and
  • suggesting when to deviate from an agenda,

group dynamics will improve overall and everyone can focus on the actual work at hand.

Well Met: The Facilitator

Originally posted to the Truss blog

We’ve all been in dead-end meetings. No matter how dedicated and efficient your team is, a few bad meetings can derail their productivity and, even worse, their morale. In the next post of our series on maximizing the value of meetings, we talk about one of the aspects of a good meeting: the facilitator.

Practice the techniques highlighted in this series to:

  • increase the effectiveness of meetings;
  • decrease the number and duration of meetings;
  • build team cohesion;
  • cross-pollinate information across teams; and
  • do so in a way which leads to new insights otherwise left buried.

You’ve learned how to determine whether you need a meeting and how to prepare for and drive those meetings, now we highlight how we select for that facilitator.

Who does this?

It’s a lot to take on. Plotting a course for effective meetings means setting aside time to discern if a meeting is actually needed, preparing for it, and assigning a dedicated person to facilitate the meeting. An important thing to note is that facilitators will participate differently in in a meeting. Experienced facilitators have a responsibility to not add their editorial opinions, and beginners may have a hard time facilitating while also joining a conversation.
 

Project managers as facilitators

In Waterfall, big plans are defined, then staff are tasked with executing a predetermined set of requirements. Project managers are responsible for tracking if individuals or departments are meeting deadlines such that the entire Gantt Chart stays on track.

In lower-case-a-agile, we see the project manager as facilitator rather than task tracker. The project manager should be primarily focused on creating uninterrupted time for the team, while also keeping an eye out for when sharing information would make that working time even more effective. This means the project manager should already have an eye out for meetings that would benefit the team and guard against those that won’t (our first post in this series). The project manager should have their finger on the pulse of what folks are up to so much of the work for agenda prep is already done (our second post in this series). Because agile team members are entrusted with finding the best route to solving a given problem, the project manager’s goal is to open and maintain the space for meaningful conversations, which points to the facilitation aspect of useful meetings (also the second post).

In short, at Truss we are structured to put project managers in the best position to uphold the responsibilities put forth in this series. But it’s not just on them.

Increasing facilitation capacity in your org

Facilitation is a core component of being a servant leader. But just as with any attempt at organizational change, it’s difficult for a project manager to come in and implement all this. A nurturing environment cultivated by the leaders of the organization means facilitation as a skill can build up throughout the organization. For this reason, when a project manager is unavailable, we tend to lean toward someone with experience in facilitation, and who doesn’t have a personal stake in the meeting itself. This could be an engineering lead, design lead, product manager, business lead, or founder. They often have additional authority and responsibility to a client.

Project managers can’t (and shouldn’t) be in every meeting. Whether there are multiple meetings happening at once or it just doesn’t make sense for the project manager to attend, other folks in the organization should also be upping their own facilitation game through facilitation mentoring. Project managers can support this by guiding a mentee through the agenda-building process, backchanneling about facilitation practices, flagging issues during meetings where a mentee and facilitator are both present, and debriefing afterward about questions or concerns.

Why would I want to be a facilitator?

To do so helps everyone make equitable space for others, amplifying the voices that might otherwise go unheard and the fountain of good ideas which accompanies that.

It also makes meetings go that much more smoothly, as the team is thinking about how to be effective and inclusive while maintaining focus on the objective. Learning to watch for signals and respecting stack can be distributed across the group, which helps everyone manage themselves.

Read more about deciding when to have a meeting and how to prepare for and drive an effective meeting to have the full impact this series offers.

Why are we doing all this?

Bad meetings, like bad policies and negative environments, are tractable problems. By following the techniques highlighted here around determining when to have meetings, how to prepare for them, and how to facilitate, your meetings can be worth the context switching they require.

Good facilitation allows you to have fewer meetings, and the ones you do have will:

  • be more impactful,
  • be more effective,
  • build team cohesion,
  • and lead to new insights otherwise left buried.

You can help make it happen!

Well Met: The Meeting Itself

Originally posted on the Truss blog

Everyone has been in a meeting that made them wonder, “What am I doing here?” While a meeting can be a productive way to drive a project forward, many meetings are the opposite—they disrupt productivity and waste valuable time. All it takes to ensure that a necessary meeting doesn’t go off the rails is a little bit of planning and someone to facilitate the process.

The first part in this series covered the hows and whys of determining that a meeting is necessary. Once you know you need one, it’s important to make the best use of everyone’s time. This requires some preparation in advance, and active attention to keeping the meeting on track.

Create an Agenda

Building an agenda is the most important, difficult, and fungible part of meeting facilitation. Here are the steps to developing a solid agenda:

  • What concrete outcome do you need to get out of the meeting? You should be able to say this in one sentence. It should be the name of the meeting, and be included in any correspondence related to the meeting.
  • Create a plan. Consider where the group is now (point A), and where they want to end up (point B). You likely need to talk to other people in order to figure this out.
  • Identify your requirements and blockers. What would need to happen to get from point A to point B?
  • What is your strategy for tackling these challenges? Pick activities that will help achieve the concrete outcome needed to get from point A to B. Search the internet for “facilitation activities” for some suggestions. A few of our favorites are:
    • Spectrograms to explore just how divisive various issues are.
    • Vizthink to externalize systems in people’s heads in a way that allows progress to be made.
    • Breakout groups to allow more people to be heard about a topic.
  • Who are the leaders who can push this project forward? To push power outward, you’ll ideally work with a different person to lead each part. This isn’t The [Facilitator’s Name Here] Show

Time management is the hardest thing to get right at first. Here are some ways to effectively manage meeting time:

  • Pad for time.
    • People will show up late. Decide how long you’re willing to wait (keep in mind waiting wastes everyone else’s time and sets a bad precedent) and stick to it. People will show up on time more often if they know you start on time and meetings are valuable experiences.
    • A/V will break. Showing up early to troubleshoot can save others time, but you can’t fix the remote setup.
    • Folks will want to dig into questions that matter, and having some extra time allows this to happen.
  • Remember to have time to open and close. Rituals matter!

If you are new to facilitation, your agenda is your guide. The signposts you set in advance will help you remember how to get where you’re going when matters inevitably become complicated. As you become more experienced and gain trust, the agenda becomes more of a thinking exercise so you can adapt in the moment.
 

Facilitating

You’ve done all the work, you’re ready to try out your well-crafted agenda, and people are on the call or at the table (hopefully on time). What do you do now?

  • Set expectations around communication. Two suggestions we have found the most useful are:
    • Demonstrate respect for each other (and the clock) at all times.
    • Follow the Rules of 1:
      • Make 1 point and pass it on. This distributes the conversational load across more people, which means more people get heard from.
      • 1 diva, 1 mic. Only one person should be speaking at a time, which prevents people speaking over each other, difficulty hearing for those dialing in, and gives equal attention to all speakers.
      • Have 1 empty chair at the table/1 available slot for call-in. This makes it welcoming (and non-disruptive) for that latecomer (or someone from a different breakout session) to join you.
      • Speak 1/Nth of the time. If you’re quiet, know people want to hear from you. If you’re gregarious, dial it back a bit to make room for others.
    • Once you’re comfortable with those, consider adding in hand signals (Zoom and Maestro also offer approximations). These can save time by getting a “temperature check” on how the team is responding to a current thread without needing to hear from individuals one-by-one.
    • Aspiration, an organization focused on building technical capacity for nonprofits has some pretty great participant guidelines that are useful to adapt to your own circumstances.
  • Take “stack.” People signal to the facilitator or the stack keeper when they’d like to speak up in a discussion. The facilitator might call on people in the order they signaled, or they might change the order to have more equal speaking time based on the stack and to account for folks who have spoken less.
  • Stop a speaker from going on too long. (You’ve already made this OK to do if they make more than one point or if they speak more than 1/Nth of the time.) You can do this through body language, hand signals, and directly speaking to the person.
  • If people get into eddies of conversation (this often happens with two people going back-and-forth, rather than the group being engaged), push for a choice to be made, or if that can’t happen, clarity to be reached. This will encourage the discussion to move forward to a place where ideas can be tested by coming in contact with reality. If people truly need more time, offer to schedule a meeting specific to that topic (with a concrete outcome) so people can return to the subject at hand.

Who should be responsible for all this work? In the final part of this series, Well Met: The Facilitator, we’ll talk about what makes a good facilitator and how to choose the right person for the job.

Well Met: Ceremonies and Beyond

Originally posted on the Truss blog

We’ve all been in bad meetings. And no matter how great your crew is, bad meetings waste time and can degrade the culture you’ve worked hard to build. We’ve talked before about which meetings are worth having, now it’s time to dive into how to get the most out of those meetings. Doing so will:

  • increase the effectiveness of meetings;
  • decrease the number and duration of meetings;
  • build team cohesion;
  • cross-pollinate information across teams; and
  • do so in a way which leads to new insights otherwise left buried.

To reap these benefits, utilize the guiding principles in this three-part series for useful meetings: determining whether you need a meeting, building an agenda and facilitating, and choosing the right facilitator to ensure everything runs smoothly.  In this first part, we’ll (re)cover some of the ways to be sure the meeting you want to hold is worthwhile.

Any scheduled event is potentially disruptive to a colleague’s flow. Meetings can be a waste of time and, even in the best case scenario, often require context switching. It’s important to make sure you actually need someone to do something synchronously with you, rather than calling a meeting for something that be fit into their own flow asynchronously in a more optimal way.


When it makes sense to have a meeting

The following circumstances are worthy of a meeting:

  1. When something can’t be decided on asynchronously – A chat (like Slack) just isn’t working. Something is being lost in tone or the information being gathered and the team would benefit from more mediums of communication (visual, verbal, physical) happening all at once.
  2. When something has been decided, but there needs to be a group status update to move on to other things – Sometimes, everyone knows the status of a project, but they don’t know that everyone else is on the same page. This can lead to concerns about leaving someone behind and cause a slow the velocity of the project. A recap meeting that ensures that everyone is aware of what decisions are set allows the team to collectively move on to the next phase.
  3. Distributed self-coordination – Instead of reading documentation, sometimes it’s more efficient to have a rapid-iteration conversation about where to go to next, together. This example is similar to scenario #1 with a splash of #2.
  4. To build team cohesion – Asynchronous communication with occasional one-on-ones just doesn’t keep the whole team together. Sometimes the team needs to get together to learn from each other, and to realize just how in alignment they already are. This scenario is mostly #2 with a splash of #1.


When you shouldn’t have a meeting

Some “meetings” do more to waste time than to move a project forward, leading to a lot of frustrated team members. Here are some signs you’re not having a meaningful meeting:

  1. You’re reading together – There are some folks who just don’t read materials they are sent. Whether they don’t have the time, the material is irrelevant, or they don’t like reading doesn’t matter. What matters is that someone has just disrupted another person’s flow to insist they come and read this thing right now, in a “meeting.”
  2. You’re listening to one person speak – If you want to give a presentation, own it! But a presentation can be ingested just as easily via a video or audio recording as it can in person. Again, don’t disrupt people’s flows.
  3. You’re hearing people talking about things they already know – This isn’t a meeting, it’s a panel discussion. The same principles apply as listening to one person speak. If you’re not up to adapting to your audience or working with them to get somewhere new, just record it. The knowledge is still useful, but the disruption of other people’s flows is not.

On the other hand, question and answer sessions after reading, presenting, or paneling do make sense to do interactively, so it’s worth it to call a meeting after the above non-meetings to share ideas.


Useful gatherings that are not meetings

There are times when it makes sense to meet with someone or a group that don’t fit the parameters above. They include:

  • Conversations – These are great, but trying to facilitate them with the meeting-level rigor suggested in this series will not make you popular amongst your peers.
  • Celebrations – While some programming is useful, celebrations are organic things that don’t need any more structure than they already have.
  • Skill shares – Vital to upping skills and building relationships, these also should be a bit more organic than what is described in this post.

Some of the same principles will apply, but these gatherings are not what this series focuses on.


Why are we doing all this?

Bad meetings, like bad policies and negative environments, are tractable problems. By following the techniques highlighted here around determining when to have meetings, your meetings can be worth the context switching they require by being impactful and more effective, building team cohesion, and leading to new insights that would otherwise be left buried.

OK, let’s say you definitely need this meeting. The next step is to be sure those meetings matter through agenda building and facilitation. Discover how to utilize these strategies in part two of our series, Well Met: The Meeting Itself.

How Could This Have Been Prevented? The Art of the Pre-Mortem

Originally posted on the Truss blog

In the world of disaster response, teams engage in something called a “hot wash” after each deployment. If something went wrong, we ask ourselves: How could this have been prevented? It’s a question that helps us mitigate crises rather than simply respond to them. Sometimes, if a responder is about to do something particularly ill-advised, say in a social context, another responder will ask them, “How could this accident have been prevented?” as they walk towards potential harm or embarrassment.

As someone who has done crisis response for the past eight years, the pre-mortem we held on my third day at Truss made me feel right at home. It was the last day of an intensive kickoff event for our DOD project (more about how we won that here). Our engineering architect Nick Twyman led the assembled team in a session to brainstorm issues which might be severe enough to tank the project. He opened with the prompt, “Imagine you’re presenting to the entire company 12 months from now and must explain why this project completely failed.”

Engaging in this practice:

  • Surfaces potential issues before they become problematic.
  • Prevents team members from suffering in silence or needlessly worrying.
  • Replaces reaction with strategy.

We’ve already benefited immensely from this practice. For instance, we learned to identify and engage early with stakeholders who otherwise might have been invisible until too late. This has allowed us to pay attention to serious concerns while also staying focused on the emerging roadmap for the project.

Where did this idea come from?

Our CTO, Mark Ferlatte, learned about the practice from Daniel Kahneman’s book Thinking Fast and Slow. He noted that it “felt incredibly weird the first time you do it.” The book covers different modes of thinking and responding to what feels immediate versus the strategic, tricks to help you move from reacting to planning, as well as how to be self-aware when in difficult conversations.

We’ve developed our own flow for pre-mortems, and have benefited in various ways.  In one instance, the team indicated that they were feeling unsure about being able to track things properly. This feedback resulted in an ad hoc training session on our task tracking tool with positive results.

How do I do it?

You, too, can avoid delays, derailments, and failures by following this process. Whether you refer to it as “forecasting” or “generalized anxiety,” there are a few simple steps.

First, think about when it makes sense to have a pre-mortem. We do ours at the end of a project kickoff (when folks have the project fresh in their minds but haven’t yet started building habits and opinions about how things “should” be). You can also run more than one for any given project. It’s particularly helpful to do during sprint planning sessions or prior to irrevocable commitments (before we sign the contract, before we begin execution on the contract, before we go live with the product).

Don’t lead the session by asking a broad question like: How might this go wrong?  Instead, be very specific. We used the prompt mentioned above, emphasizing two important factors. “Imagine you’re presenting to the entire company 12 months from now and must explain why this project completely failed.” These two aspects helped people move beyond generalized anxiety and into thinking strategically about what they are unlikely to be able to adapt to themselves. In a larger group, give everyone sticky notes and about five minutes to write down their thoughts, then group their ideas into categories while reading them out loud. In a smaller group, take a minute or so to think about it, and then go around in a circle to hear what folks came up with.

Some of the concerns raised might not surprise you. Ideally, you’re already mitigating risk around the topics some people bring up. Sometimes, though, someone will say something new or extremely obvious and scary (for example: “None of us have ever published a book” when the project is to write a book). Mark treats these concerns very seriously and attempts to mitigate them as quickly as possible (for example: hire an agent to help us navigate book publishing).

We found that those obvious and scary observations were more likely to come from junior rather than senior employees. Senior people often overlooked obvious risks because they had “always managed before.” Junior team members were justifiably concerned when they felt like the project was missing key factors, but they wouldn’t speak up if their concerns were dismissed. Yet another reason to be sure your environment is open and safe for employees to voice their concerns.

Good luck out there!

Pre-mortems are a tool to start thinking about the future and to do so strategically rather than reactively. This helps teams avoid pitfalls and focus their work. Pre-mortems are easy to hold and can happen at multiple points during a project’s lifespan.

May all of your difficulties be novel, and good luck out there!

Theorizing the Web abstract

Discourse on hackathons tends to emphasize projects and project creators rather than the events as a social practice within existing communities. Hackathons have a history as a community building method for education and creation. More recently, institutions have used hackathons to invite conversation and design with groups affected by those institutions. This step towards broader participation is obfuscated by stories that focus on the creation of products and the lucky geniuses whose work is appropriated by institutions. Critiques of hackathons often accept the same assumptions, focusing on high profile events, critiquing the small number of sustained projects, and questioning hackathons as a form of entrepreneurial free labor.

We argue that hackathons are a community practice which is poorly expressed by this focus on project outcomes. Based on our historical research and interviews with hackathon organizers, we show evidence for ongoing contributions to community objectives as a core value to many events. Hackathons have been a community practice for decades in open source groups, hackerspaces, and companies. People participate to learn, signal their belonging to the group, and at times to make something new. Many communities hold regular hackathons as one component of their larger initiatives.

As hackathons have become more popular, governments and companies without a history of engaging with people outside their organization have been using them to listen to critiques and to support people and ideas that they formerly lacked the capacity to hear. Hackathons are offering a new channel through which marginalized groups can remix, critique, and relate directly to people within those institutions. However, project-oriented narratives about hackathons motivate institutions towards easy, shallow, visible innovation from people who already know the institution. The visible project and its creators, rather than communities or process, are the goal of these hackathons, which reinforce the status quo. Repeatedly failing to meet expectations can inoculate institutions and participants alike from further engagement. Project oriented narratives also limit hackathon’s ability to share community values with new groups, encouraging and rewarding individualism rather than the more historically-common practices towards education and expanding sustainable projects.

In this talk, we illustrate what’s missed by project-oriented narratives via interviews with hackathon organizers and a series of case studies. We will also offer examples of alternative discourse that highlights community practices, learning outcomes, and critical discourse that occurs within hackathons.

How do I Create a Challenge Brief?

Originally created by the amazing Lindsay Oliver over on the Geeks Without Bounds blog, and reposted with permission here.

Why create a challenge brief?

Useful challenge briefs are the key to producing robust solutions for a hackathons. They do this by limiting, not expanding, the parameters of solutions to challenges. It’s easy for participants to overextend themselves on solutions that try to address too many components of a problem at once. By creating challenge briefs that break the problem up into parsable, bite-sized chunks that can be tackled in the time span of an event, participants are able to create more viable results when they focus on one component or feature.

Remember that hackathon challenges aren’t necessarily software development challenges. Most Geeks Without Bounds and Random Hacks of Kindness affiliated hackathons allow the opportunity to work on challenges around software, hardware, and open data. Many are also open to citizen science projects, educational resource creation, and the development of other commons resources. Be sure to explain in your brief what sorts of resources you would like to see in response to your challenge.

What are the key pieces of effective challenge briefs?

  • Background
  • Challenge Statement
  • Scenarios (optional)
  • Components
  • Resources

Background

Provide your participants with contextualizing information on the problem, the requesting organization, etc. This will help lay the groundwork for them to determine what solutions might be valuable in this use case, and how those solutions might need to be tweaked for the benefit of the end user.

Sample:

Kiva is a microfinancing platform with the goal of bringing an end to poverty through giving. They focus on individual empowerment to create opportunities, ensuring that marginalized populations are the ones in charge of their own development, prosperity, and independence.

Challenge Statement

This is the heart of your brief. The challenge statement boils down the problem(s) that are being presented to participants. Be sure to state the need and explain why solving this issue is necessary. Indicate how a solution to this challenge would impact the stakeholders, and provide any needed caveats for special cases of use.

Sample:

Kiva needs a better way to understand its own donor data and extract meaningful/actionable information from it, provide avenues for external partners and wealth managers to interpret and share impacts of this data, and use this information to further drive engagement of donors both individual and donor-advised. Any tool created for this challenge will need to take into consideration the internal and external potential uses for this tool, and implement reasonable flexibility to address these end users.

Scenarios (optional)

This is an optional component for your challenge brief that is dependent upon any special cases of use that the solution will be addressing. For the example provided below, the end user of this tool may be outside of the organizational structure that created it. This information helps participants craft solutions that provide flexibility for implementation of the tool.

Sample:

Many of Kiva’s donors come from a pool of donor-advised funds via institutions like Morgan Stanley. These wealth managers provide reports to their managed investors on how their money is being used, what the return rate of those investments are, and what the impact of those investments are for the recipients. Wealth managers need the ability to track these funds at a variety of levels (geographic area, type of loan, amount, theme, etc) and provide this information to their investors. This will enable donors to provide feedback, see the actual positive human outcomes generated by their investments, and direct their wealth managers toward targeted groups in need.

Components

This is where you break up the challenge into parsable chunks for teams to choose from. Stress to your teams that this is not a checklist of items to complete, but a starting place for ideas. Only one portion of the possible solutions should be addressed by individual teams, NOT the entire list.

Sample:

1. Refined Loan Information Processing
-Accessing information on donated/invested funds more easily
-Calibrated for intaking both individual donors and larger firms
-Both for external firms and internal Kiva usage
2. Funds Tracking
-Tracking of funds both individual and donor-advised to provide a holistic overview of where, how, and why funds are spent
-The ability to import funds data from sources outside of Kiva
3. Impact Visualization
-A flexible, adaptable, and editable visualizations generator
-Framed for use both internal and external

Resources

Give your participants shiny new toys to play with. Platforms, APIs, datasets (with PII, personally identifiable information, SCRUBBED), media, use case studies, etc, should be made available to teams. Don’t overdo it, though, as too much information may bog the teams down and prevent out of the box problem-solving.

Sample:

  • Developer Site, Kiva API, and Sample Data
  • Datasets: Incorporated into provisioned hackathon NetSuite accounts
  • Kiva Media and Image Gallery

Good luck, and happy hacking!

Should I Offer a Prize at My Hackathon?

Consider: what do you want the prize to do for the event, and for the attendees, and for your cause?

Your humble author usually steers clear of cash and large prizes because of the people it brings around, and how they influence the crowd. Do you want to prioritize large attendance / an opportunity for undergrads to be exposed to this topic? Or do you want to prioritize sharing stories and collaborating on potential solutions with no strings attached? Any of these priorities (or others) are totally fine, but decide what you’re going for, and pick how to handle prizes based on that.

Building Capacity

At things like StartUp Weekend, prizes help teams move their project forward – time with a lawyer, some startup cash, access to expensive dev tools, etc. At GWOB events, we usually give prizes which are coding books, comics, and hardware kits; all to get people thinking in new spaces. Another set of prizes might be qualifying to work towards a bounty of DELIVERING a working prototype (or some other milestone) by X months after the hackathon. Or just use prize money towards that, and use the hackathon as a time to onboard people to the ideas. (I think I would even wait to tell people about the bounty until the hackathon itself).

Attracting Attendees

Prizes sure can be great for attracting attendees. For people with many options in front of them for how to spend their time, prizes can incentivize attendance. This can also mean attendees might view the prize as compensation for their time – a strange mental space to be in, especially if not a winner. Prizes can also incentivize people to focus and to push themselves out of friendly (or unfriendly) competitiveness.

Other Considerations

Smallish prizes as indications of appreciation are awesome. Definitely need to be able to be divvied up across a team (no ONE LAPTOP PRIZE – how can 4 people deal with that?). Too big/prestigious, and people don’t collaborate or share what they’re up to (being protective of people “stealing” their good ideas).

Hackathon Consent Form

Purpose and general description of the study

Study on the history, use, and troubles of the hackathon, or codefest, model of engagement. The goal is to end up with a clearer understanding of the tension between the formal sector taking on the idea of “hackathon” while actively combatting the context of “hacking.” More appropriate methodologies for organizers, facilitators, and participants would be published and workshopped back into the community of hackathons and the people who make them happen.

This study is conducted by Willow Brugh, a research affiliate at Center for Civic Media at MIT’s Media Lab, with Ethan Zuckerman as Principal Investigator. You, along with 3-10 other individuals, are requested to participate in the study due to your connection and history with the groups which exemplify the topic. These groups were chosen based on a wide ranging view of hackathons and engagement roles.

The research is anticipated to include a one-hour interview with participants and followup questions via email. Summaries will be sent to participants for feedback and approval before being posted to a public website. Research is currently slated to end in December 2013.

Participation

Your participation in this research is completely voluntary.  You can withdraw from the study at any time without penalty or loss of the benefits to which you are otherwise entitled. You do not have to answer any questions that you do not want to answer.

Data Collection

Data will be collected via interviews via Jitsi, G+, Skype, Phone, Jabber, or some other conversational platform of the interviewee’s choice, or possible in-person interaction. Dependent upon the consent of the interviewee, data will be logged mentally, textually, and/or audibly. All data will be released to the interviewee within 2 weeks, and later to the public if single-instance consent is expressed after review.

Topics

During the interviews, expression of beliefs around hackathons, their purpose, and methodologies will be examined. Questions will revolve around history, best practices, success stories, and future expectations.

Identifiers

Due to the co-creative nature of this research, participants will determine if they would like to be identified or not. Each node of analysis of interviews will be released to the interviewee for approval and clarification, and at that time the interviewee will be asked if they would like the node to be anonymized or credited. If any subset of interviewees desires anonymity, Willow Brugh will consult with the participants to determine if all groups must be anonymized to protect the indicating party, or if a mix-and-match is possible.

Confidentiality

Confidentiality in this study is determined by the participants. After agreeing to take part in the study, each interviewee will indicate what level of confidentiality they prefer:

  1. Anonymity to the best of the researcher’s ability.
  2. Association with group, but individual anonymity.
  3. Identified by name and group affiliation.

Based upon how all interviewees respond, Willow Brugh will work with the participants to determine if mix-and-match is plausible, or if all respondants must be identified or anonymous. If in question, anonymity will be defaulted to. Any quotes or exact attributions will rely upon a per-instance specific consent.

All data will be retained on a hard drive encrypted via TrueCrypt (http://www.truecrypt.org) and stored with Willow Brugh and an encrypted backup drive stored in a locked cabinet at MIT’s Media Lab. All interviews and email exchanges will take place via OTR, PGP mail,  Jitsi, or Red Phone. Any documentation will be offered to the interviewee and transmitted via encrypted channels (as listed above), but it is their perogative to store in a secure fashion if desired. Assistance in setting up encryption methods is provided upon request.

If anonymity is desired, any audio will be destroyed after analysis of the interview is responded to and approved by the interviewee. The name of the interviewee will at no point be stored in plaintext, and will be erased from stored data after encoding occurs.

If explicit consent is given on a per-instance basis, audio and transcript (when available) will be published to the web in an open format.

Risks, Costs, and Benefits

Risks of Participating in the Research

There are no known risks for participating in this research, other than the violation of confidentiality if confidentiality is desired. I have indicated above/below the steps I am taking to preserve your confidentiality.

Benefits to the Subject or Others, or Body of Knowledge

In understanding and making explicit the benefits and difficulties of the hackathon space, these communities can become more self-aware and thereby more effective in achieving their goals.

Compensation

No compensation is provided to participants.

Questions about the research and rights of research participants

If you have any questions about this study at any time, please feel free to contact either me, Willow Brugh, at 812.219.4056 or bl00@media.mit.edu, or Ethan Zuckerman, director of Center for Civic Media at ethanz@gmail.com. We will do everything possible to prevent or reduce your discomfort and risk to you, but it is not possible to predict everything that might occur.  If you experience unexpected discomfort or think something unusual or problematic is occurring, please contact any of the people listed above.

Signature Block

By filling in your name, you indicate your desire to participate in this study.

Please indicate your preferences for overall anonymity (you can change this at any point for future publication, but existing research updates will either have been credited directly to you or stripped of all information). Each node will pass through you for feedback and approval before being published.

  1. Anonymity to the best of the researcher’s ability.
  2. Association with group, but individual anonymity.
  3. Identified by name and group affiliation.

Theorizing the Web Talk

Nate and Willow’s talk at Theorizing the Web 2014 on Hackathons are More than Hacks starts at 50:12

  1. Set up the mismatch between media and practice (3 mins max
    1. Introduce ourselves
      1. Willow
      2. Nathan
    2. N: If you’ve read about hackathons in the press, you’ve probably seen
      1. clever young hackers winning prizes for making tech
      2. rather than a community of all ages learning together
    3. W: show a quote by an organiser
    4. W: and a quote from a participant
    5. N: In this presentation, we share some early results from research on hackathons. We’re seeing a mismatch between media narratives and the stories participants themselves tell, a mismatch that is colouring critiques of hackathons.
    6. (describe our methods and context) (45 seconds) (brief)
      1. w: what is a hackathon, based on our experience and our interviews
      2. w: we interviewed around 15 participants, organizers, and facilitators.
      3. n: we analysed around 640 articles and blog posts about hackathons
      4. w: we’re involved
  2. W: In my interviews: Hackathons at the intersection of community building and engagement with institutions (who are the players, and what are their goals) (2 min)
    1. What hackathons we’ve looked and been involved in
      1. (slide) with a big list of logos and what years are covered with us and the people we’ve talked to
      2. (zoom) Communities (slide with lots of examples) (open source, disaster response, entreprenuers)
      3. (zoom) Organisations (slide with lots of examples) (businesses, governments, non profits)
    2. Who attends (front end, back end, subject matter experts, students) or just (do this for THEIR LIVING, professionals who want to volunteer their tech skills on a weekend, folk who want to learn more about a subject, folk who are passionate about a subject but don’t know how to engage)
  3. W: What actually happens at and after hackathons (3 mins) include a bunch of quotes
    1. People learn about new disciplines and challenges
    2. People find a way their skills can change the environment they’re in
    3. People find others with shared interests
    4. What happens with projects & initiatives
  4. N: How hackathons get portrayed (2 mins)
    1. Slide of what media we analyzed, including list of sources, MediaCloud mention, and histograms for Hackathon and Civic Hacking (640 articles)
    2. Simple revolutionary solutions
    3. Civic Hacking (80 articles & blog posts)
      1. equal measure PR
      2. project documentation
      3. critiques of the idea
    4. Superstars & Startups
    5. last point: mismatch between media narratives and interview results
  5. Major critiques of hackathons – coming from theorists, critics, and funders
    1. slide that points to hackathon critique articles & minisites (don’t try to respond)
      1. example: MELISSA GREGG & CARL DISALVO “The Trouble with White Hats” (New Enquiry) (http://thenewinquiry.com/essays/the-trouble-with-white-hats/)
      2. example: National Day of Hacking Assumptions & Entitlement (http://nationaldayofhacking.info/) voices from people in those communities. Disconnect causing animosity.
      3. Morozov “Making It” New Yorker: http://www.newyorker.com/arts/critics/atlarge/2014/01/13/140113crat_atlarge_morozov?currentPage=all
      4. David Sasaki (Omidyar, now Gates Foundation): On Hackathons & Solutionism http://davidsasaki.name/2012/12/on-hackathons-and-solutionism/
    2. List Critiques (willow)
      1. Produces incomplete & short-lived projects (prototyping) – addressed when about the community rather than about the media.
      2. Free labor for companies & gov’t
      3. Doesn’t create fundamental change
      4. Props up existing structures, making them more efficient
      5. Inauthentic citizenship as alternative to meaningful change
      6. Only addresses technically actionable solutions
      7. It’s impossible for tech to support meaningful structural change
      8. False Empowerment: Solutionism in a weekend
      9. Distraction: People feel good about shiny ideas that never have impact
      10. Emphasizes superstars rather than communities
      11. Entrenches exclusion by favoring people with technical skills
    3. Nathan: What ties these critiques together is an emphasis on media portrayals and less a focus on actual community practices we’re seeing
      1. Media doesn’t emphasize learning
      2. Media doesn’t emphasize community building
      3. Media supports an overly simplistic solutionist narrative
      4. Media prefers a one hero story about shallow revolution
      5. Media attention focused around the hackathon event, with limited follow-up: if projects proceed beyond prototype, we don’t hear about on going effort
      6. All of these things can obscure what really happens
  6. W: Based on what we’ve found: Responsibility for hackathons, media, and researchers, for a method that’s still growing and evolving (3 minutes)
    1. W: Impart a sense of what these become as what we make of them. By their very nature, they are malleable. People with skin in the game need to be engaged with responsibly.
    2. W: Solid as a working method – especially cross-culturally (closing technological gaps as well as socioeconomic / access gaps)
    3. W: So you’re organizing a hackathon – think about how you’re portraying it to all parties, and make sure to amplify communities and practices, not just projects
    4. M: So you’re reporting on a hackathon – reporting on projects is lazy – look deeper into the community practices, learning, and engagement with institutions
    5. M: So you’re researching hacker culture – find a stance that acknowledges and respects the voices, experiences, and work of the communities whose outcomes and potential will be directly affected by the arguments you make from a position of power and privilege. Go beyond critique and simple media criticism for a deeper engagement with communities and practices
    6. W: Use & contribute to hackathonFAQ.com