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

2017 in Review

This will be my third year in a row doing these, so you can also read about 2015 and 2016 if so desired. They are inspired by Tilde, who has taught me that it can be a Good Thing to remember what one has accomplished over the year. The headers in this post are based on my 2017 goals.

Explore, decide upon, and execute the next work bits.

This was the hardest on me. While my time at Aspiration helped me to slow down, it also removed me from the circles in which I had run, which I feel made finding work far more difficult than it might have otherwise been. Over the course of 2017, I applied to ~200 jobs, and got to the second-interview stage (or further) at 12.

Contracts did come in, some through the consultancy Vulpine Blue my brother and I started. We had 4 clients and a workshop series, including participation in a field scan for technology for social justice (complete next year) and a network strategy workshop around microfinance and direct cash assistance. External to Vulpine, I facilitated a lovely group of folk in creating a game about disaster response, and am working with Megan Yip on a resource repository about digital estate planning. Some of these things have been covered on this blog over the past year.

I applied to a data science bootcamp, and so took time to learn more about Python, statistics, Javascript, and d3. While I didn’t get in based on my lack of memory/knowledge of statistics and calculus, I did learn a lot, especially about coding. The most significant progress in all this has been made under the excellent guidance of Tilde. <3

The work on digital response has also continued, with assisting Greece Communitere in setting up their Monitoring and Evaluation for Accountability and Learning plan, participating in Neighborhood Empowerment Network and Volunteer Organizations Active in Disaster Sacramento, apparently having 35 Marines tasked to me for setting up the disaster response section of Fleet Week, and helping with community technical responses during the hurricane season. The influx of attention has improved our response knowledge base and sparked a new Slack group. A donation came in from a friend for these efforts, which means we can be even a bit more prepared in the future to do more work. For a short period of time, I had a Patreon going, and it was a reassurance that I’m not shouting into the void. Some of these efforts also appears on this blog.

For longer term thinking, I also supported the swissnex Crisis Code event, found a co-author and new editor for the mixed-mode system paper book (which progresses a goal for 2016), and set up the Do No Digital Harm Initiative with Seamus and Joe.

In short, I did manage to explore the next work bits. The route I’ve been selected for, and accepted, is to become the project manager at Truss. Truss embodies my desire to do epic shit quietly, in a healthy working environment. I’m stimulated and supported, and it’s glorious. Also, we’re hiring.

I don’t know how *you* celebrate being a new job, but I sure have a way..

A post shared by Willow Brugh (@willowbl00) on

Make a longer-term financial plan (and start on it).

All that means I have a long-term financial plan and am plugging away at those longer-term objectives. 2017 was a year of sporadic income and job hunting, and has drained all personal savings and put me back in debt to family (I am the luckiest, I know). Being paid like an adult living in SF while still persuading myself that I don’t make that kind of money means I can start saving for bigger Future things.

Remain emotionally vulnerable and available even when it suuuuucks.

After taking some time to heal after the multi-level collapse of 2016, I developed a Dating Plan, which perhaps isn’t terribly surprising to some of you. I executed at full-bore and thereby met lots of lovely new folk.

But the dating Plan didn’t go exactly as expected because the casual thing I had going with one Reed Kennedy escalated. Quickly. We worked backwards from when we should decide if we want to do other Life Things with each other, and set a move-in date in August. Be still my logic-based heart. We now share a home (but not a room), and his mom knows my parents.

A post shared by Willow Brugh (@willowbl00) on


This isn’t the only relationship in my life, of course. I’ve also worked to maintain my relationships with Jenbot, Lily, and Estee; and to deepen my friendships with friends old and new. A big part of being able to do all this was getting my average miles per hour into the single digits for the first time in years. 7! Seven mere miles per hour. That’s 61k miles traveled over the year.

There are other aspects to being emotionally vulnerable and available. To me, showing up was also participating in the airport protests, women’s march, and acting as security at a Berkeley march. Another aspect of vulnerability is this: over the course of 2017 I experienced two bouts of depression, the second of which was bad enough to mean I’m on medication. A++ modern medicine, would ask for help again.

Find 3+ adventures of any size to go on, and go on them.

I went a little overboard on this one, but I’m really proud of myself for that. In the past, most of my travel has been for work, with rare exceptions. In 2017, I went snowboarding in Colorado, went to Santa Fe to see Meow Wolf, rode to Pinnacles to go rock climbing, hiked Gunsight Pass with my dad in Glacier, and had romantic getaways with two partners (one to Point Reyes, the other to Virginia)!

Where I was yesterday.

A post shared by Willow Brugh (@willowbl00) on

I also managed to Do Things in the Bay Area, including taking a shining to the SF Neo Futurists, playing D&D for a long weekend in Oakland, experiencing an interactive play set during the Prohibition, and seeing Hamilton and the Magnetic Fields.

