Hackathons: Always Be Learning
On team-building with mentors and participants
By Link Clark, Program Manager, Coding4TX
Youth hackathons are opportunities for learning at each phase and level of participation, if they’re done well. The 2017 SPARK! Hackathon at St. Anne’s-Belfield School (STAB) was done well, and I am fortunate to have been invited as a mentor on behalf of Mozilla and Hive Austin. I was able to join and act as a mentor, but most importantly I was able to learn from the participants and fellow mentors on how to build a better hackathon. Here are two takeaways for me.
Mentor Jam
A Mentor Jam the day before the hackathon was an excellent way to convene and share skills we utilize in our professions and for the hackathon. A mentor jam is a chance for skill sharing among mentors and, just as important, a way to know more about one another so we could support the hackathon participants as a team.
It was a great first step in establishing an important ethic of successful hacks: diversity and teamwork. We each had a valuable skill and perspective to bring for one another and the participants.Thanks to Mentor Jam we entered the next day as a team that could push participants to embrace the Mozilla problem statement. We invited participants to:
design resilient, human-centered networks that reflected their interests and values and created trust between members.
The post-hack survey supports the idea of the Mentor Jam being an important way for us to prepare. Based on the feedback from the participants, the Mentor Jam certainly worked in preparing us to help participants, as one attendee reported in the post-event survey:
“I would like to thank all of the mentors from Mozilla for their help and advice in the Hackathon. This team made the experience even better!”. Two of our mentors were thanked specifically, Robert and Brenda, for encouraging a positive outlook and leading a productive class on the design process. Nice work!
Participant Team Building
I’d like to share one anecdote that illustrated the importance of team building and reminded me that hackathons aren’t just about coding skills.
Once the groups were formed mentors were expected to go around and see that participants were off to a strong start in their ideation.
Immediately I could see a problem in one group just by the look on one teen’s face.
“I think I’ll go to a different team,” she said, with a tinge of guilt.
“Why?”
“I don’t want to change their plan,” again she said with a pained look.
This is what educators call a teachable moment.
If left to her own internal processing this student would have been willing to remove herself from this team because she hadn’t considered the value of her presence and ideas.
Fortunately, with some guided questions, she stayed and helped the team pivot to a community building and sharing platform called Neighbor 2 Neighbor.
I was so proud to participate in the hackathon with the Mozilla team because they believe, as do I, that youth hackathons can be about more than building cool products. The values that I and the SPARK! organizers share with Mozilla give us the chance to lay the foundation for students to build a more just and inclusive society while generating awesome ideas and writing code.
By staying in the Neighbor to Neighbor group the student I coached practiced the courage to realize her value and become a leader in her group, developing skills that will last beyond the next great idea and prevalent coding language. One component of Mozilla’s problem statement, “establish and build trust between community members,” set up her and her team, along with the 60 other teens from 16 high schools in the region, with a value to guide but not limit their ideas.
Thanks to her teammates she learned that her presence and ideas are valuable; she doesn’t need to change herself for a group or leave it.
