Improving our defaults

Last week, I was at #17NTC (the 2017 Nonprofit Technology Conference) and I’m still processing all of the things I learned or ideas that were sparked and how I might apply them in my work or in life generally. But one of the biggest takeaways for me was a question:

How can we improve our defaults?

This was sparked by a session on improving website accessibility for people with disabilities. Someone on the panel mentioned how, in the most recent version of Drupal, they had worked to improve the defaults so that some level of accessibility was built-in even if the organization using the platform didn’t specifically care about or pay attention to accessibility. Most of these things, like offline adjustments for accessibility, could benefit everyone. Otherwise, they were no detriment to the user experience for anyone else.

One of the other suggestions in the website session was that we should build accessibility into our budget and our project schedules so that crossing it out is a active choice. Similar to automatically opting people in and making it an active choice to opt out—which can be annoying for e-mail lists but beneficial for 401k participation.

The day before, I’d been in a discussion with community organizers where we were talking about venue. One mentioned that a challenge was that the space they currently had for events was not accessible for people in wheelchairs or who otherwise had trouble getting up and down stairs. They were raising money for a lift, but in the meantime, they stated upfront in each event description that the venue was not wheelchair accessible. Which sounds a bit counterintuitive, but the organizer mentioned some community members appreciated that the information was there, that they didn’t have to ask. Because they have always had to ask—many organizations hosting events, in leaving this type of information out, made an implicit assumption that people attending their event would not have disabilities.

One: Don’t make people ask.

From the start of the conference, there were efforts at inclusivity all around. When I checked in, I could pick up a pronoun ribbon to attach to my badge. In one look, people could know my name as well as that I use she/her. Other options included him/her, they/them, and there was also a write-in option. There were gender neutral bathrooms. At the opening, the CEO mentioned both of these along with the nursing mothers room, the prayer room, and other amenities that recognized we are not simply session-attending robots. In addition, recognizing that there were many first-time attendees, she explained some common lingo and abbreviations. There were “I’m shy” buttons, for those who were happy to talk to others but perhaps looking for the more outgoing attendees to make the first move. There were Birds of a Feather lunch tables and volunteer-staffed Dine Around Town reservations so, although you could certainly eat with whoever you chose, nobody had to eat alone or had to figure out how to ask a stranger to eat with them in a city they didn’t know.

None of these things are terribly difficult to do. None of these things precluded people from choosing otherwise (e.g. some chose not to use the pronoun ribbons, some chose to make their own plans for meals). But as someone who has come a long way to be able to ask a stranger if they wanted to eat lunch, about what an acronym stood for, and who still struggles with these things, and has watched others stress out about trying to find a place where they could pump or breastfeed, about whether or not they could even get into the building, let alone use a bathroom once inside—it means a lot to be seen.

Two: Inclusivity means nothing without access.

Inclusivity is not the fact that you have taken down the signs that say “No coloreds” or changed your policy from being a men-only club to one that allows female members. Sure, nobody is actively stopping women or people of color from applying to jobs in technology (or any other field). Nor is that an explicit reason people don’t get promotions or aren’t seen as leaders in spite of actions that would demonstrate leadership if only they looked like what we expect a leader to look like.

Inclusivity is meaningless without access; inclusivity is as much about removing barriers as it is about creating the space and opening the doors. As in, not only are we not restricting membership by gender, but we’re also ensuring that this space is actually accessible to all community members for the purpose we aim to serve. If people need to be able to spend a day learning at a conference, they will also need to go to the bathroom, possibly need to pump or breastfeed, may need a space to observe their religion, will need to be able to get in the building and into all of the rooms in which we are holding sessions and events. If we want people to lead at all levels within our organizations, then we need to look for those actions in all places rather than only in the places and people we’d expect.

Three: Improving accessibility + increasing inclusivity = benefits to us all

Revamping your website from looking like Times Square to being less cluttered and focused is not only easier for people using screenreaders but is a better user experience for all of your website visitors—yes. Not having to navigate stairs helps even those of us who can walk when we’re moving heavy carts of equipment or boxes of supplies—sure. Being able to use either single-person bathroom rather than having to (or feeling like you have to) wait for the one that says “Women” even while the one that says “Men” is empty—heck yeah.

But it also benefits us all because we’re getting whole people. People who aren’t spending mental energy (and actual energy, and actual hours of time) on planning out how they’re getting from point A to point B via points F and U because of stairs, or because of needing to pump every few hours or because they need to bring their own interpreter, or because there isn’t a bathroom they can use within a 15 minute walk (as exhibited in Hidden Figures), or because they need to assist their opposite-sex adult child who has special needs in using the bathroom, or because the way they observe their religion frightens some people who do not know them. When people can bring their best selves and their whole selves—why would we not choose that over people bringing only a part of their brain power, a part of their time, a part of their talent and passion and brilliance? If we’re willing to spend time and energy on recruiting/hiring/engaging the right people, why wouldn’t we make sure we could get the best of them?