Adventures aren’t just for experiencing, they’re also for building. Over 2017, I gave a talk at Odd Salon, did some minor support on Radiance, sat on a panel about Apocalyptic Civics at the Personal Democracy Forum, gave a talk on Weaponized Social at SHA (the Dutch hacker camp), contributed to a Cultivate the Karass event, and sat on a panel about disaster response technology at Hackers. Oh, and I ended up in a coordinating leadership role for the 1100-person, 4-day festival Priceless, which I shall continue doing next year as well.

Yours truly, on the last day of #priceless, with “enough” radios.

A post shared by Willow Brugh (@willowbl00) on

Get back into reading a nerdy amount.

I did ok at this, but not as well as I might’ve liked. Instapaper doesn’t offer data, but apparently I’ve finished 18 books this year on Audible, and maybe 3 physical books (yay dyslexia!). Favorites include Thanks For The Feedback, Marriage (a History), the Broken Earth series, The Gone Away World, and The Fire Next Time. I also binged hard on The Adventure Zone podcast.

Physical Things

Here were the physical goals for 2017:

  • Run 400 miles over the course of 2017 (about twice what I did this year).
  • Beat my time/position for a Spartan race.
  • Climb at least 6 times a month.
  • Bike 50 miles or more a month.

Maybe there are so many because they’re the easiest thing to track?

I ran 307 miles (100 more than 2016, but 100 less than my goal), primarily because bicycling became more of a priority than running. I bicycled 1,163 miles over 2017, which is pretty great for the first year of having my own bicycle as an adult. The hardest (but not longest) ride I did was 31.8 miles and 2,554 ft of climbing. I walked 100 miles less than last year, but 500 miles more than I bicycled in 2017.

Hours and hours spent with @sofauxboho for this Goldie-Locks-fit of a bike.

A post shared by Willow Brugh (@willowbl00) on


The Spartan race I ran was during the same month and same location as 2016’s, but the track was slightly different. I ran a better time (1:40 to last year’s was 2:05) but poorer position (583/4800 to last year’s 255/2617). I don’t know that I’ll do another race. It’s been interesting but I don’t see it building to anything.

The only month I missed my 6x climbing goal was November, and November was a tire fire. I got Reed into climbing, who got Josh and Gordon into it, and I made new lead-practice climbing friends Sophia and Alejandro. I made it up a Mission Cliffs .11C (not Yosemite grading, so not as fancy as you think it is, but still damn hard).

I persisted with yoga and strength training, took up boxing (this also knocks out (lulz) a goal for 2016) (shout out to Four Elements Fitness, and to Scout and Debbie for the encouragement), and started on a ketogentic diet which has had huge benefits to my mood stability. And I’ve halved my alcohol consumption from last year, which was already a drastic decrease. My average workouts per month is up to 15 from 5 last year. This is especially strange, looking back to 2015 when working out regularly was notable. Lest this seem easy or accessible, it’s the equivalent of spending just over 7 straight days in the gym (not including walking or biking), almost 4 days of which was just on walls.

Not-Goal-Related Joy in 2017

Got my motorcycle painted so it is now the right colors.

Personal things : still improving.

A post shared by Willow Brugh (@willowbl00) on


Bought myself very nice slippers. I mean, really nice. I’m wearing them right now.

Now drink only decaf coffee and teas unless under extreme circumstance.

I also learned 3 songs on the ukulele. This was a huge deal to me, as I’ve always been convinced I couldn’t play an instrument. Now, having played those three songs, I don’t know how much more time I’ll spend on it, but it was fun to figure out. Thanks to Katie and Drew for badgering me into believing in myself.

2018

The term I carried with me into 2017 was personal ambition, as I wanted to start considering my own needs while caring about the world. While I don’t think my personal ambition came anywhere close to the ambitions I have for the world, this goal did shape how I thought about things.

The term I will carry with me in 2018 is space for foundations, as I continue to re-learn how to take up space, in light of the things I’ve learned about humility and ambition over the past couple years. So my goals are:

  • Do solidly (excel, even!) at my job
  • Get certified for lead climbing
  • Continue reducing my intoxicant consumption
  • Meet one of my four savings-related goals. I still feel awkward about money so I won’t go into more detail here.
  • Get the book proposal in front of 4 publishers
  • Go bicycle camping
  • Bicycle further than I walk (without any drastic reduction in walking)
  • Complete the coding project with Tilde for the year-end report next year
  • Responsibly wrap up some of the projects listed here
  • Keep on top of my responsibilities during Priceless and other high-tumult times
  • Feel like I’m speaking 1/Nth of the time

Rights Based and Needs Based Response

