Summary
- Context about my role in leading teams, and what being into hackathons is like in a country that doesn’t have the culture for it.
- Teams of strangers vs. Teams of familiar veteran hackers in the US
- The System I developed to evaluate people and build teams.
- Mindset in leading and facilitating teams.
My context
In most hackathons, I usually lead the team.
Sometimes by merit, sometimes because no one else wants to, and sometimes from being the one who brings the team together.
I enjoy leading teams, it’s fulfilling to me and I find myself empowered to do more when I have responsibilities to people. I rise to the occasion. I care about my teammates,
- are they having fun?
- is everyone having a chance to be heard?
- are they able to achieve their individual goal and is it aligned to the team’s goal?
- are they getting visibility?
- how are they going?
I treasure not leading teams – ideally, it means I can learn from someone’s leadership of a team. Perhaps someone is more suited to lead that particular team or I joined a team with a lead already. What systems/frameworks/PM style do they use? What can I learn here? Why did they do this?
There is a supply/demand problem in Australia (where I’m from).
As Australia has a comparatively lower focus on the tech industry than the US, its hackathon culture isn’t that strong.
Consequently, I am a rare hackathon athlete in Australia, and few of my friends or colleagues would want to sacrifice their weekend to nerd-out at a hackathon with me after a long week of work/study.
Thus, whenever I do a hackathon – I have a disadvantage in team formation. In Australia, because I did not study CS – it’s harder to simply grab uni mates with the right skillsets. Especially in the US scene, my network is drastically smaller than hackers who studied and/or worked there. I entered knowing zero people.
versus teams of Pokemon’s Elite 4 - all at once
In the US, the force hackathons is strong there. There are people who have won and done more than me. There are hardcore hackers who tour the states competing in hackathons with the same group of 4. The synergy from working with a well-balanced, committed, skilled, and familiar team is huge. Often they prepare their ideas and design before the hackathon, saving hours of hack time.
Interestingly, all the extremely experienced hackers (~past 50 hackathons) I interacted with – have a quirk in some way. A writing for another time seed
I’ve never tried to establish a solid elite team of 4 from great hackers I’ve worked with – mainly because it’s tricky to align the interests and timing of 4 strangers, and I actually enjoy hacking with new people because it expands my US connections and serendipity.
Fortunately, a constant is myself – so I learnt to carry my team both technically and non-technically, and to empower them to contribute in the ways they are able to.
If you want to go fast - go alone, if you want to go far - go together.
No matter how able I am or easier it can be to be solo – I still much prefer working in a team.
- Firstly and most importantly, it’s simply more fun ✨.
- Secondly, every teammate brings a unique set of strengths to the table. I can make great pork dumplings alone, but when someone brings the right sauce or makes the Charsiew Bao’s – then we have a feast. 🥘
- Thirdly, as a consequence of 1. and 2., teams scale (1+1 = 3, to a point, then things the pros/cons shift and need to be managed differently). There will always be strengths that teammates can bring to the table. Whether it’s expertise in a tool, a unique perspective or even a vibe that makes the team atmosphere more fun.
That makes the effort worth it - it takes more effort to collaborate with strangers, but there are magical moments that arise from it.I made a handful of good friends from hacking, and whenever we’re in the same town – it’s a joy to hangout. They are always welcome to my home.
Of course, a team of strangers doesn’t always pan out. For many different reasons, misalignment can occur and poor outcomes result.
However, it’s still a great experience. You can still improve, and the next time a similar situation arises – you can influence and adapt more effectively to produce better outcomes. It’s valuable – as the world is people, so you shouldn’t shut yourself out even from a few poor experiences. Often in a strange way, you learn a lot about yourself too as a person.
However, it’s definitely challenging to compete as a team of strangers against the hardcore teams of Elite 4’s. You still want to try team up with decent people – or at the very least, aligned people.
I’ve established systems to build the best possible team I can from the pool of strangers I can reach.
Once the game begins, you have to play ball with the cards you’ve been dealt or that you can find. Over time, I’ve refined my systems to market myself more effectively, and to evaluate potential teammates more accurately.
The magic of hackathons
No matter how strong those Elite 4 teams are, it’s entirely possible for a team of beginners to win 1st place and beat everyone.
I’ve seen it. And it’s magical how a more fundamental appreciation of a problem and a truly special solution can triumph.
How to Evaluate - Team Forming/Attribute System
- 5 attributes I look for – evaluated holistically:
- Skill
- Commitment
- Vibe
- Alignment
- Working-style fit
- the most recent attribute I’m still defining. The others can be determined quite well before teaming-up, this one is harder to reveal outside actually working together.
Interviewing: To form a team, I’d talk to prospective teammates and ask questions that would indicate those attributes. I’d would rate them, and also calculate a holistic metric. After talking to enough people, I would rank by their scores and put a team together based on overall compatibility in working together and also towards an approximate tech stack.
This takes time. Sometimes taking hours if you talk 15-30mins to each person. More often then not, I don’t get to apply my Teaming Forming/Attribute System entirely because of situation constraints or because it’s overkill for my goals for that particular hackathon.
However, I’d at least try to get a quick sense and do a mental check. Remember, 80/20 rule.
What order of attributes matters?
Great question!
I recall my journey in discovering and adding to these attributes criteria went from:
Skill > Commitment > Alignment > Vibe > Working-style fit
Over experience, I’ve refined the order of priority to be roughly the reverse:
Attribute Order Priority: Working-style fit > Vibe > Alignment > Commitment > Skill
The order of attributes is not a hard-and-fast rule, it should be evaluated holistically
- E.g.
- Commitment matters nearly as much as Alignment
- what if the vibe is medium, but alignment is high?
- If alignment on goals is not met, if there is high commitment – couldn’t something be worked out?
Essentially, you want as high as possible for these attributes
- But you’ll rarely ever get to work with someone with high across all 5
- I’ve never worked with a single person who was high across all 5 even after 132 different people – especially when they were strangers and it was a snapshot in time
- Which is why Feedback is so important, to grow a team and yourself
- This Attribute System is a framework aiming to give the best chance:
- to avoid Team Killers, or poor-fit people
- highlight foreseeable issues to mitigate or avoid
- evaluate people more accurately with less bias and emotions
- manage expectations and increase alignment
Skill?
Initially, I looked at the skill-level of people as most important in building a team.
- Of course! You need great backend, frontend, designer…etc to make great webapps right?
- Surely someone with tons of GitHub activity, projects and experience would be great?
Nope, skill level matters, but it’s not nearly as foundational. There are more important upstream attributes.
Commitment?
Then, I realised it meant nothing (and can even be detrimental) if skilled developer X was only available for 10% of the hackathon.
So, I added Commitment to my system.
- My engineering mindset loved it.
- If
- member(x) = skill(high) x commitment (40 hours)
- then,
- output(x) = high x 40 hours 🔥
- output(x) = high x 40 hours 🔥
- If
- Nope 🙂↔️
- Forgot about vectors (object that has both a magnitude and a direction)
The direction (alignment) matters as much as the magnitude (commitment)
Alignment?
Analogy: a team is like rowing a boat, if each person decides to row in a different direction – can it go anywhere effectively?
If that Backend wiz simply wanted to try build with some shiny new tech with no user value add, or suddenly learn Frontend – that would not be effective contribution to win a hackathon.
- Over time, I became better at decomposing the vector’s direction into sub-vectors
- e.g. Okay, you can learn Frontend – could I ask for your expert help and guidance as I do the Backend?
Get skilled and adaptable at aligning your goals and different teammates’ goals with the team’s goal
So, I added Alignment.
- It became obvious that Alignment played a consistent role throughout entire projects.
- There are many forms of Alignment seed
- managing expectations
- goal and mission
- product understanding
- Steel Thread for technical alignment
Vibe?
Then one day, in my 3rd US hackathon, I was looking for teammates on Discord.
I chatted with someone who had solid skillsets in VR, was committed to the entire hackathon, and wanted to win just like me – terrific! I brought them into the team.
The reality was 😩, this skilled, committed and aligned teammate – was a strong pessimist and constantly brought down the team’s atmosphere throughout hacking.
- They constantly shut down the ideas and opinions without proposing solutions
- They expressed negativity in their speech, thoughts, and actions – and influenced others to shift to a more negative mindset
- They were largely unhelpful
If it's not fun, why bother?
Reggie, ex-President of Nintendo
You said it Reggie!
- Before winning, even just participating in a hackathon – asks for a lot from the team
- teammates give up weekends, push other commitments back, sacrifice sleep, energy and opportunity cost
- they better have a reason they are here instead of going to the beach
Teams having fun outperform Teams not having fun
- Management Consulting firms, startups, and FANG – why do we do behavioural interviews?
- Management Consulting firms – literally, interview you and evaluate if you’re someone they would want to spend 16 hours in a room with
Similarly in hackathons, you’ll spend ~40 hours in the same room – you want good vibes 😎
Vibe cannot be accurately discerned from text chatting. At minimum, you need a voice or video call. How do you feel from interacting with that person? Do a vibe check.
Working-style Fit?
This is the one I’m still defining.
In more recent hackathons, I entered last minute after the hackathon commenced – meaning most teams have been formed and the teaming limitations were trickier.
- I usually had to join a team rather than build one myself
- There were fewer options left
- I couldn’t apply my System fully as I wouldn’t have time to talk to all other prospective team members and get a good read
Fortunately, with a solid track record – many teams reached out to have me join as their 4th member. I still applied my Attribute System to do a quick mental check if I would be a good fit for their team(s).
I teamed up with people who were Neo Scholars, who were class Presidents at globally top universities in the US, who had great credentials, who had startup experience, who had their idea all ready, and who worked together before.
All positive signals to me!
- From a quick sense – they had Skills, Commitment, Alignment, Vibe
Outcome: lost all of the 3 hackathons
Why?
People are complex. There are things I could have done better too.
Fundamentally, I’d judge it as incompatibility in Working-styles
- I haven’t figured a reliable way to evaluate this before working with someone
Here are some signals of Working-Styles that I only found from working with them:
Dishonesty and Lack of Transparency
e.g. they did not want to reveal or share their idea until I committed to joining them, even after I gave assurance I would not steal it
Inflated Credentials
their ‘startup experience’ was helping out in their sibling’s startup
Lacked Resiliency
Weak Collaborative Spirit
Fair-weather Friends: together in sunshine, gone with rain
Lack of Trust, or Heavily Weighted self-opinion
There is no evil (kinda) seed
This is a tricky concept that would need more thought and paragraphs to convey well.
Basically and over simplified, people have different views on what’s ok and not ok – understanding this helps in acknowledging the differences of others without having to fixate on agreement/disagreement.
To those people in those teams, it was ok to be like that from their unique perspectives and experiences.Over simplified, while these signals above wouldn’t sound like ‘good’ or positive characteristics to most people including myself.
I’ve come to realise that people are multi-dimensionally different. To some people, these are good and okay to do – while to others, bad and not okay. The value of this concept, can help you to understand people – as you’re taking a step back. A team with these working-styles/values might still be able to work together and produce good outcomes.For me, it was more of – these are working-styles I am personally not compatible with and I do not wish to build in a team. Although, If I found myself in a similar situation, I’d know how to manage it better and make things happen.
Conversely, I’ve hacked with people who are extremely easy to work with – with seemingly lower attributes and credentials – yet, we’ve consistently produced great outcomes.
A story of trust
I was chatting with a Stanford friend (Jasmine) I hacked twice with,
- I was admitting my mistake for pushing for a silly feature creep idea, and asking why she trusted my judgement despite her disagreement with that feature
- She said, “Yeah that was off, but frankly you’ve done way more hackathons than I have so I’d trust your experience more. Even if you’re wrong sometimes, you know how to make things work out – so I trust you.”
- That touched my heart, because I felt trust. I still strongly encouraged her to call me out when she disagrees
- We won in both hackathons with thousands of dollars cash each
- I Invited her again to hack with me – because we trusted each other to voice our opinions and could have great discussions that resulted in better outcomes
- It was a safe place we could disagree – psychological safety does wonders for performance
Working-style Fit is about answering Value Questions for oneself and for others,
- What do we value?
- When the masks are torn-off, what is revealed?
- What are we like when things go wrong?
- When we’re stressed, sleep deprived, and rushing for a deadline – what do we become?
- How do we resolve disagreements?
- How much do we care about others’ opinions?
- How do we trust each other?
- How do we make decisions?
- How honest are we with ourselves?
Working-style Fit is about answering Value Questions for oneself and for others
- If similar values and answers are found, the team is compatible and will shine even in the darkest night ✨
- If conflicting values and answers are found, the team is not compatible and the smallest cracks will shatter the team ⛓️💥