Seattle Startup Weekend

It’s nearing the end of the first full day of the Seattle Startup Weekend. I didn’t get a chance to post every update, because I got too distracted with the learning process. You’re probably thinking that’s not a great excuse! But imagine, if you were expecting to be completely behind technologically, and blogging away in a corner, and instead there were other folks following through with tutorials and things you have already done, you’d be a little distracted too. I was over in the dev wing. Our fearless leaders (not sure if they were appointed, or have natural abilities, or what, but for sure they were fearless) prevented the marketing, UI, program management, product management folks from coming over for quick chats. Productivity lay flat while the learning curve soared. While that can be uncomfortable giving a status report, it was the honest truth. It seemed everyone was jazzing on Django and doing a crackerjack job of putting together the pieces to support a real product.

I’d like to write a quick sidebar of things that did not go so well so far. And for this I blame Seattle itself, due to our consensus based culture, which inhibits leadership and leads to crowdspeak and crowdact and eventually a lemming type of existence. (Lemmings with lattes, that is). The main thing that did not work well was the choice of project. Projects were promoted to the front on the basis of if they were “gotten” (as in “I don’t get it”). Other than this simple I get it or I don’t get it, it was very hard to set attributes on a project or a group of project ideas because we were each only looking at a small few at a time. The attributes should have been scope, originality, competitive landscape, viral, the list might go on. The narrowing down process resulted in some finalists that were explainable, but failed on the attribute level. Many other ideas that had better attributes, but lower explainability to that specific table, were sent home. Here’s the rub. If Seattle planned on flunking out an idea because it had a poor competitive landscape (two other players already failing at the same mission), then we should have performed the competitive analysis on a range of projects before the idea was selected. There could be a 20 minute analysis performed on each one, and we’d gain much from their report. On the flip side, if it’s OK for Seattle to pick an idea without doing a competitive analysis, then we’re saying we won’t change the idea if the analysis comes up short. But that’s exactly what we did. This goes along with the “act first, review later” type of pattern that brings me to my second point. An initial data structure was used for the database. This data structure was not reviewed, but we did not expect much and we limped along with what we had. Then another, better data structure came along. The thing is, if we had focused our energy on writing and reviewing the data strucutre in its initial iteration, or even the second, we would have smoothed the learning curve for many people, myself included. As Seattleites who are shy of confrontation and of authority, it makes sense that we would want the idea process to go as quick as possible (regardless of result), and it makes sense that if someone hands us a data structure we say thank-you and work with it. What should have happened? A more dogmatic group would have added a checkpoint and determined what the bar for entry was, and whether this met it. Yet, we’re from Seattle, we don’t want to hurt anyone’s feelings, and setting up a dogmatic structure like that sounds, well, not very nice. Let’s just all agree on something and get on with things. Yet it’s these checkpoints that we cite as the thing missing in the postmortem.

Many process points did go well today. The majority. Practically all. We broke into tables that took certain areas of the product. (You can read about the idea we’re doing in other posts). Some tables had people that needed to work on the whiteboard, or with other groups. Others had subject matter experts at the table, while some did not. (My table did not, and sadly I was behind even them, but still ahead of those doing tutorials, for the moment at least). A contribution was sometimes doing a svn up and seeing if anyone had broken the build (or more likely the synchdb). Other times, a contribution was dropping in the logo, or adding a new menu item. Someone gave an excellent talk on some Django basics, before we got too mired trying to think about problems in SQL that weren’t necessary. Several more advanced folks were on-call and roaming, with a helpful “Ask me about Django” scribbled on their nametag. It didn’t make up for not having the schema locked earlier, but many tables made enough progress that by the end of the session they were done until there was a big delivery from a different table. Most people had the basics of basecamp, subversion, python, and django installed, and tricky environment stuff was posted to whiteboards and to the wiki.

Sitting over in the dev side, I occasionally looked up to see the energy in the rest of the room that we were being so effectively shielded from. I’m usually a program manager, which encompasses project management, UI and interaction design, sitemap, requirements, and scoping. I knew those people were out there and wondered what they were talking about. I was happy I made the choice to be a dev for the weekend, or at least sit in the chair and synch to the latest build.