The humanitarian aid groups I work with are “needs based.”

The advocacy groups I work with are “rights based.”

These are useful frames which mean different things, and while a person can operate with both of them in mind, it is not possible for an organization to operate under both pretexts. Let me explain.

Rights Based

Rights based groups include the United Nations, Amnesty International, the ACLU, HURIDOCS, Islamic Human Rights Commission, and International Work Group for Indigenous Affairs. Find more listed on Wikipedia.1

The UN was born out of the aftermath of WWII. One of the things the UN immediately2 did was to adopt the Universal Declaration of Human Rights in 1948. These include both freedoms from and freedoms to, such as the right to “rest and leisure,” “life, liberty and security of person,” and “no one shall be subjected to arbitrary arrest, detention or exile.”3 Sounds dreamy.

From the UN Populations Fund on why the UN decided to go with a rights based, rather than a needs based approach:

an unfulfilled need leads to dissatisfaction, while a right that is not respected leads to a violation. Redress or reparation can be legally and legitimately claimed.

The rights based approach states a baseline expectation of how humans should be treated. However, if a government, group, or individual is violating that baseline, public opinion are used against the perpetrator to change behavior. While countries may base some of their laws on the UDHR, the international courts use them as customary law, rather than anything more rigid.

But what about in unusual circumstances, such as conflict? Rights based organizations do not care about the unusual circumstance–rights are rights–and so rights based groups are rarely “allowed” access to conflict zones, although they may go regardless.

Needs Based

In war, the Geneva Conventions apply, which

are international treaties that contain the most important rules limiting the barbarity of war. They protect people who do not take part in the fighting (civilians, medics, aid workers) and those who can no longer fight (wounded, sick and shipwrecked troops, prisoners of war).

These are also enforced through a special international court called the International Criminal Court.

While there is a neat and tidy list of rights based organizations on Wikipedia, there is instead a category of humanitarian aid organizations. The only organizations founded on the Geneva conventions are the International Committee of the Red Cross and International Federation of Red Cross and Red Crescent Societies which operate under the full set of humanitarian pricinples, including neutrality.4

Neutrality is the hard one which is often forgone by groups which call themselves “humanitarian”5 because of how difficult it is to maintain. It means laying aside a personal sense of justice (related to rights) in order to provide for human needs. It means fixing up the wounds of a militia with the assumption that the wounds of the civilians and the “other side” will also be fixed up.

This means needs based groups are allowed access to regions which rights based groups are not. But if that neutrality is ever called into question it is hugely detrimental to all people in conflict zones everywhere. A needs based organization can never act as if it is rights based.

Making Choices

It is from this background that I asked a question of Twitter about a project I’ve been working on called Do No Digital Harm.

Should the people who help secure an ICT6 network in use by groups in conflict align/organize themselves with/like a group like Amnesty, or a group like the Red Cross? The first allows for a much broader conversation and pushing of an agenda. The latter allows access to places otherwise inaccessible.

As always, one of the key groups I continue having a massive crush on is Médecins Sans Frontières (Doctors Without Borders). Even in their founding is the combining of a rights and needs based approach, and though comprised of many fiercely rights based individuals, the organization itself remains needs based and trusted to be neutral in conflicts of all severities.

I’ve talked before (with the amazing Margaret Killjoy) about how humanitarianism needs to be politicized. But that political action can happen by other groups to those which are needs based, in different arenas. We must be strategic in meeting needs while also increasing access to rights in the future.

Footnotes

  1. Bless you, Wikipedia. Have you donated to them, or called your rep about Net Neutrality? If not, please do so now.
  2. well, for them… it took 3 years
  3. If you’d like to feel inspired and crushed all in one go, visit the UN Human Rights Office of the High Commissioner website to see what they’re up to.
  4. Yes, IFRC and ICRC are different, I’m so sorry.
  5. Also sometimes Proselytism because people gonna people.
  6. information communication technology

The Contributions of Grassroots Technical Communities

The Haitian Earthquake saw the first significant uptick in responding entities. Gisli Olafsson brought this up the first time we’d met, at a talk of his at the Wilson Center. I was just starting to visually take notes (having broken my arm), and I was a year into leading a group called Geeks Without Bounds, one of the many technical response groups which had emerged and then stuck around. It was hard to know what we would be good at, where we fit in. Disaster response has such a long and complicated history, and the culture of technology is so used to being new, shiny, and the Fixer of All Things.

Seven years later, and the patterns of digital response are becoming so well ingrained in my soul that I can use the Socratic method to help new groups as they spin up without becoming frustrated, and insist on things like self care. There’s still a lot to learn – especially as our physical and digital environments are changing all the time – but here is what I have figured out about where digital/technical/whatever response fits into the larger response ecosystem: crowdsourcing (and microtasking), increasing everyday capacity, information communication technology, and easing collaboration through standards.