Four: We will never be completely inclusive or accessible.

Another recurring theme, in the session on website accessibility, and in many others, was to let go of perfect. We may not currently have the budget to install an elevator. Or the capacity to overhaul our website.

But what can we do right now to make it better?

Maybe it’s saying, to our community members who use wheelchairs: We see you. We can’t fix it yet, but we wanted to give you a heads up that there are stairs. Maybe it’s not having a prayer before a meal but having a moment of silence for those who wish to pray, to create that space for them. Maybe it’s considering what will be readable to people who are color blind or who have issues with low-contrast when you’re choosing the colors on your website, or writing detailed descriptions for your images in your blog posts. I remember a friend of mine (who is a quadriplegic) once telling me a story about talking to bar owner about how changing the doorknobs on the bathroom door to lever door handles would make it so much easier for him to get in and out of the bathroom. To which the owner responded, “Oh, that’s it? I could do that.” At a previous organization that only had about 20 staff, they didn’t have space/need for a dedicated nursing mothers’ room, but they installed a lock on the conference room door so it could be used as such.

When we have the opportunities to do the big overhauls, that’s wonderful. But more important is that we try to improve our defaults. Like what if, instead of waiting for people to ask for a raise, we evaluated everybody’s compensation every 6 months, and within our capacity, gave everyone raises who deserved one regardless of whether they had asked? Or asked everyone about professional development they were interested in rather than just saying yes to people who asked about it? What if we simply got rid of urinals? What if the form you filled out to get your event added to the calendar or your business added to a review site asked whether or not the space was wheelchair accessible? If job websites required employers to post jobs with a salary range, rather than employers requiring it of applicants, and to post their policies around family leave rather than requiring candidates to ask? At my husband’s company, it is expected that, if the company pays for you to attend a training or a conference, you will share what you’ve learned with the rest of the team afterwards. I don’t know if that’s policy or just a cultural thing, but that make sense. Whereas I heard another attendee comment on going back to the office and their boss telling them to go back to work and stop bothering them with all of these ideas. Why waste everyone’s time leading someone on if they won’t be able to get into the restaurant, if the highest salary you can offer will not meet the minimum of what they are seeking, if you’re sending them to a training for the sake of checking a box rather than using professional development to enhance capacity, if the contribution people make to the organization have nothing to do with how you compensate them? In addition to being disrespectful and not inclusive, it is simply inefficient. It doesn’t make any sense.

We’re bleeding opportunity cost, and we’re usually not even aware of it.

I’m sure there are plenty of things I’ve not mentioned, and pitfalls with some of the things I have. I’m not perfect and plenty of my defaults could use improvement. I had the awesome opportunity to present at the conference, and I talked about flipping the switch with change-resistors: what do we risk by not doing X?

I’ve always struggled with that because quantifying output or input is easy. We spend a lot of money on education, for example, and money in and of itself is not an answer, but neither is not spending that money. What is the cost of an under-educated citizen? Of a person who ends up in prison instead of in a job? Not just the cost of running the prison or feeding inmates, but the cost of that person’s potential had they not ended up there in the first place? I’m willing to bet it is greater than the cost of providing certain services or programs. Not all of them. But probably a significant number. If someone figures out a good way to calculate that, let me know. I don’t know that the data would prove this theory, but I don’t know that it would disprove it either.

I could keep going, but I’ll end on this note:

What are our defaults? What are the inherent assumptions? How might we make our defaults better?


Introducing new technology and processes to staff/volunteers: A case study

This is adapted from a class assignment and the story told is from a several years ago (there’s an app for this now!).  However, the inherent principles still apply.  And it had been a while since I’ve posted so I thought I’d share…

We were working in the dark

Our organization had a very large event, with approximately 800-900 attendees. When attendees arrived, they would need to check in to get their materials for the event and to find out their assigned table. Since not everyone would receive the same materials, and table assignments often changed up until the last minute, making sure everyone received the right materials and was sent to the right table was challenging. The previous method was essentially a spreadsheet printed out on paper, with volunteers checking off names manually. Any updates or corrections also had to be done manually on every single copy—which is a lot of fun when you have 12 copies of a 20-page list and people are starting to line up at the door! Plus, after the event we had to compile all the lists of checked off names so that we could follow up appropriately based on whether they had actually attended or not. One year, someone didn’t realize we would need to know that information afterwards and tossed the checked off lists at the end of the night!

Then a light appeared from the front lines

