May 26, 2023 | Elisabeth Kim
Glitch Hackathon was my first-ever hackathon experience. I participated as a passionate builder in the Project Manager role with a team of 5. I started the hackathon in high hopes of kicking off a product I had been ideating for months and taking home some cash prizes.
My dreamed triumph unraveled as a catastrophe during the final 5 hours of the hackathon with a series of unfortunate events
A team member stormed out of the campus in the middle of nowhere under the relentless onslaught of the rain. Another member vomiting and crying, and then deleting all the files in the project’s Github repo. A friend quickly helping me recover the repo and then getting announced in the official group chat of the hackathon with 459 members as a Code Thief. (I had not submitted the final project which freed my friend from any allegations that my friend was actually a thief.)
So, how did everything go so terribly wrong? Here are the 4 things that ultimately lead to a tragic hacking disaster:
Overly Distinct and Isolated Roles.
Each team member was assigned a specific function and role even before we had a clear understanding of our end product.
- Project Manager — Priority, timeline, wireframe, content, QA, pitch
- Designer — NFT design, logo design, web design
- Front-end engineer — Front-end development (React JS)
- Back-end engineer — Web 2 elements, Front & Back-end integration (Javascript)
- Smart-contract engineer — Smart Contract, Troubleshooting
While clearly demarcated roles are generally encouraged in professional settings, this stratification incited an uncooperative sense of individualism within our team. During hackathons, traditional roles and rigid deadlines may be counterproductive, igniting blame games when a member falls behind. A more collective, step-by-step approach could perhaps have been more effective.
Granting Proprietary Ownership
The team’s Smart Contract engineer copyrighted all of his codes and other back-end codes integrated with the Smart Contract in the middle of the process. Nobody on the team foresaw the implications a copyrighted code had until shit hit the fan. In a fit of fury, he barred the team from using his codes to submit the project.
Prior to this unfortunate incident, the team had placed our Smart Contract developer on a pedestal due to his expertise. The other team members, relative novices in the realm of Web 3, revered him. However, in the shadow of his claim to copyrights, the collaborative efforts of the rest of the team in ideating, designing, and building went unacknowledged.
I’ve now understood that the proprietary rights of a group effort must remain collective, and that appreciation for a team member’s skills shouldn’t be overly expressed.
Misjudging Scope and Complexity
No real product is intended to be made in the course of two nights. My team did not take that into account when designing the system architecture and aimed to build a perfect product for the market.
Instead of using temporary online servers for storage, we opted for MySQL and EC2 databases expanding the scope of development. We created 8 different layers for PFP NFTs, when we only needed 6 PFPs for the demo. We used solely our own brains to write code rather than to find and piece codes together from Stack Overflow or Github. We spent hours discussing security issues when the criteria did not even mention it.
Our ambitions to build something perfect did not account for reality. And while I believe the product’s architecture would have done great for a market release, it was inept to build for a hackathon. I’ll advise everyone to research short cuts and easier methods to everything, before finalizing architecture and strategies.
Emotional Stress
In future hackathons or high-pressure scenarios, we need to establish mechanisms to manage stress, encourage open communication, and handle disagreements or conflicts constructively. Time should be taken to ensure all members are coping well, and where necessary, breaks should be taken to rest and regroup. I’ve realized that in times of crisis, maintaining emotional control can make the difference between catastrophic failure and a triumphant comeback.
Normally, you join a team in a hackathon without extensive knowledge about your team members preferences and capabilities. Even though you and your team members are going through exactly the same experience, it’s important to realize that the perception of the experience will be different upon each individual’s prior experiences and expectations. Hackathons are intense, but what is bearable enough for you may be the most stressful situation your teammate has ever been through, or vice versa.
As the project manager, I take responsibility for not properly managing the team’s emotional state. I realize now that fostering a supportive, understanding, and patient team culture is just as important, if not more so, as meeting deadlines and producing outputs.
Even though I didn’t secure any prizes, the experience allowed me to broaden my professional network, deepen my understanding of Web 3 technology and industry, and foster valuable friendships. Despite the tumultuous ride, it was an invaluable experience that spurred professional growth, and fostered a closer relationship with my therapist lol.
Special thanks to Martin at Bisonai, Dragos Roua (Winner of Polygon track), Prince Akpeki of SojuDAO and Han from EvmosDAO for lending a hand to the team during the times of turmoil.
See you at my next Hackathon, ETH SEOUL. 👋