Because each of those is a hefty thing to speak about, this entry covers crowdsourcing and microtasking.

What’s the difference between crowdsourcing and microtasking?

Crowdsourcing is about gathering data, microtasking is about parsing through data. Both are predicated on a very large task being broken down into many tiny pieces, which can can then be done by relatively unskilled/untrained labor. Then all those individual contributions need to be able to re-combine into a logical Whole again without too much overhead. Because of the need for a very clear workflow, the problem-solving creativity of in this process exists in the creation of the workflow, the systems on which it runs, and the creation of the experience for the individual participant.

What follows is an example of an emerging crowdsourced practice and one with a smoother flow and two examples about microtasking. A later entry will cover how citizen science exists in the overlap between crowdsourcing and microtasking,

Crowdsourcing

Rescue Requests and Dispatch

The way I’m used to seeing rescue requests happen is through an overloaded emergency response system asking people to stay in their homes and wait it out. It’s never sat well with me, but I’ve been at a loss as to how, as a remote responder, assist. During Harvey, the Coast Guard activated the Digital Humanitarian Network to help go through rescue requests on social media to provide them with summaries every 12 hours which they could then respond to. 12 hours is a long time to wait, even if it’s a quick cycle for the formal sector. Locals started using Zello to request and offer help via the Cajun Navy. (Let’s return to a rant on redundancy in dispatched resources based on a lack of sharing another time, yes?) Rescue.fm has since started working on ways to coordinate dispatch beyond scribbling on pieces of paper and spreadsheets. Good work, Zello, Cajun Navy, and Rescue.fm! I’m excited to see how this evolves over time, and to see such clear improvements to systems for mutual aid.

Shelter Information

During Harvey response (and then again for Irma), Sketch City set up a workflow for volunteers to call shelters to ask for their capacity, available beds, location, etc. That information was then entered into a data structure which could be queried via SMS through code built by the HarveyAPI team.

Eventually, something like a data standard for health and human services could automate much of this process. But until and unless that happens, this sort of information doesn’t become available to people under stress unless folk are chipping in to make those phone calls and enter the data. Good work, Sketch City!

Microtasking

Mapping Infrastructure

The remote mapping of regions (whether in crisis or not) is something that Humanitarian OpenStreetMap Team has been doing as a core component of digital response since before their mapping of Port-au-Prince in less time than it would have taken to set up a contract through a response agency. Their Tasker is a beacon of how anyone can get involved in helping a response (or “Putting the World’s Vulnerable People on the Map“). Those maps are then used by responders and locals to allocate resources, find useful paths across treacherous ground, or focus restoration efforts. This most recent round of hurricane response was no different, and for that we thank you.

Translation

People should be able to ask for, and offer, help in whatever language they are most comfortable in. Areas affected by extreme environmental events will always be home to multilingual populations, whether or not they are visible. The incoming and outgoing information is often so varied as to mean blanket translations won’t work. Thankfully, Meedan stepped in with their Bridge tool and community to create a workflow around translating individual messages, announcements of services, and some documentation of products. Without them, we would have been even more colonial than usual (another rant for another time).

Closing

In short, there are many people in the world who want to help, and many who need help. Often, they’re one and the same. Our role as remote responders and system-builders is to help them find each other and to interact with fewer things in the way. A good first step for many people wanting to help is to have a quick, easy way to contribute – often through crowdsourcing or microtasking. A next step to plug in for more complex and longer-term efforts is ethically desirable as well.

If we work together to build an ecosystem around different ways for people to contribute and request, we strengthen our social fabric and become more resilient.

With thanks to supporters on Patreon, who made it WAY less stressful to take the time to write all this down, and to Greg, Jeff, and others who reviewed the post.

What is a Digital Asset?

This blog post is a part of an ongoing series for Networked Mortality. If you’re new to the series but not to the blog, here is a primer post about the approach I’m taking. We’ve already covered using password managers for estate planning. Here, we get into what a “digital asset” even is.1

Do you own your Flickr photos? What about the ones you have on Instagram? Can you pass them on to someone when you die? Should you be able to pass on the license of Photoshop you purchased? Access to your Instagram account? I think you should be able to, but right now companies and the law disagree (in very unclear ways).

How do we define a digital asset?

We define digital assets as: content, files, resources, or accounts that you have created, purchased, or primarily store in a digital format.

Some digital assets you OWN, some you LICENSE (access/accounts/software). Digital assets you own you can bequeath or pass on to others. Those you license may not be transferrable.2

But how did we get here? Does it match with what other frameworks (legal and otherwise) define digital assets as?

What is an “asset”?

Continue reading