In the post-event debrief, one of the volunteers suggested using Google Docs as a way to have multiple people working off the same list and to be able to make updates in real time on a single file. She had used this with her friends while planning a group trip and thought that it might also be useful for this event. It sounded great, but…

We had so many questions

  • Would we have the technological capacity and infrastructure needed? (e.g. internet, laptops, electrical outlets, Google accounts)
  • How might we need to adjust the standard physical set-up?
  • What kind of adjustments might be needed when working directly in the spreadsheet?
    • Previously, we had created the list on a large spreadsheet to track all of the information we needed but hid certain columns when printing so that volunteers would only see the information they needed. We had also printed out multiple versions of the list (e.g. alphabetical by last name, by group, groups only, presenters only) depending on how guests might present or information might be requested by staff.
  • What changes would we need to make to the check in process, from when a guest first steps up to the desk, to when they’re going off on their way?
  • Is information visually ordered/formatted to support the new process?
  • How might we need to adjust the volunteer training?
  • What would happen if someone accidentally typed over data or made a mistake during data entry?
  • What types of changes to the data would volunteers be empowered to make on their own, and what types of changes would need to go through the registration manager? (In this case, I was both the person managing registration volunteers at the event and the one who managed the data before and after the event.)

Another question, in hindsight, would be:

  • If the point was to streamline the process and make things simpler for both the data managers and volunteers, could we do this without volunteers having to learn so many new things that it negated the benefits of saving time and increasing accuracy?

This did not end up being an issue in this particular case, but in general, it is worth asking as it will be difficult to get staff or volunteers to learn a new system or implement a new process if they are taking on the costs (training time, frustration in troubleshooting, etc.) without seeing the benefits (i.e. it doesn’t save them any time or make things easier for people in their roles).

It is always important to remember why you were trying to do this in the first place and determine whether the benefits outweigh the costs (time, resources, etc.). Once you dig a little deeper, you may discover that the benefits don’t outweigh the costs for anyone. Sometimes the simplest answer is the best one.

How we answered some of those questions

  • We worked with the venue to make sure we would be set up in a space with internet connection and electrical outlets. We asked all the volunteers about access to laptops and Google accounts and made arrangements ahead of time for those who would not. And we sent everyone a calendar appointment to remind them to bring their laptops on the day of the event!
  • We decided that we would ask volunteers to use the Find function and provide training on how to use this to find the information needed among all the other data in the spreadsheet.
  • We updated the check-in process, and updated the color coding and visual formatting of the spreadsheet accordingly to call out or differentiate key information.
  • For the volunteer training, we decided to bring a couple laptops and have them go through the entire process.
  • We came up with specific guidelines about the changes volunteers could make to the spreadsheet; anything beyond those would be directed to the registration manager.
  • After testing, we felt comfortable that most of the volunteers would be able to learn the new process, especially since they’d all worked in similar programs like Excel before.

Testing, testing, 1, 2, 3

  • We built a prototype of the spreadsheet in Google Docs using the previous year’s event information.
  • We wrote up a new process.
  • We drafted some of our most seasoned volunteers (who had seen the widest range of situations) to put the new process and Google Docs spreadsheet through the wringer.
  • We adjusted the spreadsheet and the process.
  • We tested again.
  • We made the final adjustments and prepared to train the volunteers.

Training volunteers

  • After the basic event overview, we explained why we were making the change in order to answer the question of “so what?” for returning volunteers. In addition to providing more accurate and up-to-date information, we explained that the new process/system should make the process faster and easier for everyone—from staff/volunteers to guests.
  • Our graphic designer (also the volunteer assigned to event registration who suggested this in the first place) created a flow chart/decision-tree to keep it simple and help volunteers visualize the new process and how to handle different situations.
  • We walked through the new process verbally.
  • Then it was time to practice! We created a mock registration spreadsheet in Google Docs using the information from the previous year. We scripted various scenarios and had volunteers take turns role playing to get comfortable with the technology and the process, and to get a sense of the different ways a guest might present and how to handle those.
  • To make the training fun, we also took advantage of the inherent awkwardness of role playing and came up with some ridiculous scenarios involving celebrity couples and TV characters. Some people decided to show off their various accents as well…
  • Some volunteers were fine with the flow chart/decision tree and the verbal walk-through. Some practiced with extra scenarios. Volunteers needed varying levels of support during the event. One volunteer tried it out that year and then asked for a different assignment in the future. Everyone learns differently and sometimes, in spite of everyone’s best attempts, not everyone is necessarily a good fit or comfortable with the new system.

