This is a guest post by Justin Elof Johnson, the co-founder of Late Labs.
I was part of the group on the bus that departed from San Francisco, while five other buses left from other parts of the U.S. When the ride started, we quickly formed teams and pitched ideas. After going through ideas, we eventually pulled over in a Walmart parking lot and started a “speed dating” process that consisted of people saying which ideas were best and what they could contribute to the project.
Our team eventually formed, and ended up being nine members — twice as big as the other two teams on the West Coast bus. Having that many people and trying get traction with it in three days seemed like an impossible feat, but we eventually came up with a simple platform that we could rally behind.
We built Ghostpost.io, an anonymous chat application, and made it all they way to the finals and eventually pitched to Dave McClure and Robert Scoble. The app has been used in 70 countries by more than 5,000 people since we launched on March 6th. We don’t know what the future of Ghostpost is, but we had a lot of fun building and using it during SXSW.
After reflecting on the experience, here are three big things I learned about teamwork:
Assign leaders as fast as possible
Our Ghostpost team had a lot of big personalities with previous leadership experience. One of the reoccurring problems we encountered is that we often came to a standstill on what to do next because we would spend an hour or more coming to a consensus on every little decision. We had clearly defined roles for development, design, and strategy. But we never made it a point to assign leadership roles within the micro-groups or to assign one person as the overall decision maker within groups.
What ended up happening was different people trying to take the reigns as the leader at different points in the competition. This created some frustration among team members and flared up some egos. Some members started to not listen to other team members while barking orders about what we were all going to do next. Some team members withdrew and started to work on things on their own. Others got upset and gave up.
We ended up with a divided team that eventually built similar (but different) products on two different platforms. The outcome was us delivering a stripped down version of the full idea, but at the end of the day it worked out well.
If we had taken the time to assign leadership responsibility to one or two people and all agreed upon that, we might have been able to get a lot more done with the time that we had.
Figure out everyone’s communication styles as early as possible
Communication in a professional environment is much more then just talking to people the way that you would prefer others talk to you. This became apparent when I was on a bus with eight other people I had just met. Some people want to talk about every little thing, while others want to have short huddles and then work without being bothered.
When you are trying to be democratic about decision-making, it’s easy to have group discussions, but unless these discussions are structured, the loudest and most aggressive people end up getting their say and no else gets a word. This immediately creates dissension in the ranks because subgroups begin to form so the less vocal folks can say what they think without being interrupted.
In the future, I’m going to pay more attention to the communication styles of the individual team members and work toward creating an environment where team members get equal opportunity to voice opinions.
We built a minimum viable product almost immediately, and everyone was pretty stoked on the outcome. As a way to test if anonymous chat would be interesting, we created a Twitter account and gave everyone in the team access. Everyone ended up checking the account obsessively to see if people were posting, and people wondered aloud about about who posted the last tweet. As a joke, any time someone asked that question, every person on the team had to raise their hand.
After our basic product was up, iterative development seemed to stop. The team was making headway, but instead of prototyping new builds, we all got caught up in feature creep and didn’t actually deploy a working testable prototype until the morning of the first pitch in the competition. We were able to hustle together some legit user testing, but we could have had way more numbers with more time.
Companies often miss release dates because they want to get one last feature done. This exercise was a great reminder to always build the core of the product first and worry about the nice-to-have’s later.
I came out of this crazy experience with eight new friendships. There is a special bond that comes out of a 3 a.m. hack session in a New Mexico hotel.
Being an entrepreneur takes practice. Competitions like StartupBus and hackathons create an intense environment that stretch us to our limits and force us to think about things differently. And now I think encouraging this type of intensity and team building should be a part of every company’s culture.
VB’s research team is studying mobile user acquisition: Chime in here, and we’ll share the results.