Measure of Music | How-To Guide Part 2: Assigning Teams

Measure of Music was a three-day music & data conference & workshop/hackathon with 1000+ viewers, participants & contributors. The entire event was done for less than $250, took less than 3 months to plan, ran on Zoom, and was live-streamed to YouTube Live for spectators. Read more about it on measureofmusic.com.

I don’t consider a big milestone in my life done until I recap it, so to close out the first Measure of Music, I’m writing a series of how to/reflective guide of the weekend starting with the logistics and costs. I wanted to do this blog post about teams early because it was, by far, the toughest part of the planning process.

The survey feedback I’ve gotten so far expressed frustration with the team structure (not enough technical people), a wish to pick teams beforehand, and a desire to have teams all announced at once.

Here’s why none of that was possible…

Over 280 people signed up to participate in the project, yet; in the end, only 68 people actually presented, which means only 24% of people that signed up actually participated for the entire weekend.

On the weekend of the event we had about 110 people signed up to participate, so about 40 people canceled day of, canceled during the weekend, or just didn’t show up/stopped showing up.

This is why the teams ended up the way they did. I did my best to put people into groups based on timezones and skills but it just wasn’t always possible to evenly distribute people. I actually created 22 groups based on the people that were signed up just one week before the event started. I took into account, timezones, skills, and the preferences of those that asked to and to not be paired with people. In the end, only 1 of the teams I created just one week before actually had all 5 members in it. So, all group creation had to be done as people arrived.

Suggested Solutions

Looking at the surveys, some suggestions included charging for the event so people feel more invested, having more professionals in data/tech sign up as participants, assigning mentors explicitly to teams to supplement for lack of tech skills.

Charging Money

Unfortunately, I don’t feel comfortable charging recent grads and job seekers for an event like this especially because even what feels like a nominal fee in one country could feel like a lot of money to someone in another country. As the event is meant to be inclusive to all, it’s not something I’m likely going to implement.

Mentors as Participants Instead

Having more mentors as participants instead is interesting but while the mentors were there to help, they also weren’t committing their entire weekend to the event.

The average amount of time a mentor spent online was about 4.5 hours for the duration of the weekend.

As the participants know, it takes a lot of commitment to spend your whole weekend on something like this, and to those that also do it for a living, spending their entire weekend doing it may not be as enticing (though there are some amazing exceptions to that in many of the teams). We did offer up participating to all those involved, even after the waitlist had closed, so the option was there.

Dedicating Mentors to Specific Teams

I did consider assigning mentors to specific teams when we first started but a few issues here. The teams couldn’t be assigned until people showed up and the same would hold true for mentors. Mentors also were online at various times throughout the event, so what if they weren’t online at a time you needed them? Also, not every mentor was a technical mentor, so really I may have needed to assign multiple mentors per team. The issues go on but there’s something here to explore more, just haven’t quite figured it out yet…

Best: Because groups were determined by timezone, people worked with people across different countries with different cultures and backgrounds.
Worst: Took a huge amount of time to create, recreate and then redistribute people throughout the weekend. This is why the team numbers are from 1–17 but actually only 14 teams presented.

Possible Solutions for Next Time:
• Open up the conference portion of the event first and delay the project sign up until 4 weeks before the event to reduce turnover.
• Potentially cap the number of non-technical sign ups to ensure there’s a more even distribution of skills.
• Create a matching algorithm to quickly match people on the day of the event.

That’s it for now & certainly open to other suggestions.

Thanks for reading & look out for more of these coming soon.

Thanks,
Christine