– Vancouver, Canada

As I write the code to add two product improvements to Out of Office Hours, I want to take a minute to document the changes and the thought behind them. Also, I’m self-isolating during the COVID-19 outbreak, and it feels pleasing to write, so I’m doing so.

First, a short recap on how Out of Office Hours works (henceforth referred to as OOOHours): OOOHours is a platform to create dialog between people aspiring to get into the technology industry “Newcomers,” and people who currently work in the industry “Volunteers.” There’s a particular focus paid to newcomers who are underrepresented in the industry or don’t have access to other mentorship opportunities. You can read more about the selection process or the origin of OOOHours.

So how does the current system work? Every month the system automatically generates a new ‘batch’ consisting of a 4:1 ratio of volunteers to newcomers. To avoid first-come-first-serve, determination of who is added in the batch is randomized. The ratio of four volunteers to one newcomer is because meeting with four newcomers a month feels like an appropriate ask of a volunteer. On the 20th of the month, an email is sent to all volunteers in the batch stating they’ve been selected. The email also asks them to make sure their information is up-to-date and their calendar open. On the 1st of the following month, all newcomers in the batch are emailed. The email explains that they’ve been selected for the batch and includes a unique link to view the volunteers they can choose to meet with.

What’s working:

  1. The 4:1 ratio of volunteers to newcomers appears appropriate.
  2. A monthly batch feels like the apt cadence.
  3. Providing volunteers a 10-day heads-up to prep their calendars before emailing newcomers.

What’s not working:

  1. Every month on the 20th, I get more than one email from a volunteer saying something along the lines of “I want to volunteer, but this month is too busy! Please take me out of this batch, but include me in future batches.”
  2. Now that we have many volunteers (> 500), newcomers are inundated with the unordered list of volunteers. The list was less than ideal when there were ~20 volunteers but utterly falls apart with the current number.

The first improvement to the system addresses point number one: “Volunteers being too busy to volunteer.” One of the product pillars, when I was building OOOHours, was to respect volunteers’ time as much as possible. They’re busy, and they’re donating their time. OOOHours should go out of its way to make it easy for volunteers to say ‘yay’ or ‘nay’ to volunteering. Implicitly requiring a volunteer to email me when they’re too busy for the month is not respectful of their time. Poorly received or unactionable emails encourage people to delete or block rather than engage with your product. Besides, the 4:1 ratio is chosen before, I email volunteers. If 50% of volunteers respond with being too busy for a month, the ratio of volunteers-to-newcomers is erroneous.

To acknowledge volunteers possibly being unavailable for a batch, and to account for an ideal volunteer-to-newcomers ratio of 4:1, volunteer induction to a batch is now opt-in. On the 20th of the month, an email is sent to all volunteers asking if they’re available. If they click ‘accept,’ they’re taken to a unique URL (without requiring authentication, again, to consider their time), asking them to update their calendar and information in OOOHours. If they don’t click ‘accept,’ they’re not added to the batch. A fast-follow to this feature will be to enable volunteers to ‘snooze’ OOOHours emails for a select duration. Now, after a ten day window for volunteers to opt-in to a batch, on the 1st, the system randomly adds four newcomers to the batch for every accepted volunteer, honoring the volunteer-to-newcomer ratio. These revisions are finished and will be deployed to OOOHours and will be applied to the next batch.

The second improvement is to address point number two: “Newcomers being inundated with a long list of volunteers to pick from.” When OOOHours first launched, there was a handful of volunteers. Choosing someone to talk to from a list of 20 is easy, choosing someone from a list of a few hundred is difficult and time-consuming. It’s also not respectful of the newcomers’ time.

My mind initially went to enabling volunteers to tag themselves: “engineer,” “designer,” “product manager,” etc. Grouping people into general tags afford filters to shorten the list. As someone apprehensive of skill-labeling themselves, being both a designer and engineer, I knew I wanted to be mindful of not forcing volunteers to conform to a single tag. Easy enough to let a volunteer associate with multiple tags. If someone tried to tag themselves as an “engineer” and a “designer,” I could easily support it. To avoid coming up with the tags myself, I ran NLP (Natural Language Processing) on what volunteers stated they felt competent to discuss. I also shared the list of tags made by the NLP script in the OOOHours Slack to collect feedback. The tags were interesting but felt very non-human. From the perspective of a newcomer, if I see a list of volunteers and 50% of them are tagged with “design,” do I gain any context if they’re appropriate to discuss my circumstances? Not at all. People are nuanced; they’re not categorizable products on Amazon.

This was when I had an ah-ha moment, which, like most ah-ah moments, is obvious in retrospect. Currently, when newcomers apply to OOOHours, they fill out a form answering what they aspire to talk to volunteers about. The answers vary from career transitions (i.e., non-tech → tech), position transitions (i.e., PM → Designer) to requesting help writing resumes, portfolio reviews to how to deal with a coworker or boss they can’t seem to cooperate with. Their answers also mention wanting to speak with volunteers who identify as a POC or in the LGBTQIA+ community. These answers are a goldmine for what newcomers getting into tech actually hope to talk to volunteers about. So, rather than allowing volunteers to tag themselves with hollow tags such as “design” or “engineering,” I’m creating a list of themes volunteers can choose from based on what newcomers aspire to speak about. Now when a newcomer views the list of volunteers, volunteers will be arranged by themes aligned with why the newcomer signed up to OOOHours in the first place. Again, obvious in retrospect, but not the original path I went down.

The code to support these broad themes isn’t written yet, nor is the UI to view volunteers by them. I’m excited to explore the UI here. Themes such as “I feel comfortable giving feedback on a design portfolio” or “I feel comfortable running a mock-technical interview” are long and will fall apart if I try to represent them as “traditional” tags. I’ll share as I work on this problem and am always open to feedback and concepts.

— Dustin