Almost a week and a half ago now, I attended Startup Weekend Seattle as a developer. It was an incredible, unforgettable experience. I had read Justin Woodum’s fantastically helpful post about preparing for it, but I was not expecting a lot of the events and lessons I came away with. Throughout the weekend, I worked on three different teams, going from enormous, to dysfunctional, to just-right.

For most attendees, the weekend looked something like this:

• Friday night – network, listen to people’s ideas, vote on ideas and form teams, and come up with a more concrete plan for the team for the weekend
• Saturday – develop, design, do market research, refine business model
• Sunday – keep working (if frantically) until giving final presentations – pitches – at 4

My weekend looked more like this:

• Friday night – meet lots of awesome people and scope out which projects I want to work on; during team-forming, realize that developers are – surprisingly – in short supply for most teams. After trying hard to come to any consensus with 15 people on Team #1 (most other teams were about 5 or 6 people), leave for Team #2 with no developers but a cool idea. Spend 40 minutes trying to up the morale and set reasonable goals for the weekend.
• Saturday – spend first part of morning iterating on the progress from previous night, and the second part fighting with a communication-damping leader. Code all afternoon, until leader leaves in a huff and the team disbands. Join Team #3, work like a maniac…
• Sunday – …continue working like a maniac in a productive, supportive team, until it’s time to present a demo product that we are actually pretty happy with

Team #1

The first team I worked with was an incredible set of folks who wanted to make a mobile app to bring joy and delight to people’s lives by enabling giving surprise gifts. This team bustled with lots of designers, business-people, and developers, while some other teams I was interested in had no developers. After three hours of trying to organize a conversation, this team seemed like it could use less people. Even though I was not the only one to leave, drama still ensued, catalogued brilliantly and hilariously on Dwight Battle’s blog in parts 1 & 2. This journal includes gems such as this:

The group had arrived, and we had already picked up where we left off last night. One of the developers asked me, “can’t you start designing something?” I replied with, “what the hell am I designing?!” We had no focus, we were talking about everything from who we were trying to reach, to business plans, to revenue models. Everyone was overwhelmed, nobody had a task, and again, we were talking over each other. Attempts to reign in chaos were futile. At one point, our project manager, Dani Harder, held up an orange and said, “whoever holds the orange gets to talk. No interruptions.” Which worked fine, until one of our business guys, Ken Decanio, talked so long, that he started eating the orange while he was talking. I’d had enough.

Now that the weekend is over, I have – delightedly – rejoined the team, which is now smaller and more focused.

Team #2

In retrospect, the experience with team #2 was a very useful hand-on learning experience about teamwork and communication. At the time, it was infuriating and frustrating to no end. When I initially joined the team, morale was way down among the four people already on it. They were planning to just make a mockup for the presentation on sunday. So, on Friday night, I tried to up the spirit a bit, and get a concrete sense of goals for the weekend, taking example from the manager of Team #1, Dani Harder.

When we all came together on Saturday morning, things seemed great. We got a whiteboard, rehashed the progress from the night before, and were about to set to work when the leader/visionary – the guy who actually had the idea in the first place – showed up. He contradicted everything we had decided on, allowing no room for discussion. It seems negative to put it that way, but he quite literally prevented communication. If I have learned anything from this, it’s that assigning blame might not be wise in a tight team setting, but identifying people who directly prevent progress is the first step to the solution.

The whole day, it was us and him. Various mentors from startup weekend came to speak with us and give their insight, knowledge, and advice, and the moment they would walk away, this guy would disagree with them and tell us not to do what they said. We couldn’t even talk about what just happened without him jumping in and repeating his unyielding stance on every issue. There was no compromise anywhere in sight. And yet, we persisted.

Morale was down. I wanted to leave, but when I bumped into a few members of Team #1, they joked about how I got away in time – clearly, not an invitation to make a come back into a team already fraught with dissenting voices. Also, I grew to really like Team #2 and I wanted to make a demo-able product by Sunday.

And then, at about 8 on Saturday night, well past what would seem the point of no return, the guy announced that he would just make something pretty in photoshop by himself, and left. The rest of us were stunned, and decided not to stage a coup by just making something ourselves but disband and help other teams.

Team #3

Look at all this glorious absence of drama!

And so I came to join another team with no developer! Better yet: a team who had seen several developers, all of whom used ruby, which is not something I know. So that was a learning curve, as well as the fact that what we were making involved a JavaScript-based music player, and I have never done anything like that. So I spent a long time wading through the echonest, rdio, and last.fm APIs to chain a reasonable application for a music-trivia-ish game. You can read more about this project on the #SWSea posterous!

The Moral?

I have always been the overachiever who disliked groupwork in school, but despite all the tribulations of the weekend, I realized I really, really enjoy being a part of a team. Furthermore, I think the lessons I learned – by watching and by doing – about how to manage a team effectively will serve me for a very long time to come, so I would strongly encourage pretty much everyone to go. A team can provide a supportive, encouraging, and enthusiastic environment, but only if all the members of that team are invested in communicating with one another at least as much as they are in doing the cool thing they’re doing. The seemingly simple task of maintaining open channels of communication is no easy one, and management skills can make or break any number of cool ideas.