Last minute hiccups, a.k.a. The Murphy’s Law of events and anything tech-related

  • We learned that the wireless internet would be shut down during the event and would need to hardwire the internet connection for each laptop.
    • We talked to the venue to ensure this was possible. Then we asked everybody who was providing a laptop whether they had an Ethernet cable. And then we searched every cabinet in the office.
  • A few hours before the event, I discovered that the final spreadsheet file was too large to import into Google Docs.
    • After trying to reformat the file, panicking, and sheer banging my head into the same wall multiple times, I finally resorted to copying and pasting the spreadsheet in chunks (the technical term, I’m sure) of about a hundred rows at a time. It wasn’t pretty, but it worked! (Back to that point about Occam’s Razor and the simplest solution…)
  • During the event, Google Docs appeared to freeze or act up for some of the volunteers.
    • We discussed this during the post-event debrief and realized that certain browsers were not fully compatible and that, in the future, we would need to ensure that every laptop used for the event had a compatible browser.

Lessons learned, re-learned, and still being learned

  • Try as many ways as you can to “break” the technology, system, or process, in field conditions, and preferably with whoever is in the field or has that experience. There will always be something unexpected, but you can probably test out most common situations and come up with contingencies.
  • Don’t be afraid to tear it all down and start from scratch. Sometimes it can be easier (and less confusing) to build a comprehensive process incorporating all the new (and relevant existing) pieces than to try to shoehorn the old process into a new system or vice versa.
  • The best way to learn is by doing. It can be a scary moment of truth, but better that you discover any kinks during training than when rolling out a new technology or system live!
  • Frontline feedback is crucial! In this case, it brought about a change that was a significant improvement, and it was helpful in figuring out what worked or did not work the first time and making things easier for the next event.
  • The more you empower frontline staff, the easier it will be for everyone involved. There will always be some decisions that need to be made centrally or with consideration for factors beyond what frontline staff can see, but if you’re clear about the parameters, you might be surprised at the solutions people come up with on their own.
  • Sometimes the simplest solution is the best one. It can be tempting to think that just because technology can do something, that it is the best way to do something in this particular situation. For many smaller and less complex events, pen and paper is still the easiest and quickest way to handle registration.

Well, enough from me. What has worked well or not worked well for you when rolling out new technologies, systems, or processes?


Read Me, Please

One of the great things about Twitter is that, if you follow other curious people, someone is always sharing something interesting that I might not have otherwise found or have had any reason to know about, like 18F’s Open Source Style Guide.

I’m not a software developer nor do I work with open source code.  But I appreciate documentation done well, let alone when it’s done at all.  It’s fun to build new things–like figuring out a new process or procedure–and taking breaks to write down what you did and how you did it and why you did it that way can feel like a tedious chore that slows down all the fun progress.  Plus, sometimes it seems pointless because nobody ever reads it but you, and you already know all those answers.  Especially when they keep asking you the same question repeatedly after all the trouble you took to write down the answer in a shared location!  Sustainability of operations if you were to get hit by a buswin the lottery can only be so motivating for so long.

Then again, there are plenty of times, particularly with complex processes and tasks that I only need to do a couple times a year where I’ve kicked myself for not taking better notes at the time.  (Are these numbers significantly down from last year, or am I forgetting to include something that was included last year?  How did we define this again?)  Deconstruction can be fun, too, but it’s one thing when you’re looking for parts to build something else.  It’s another thing to have to reverse-engineer how you did something last year because you need to do the exact same thing again and you can’t remember how and your deadline is chasing you like Captain Hook’s crocodile.

Okay, but why start documentation during?  Why not after?  It can also feel pointless when you’re trying to document a process in the midst of creating it, and subsequently adjusting both a million times.  You took all this time to write up all the steps and definitions and one afternoon later, half of it is out of date.

The past two weeks, I’ve been plugging away at a new process and a Read Me document of sorts.  And next week, I’ll need to update that Read Me document to reflect all the adjustments I had to make while actually doing what I had imagined doing when writing that document in the first place.  Maybe nobody will ever read it but me, but it’s a starting point to which I can always refer back.  And all my annotations to the first draft will be saved in my files for when I question why something is that way.  Because I will.  And because if I don’t, then I will definitely need to know.

When I was a kid, I did all my math homework in pen.  It drove my teachers up the wall because everything I turned in was always three or four pages longer than my classmates’ assignments due to all the times I’d cross out my work and start over on a problem.  Plus, in addition to reading my handwriting, they had to read past all the scratch-outs and find the right answer.

There’s always one more edit, one new change, some circumstance we hadn’t anticipated or planned for originally.  We wait and we’ll never do it.  Besides, if you take thorough notes, including all the things you tried that didn’t work, then you won’t forget and make the same mistake twice.  Pencils are forgiving, but they won’t give you a trail out of the woods.