Thursday, July 17, 2014

My Condolences to Laid-off Microsoftees

My heart goes out to all of you who were affected by the Microsoft layoffs.

I was an engineer at Microsoft during the 2009 layoffs and, even though we knew they were coming, it was a shock when whole teams were eliminated regardless of performance. The layoffs announced today are just as difficult and several close personal friends came back from lunch today with no manager, no team, and no job.

This will be, without a doubt, a difficult time. Not just for those laid off, but for their families, friends, and our entire Seattle tech community and beyond. At the same time, I'm certain it'll open the doors to many new opportunities.

To all my friends and everyone else affected, my condolences. On to better times.

Thursday, April 17, 2014

Why Failing in School Was One of the Best Mistakes I've Ever Made

"Fuck me... I'm gonna get kicked out of school."

As I looked over my grades, the pretense of a bright future crashed down around me. I had been skating by for the past 2 years doing just enough to get by and it had finally caught up with me. "Two F's," I thought, "...double fucked. My life is over."

Before college, I was a great student. Under the close supervision of my parents, I managed to stay focused enough to keep up excellent grades while taking all honors classes. It was a time when I truly believed in my grand dreams of being a scientist and a visionary leader. But once I was out of my parents' house, I quickly fell prey to the seductive charms of my new-found freedom. My nights were consumed by parties, which meant my days went to recovery.

By the time I'd reached my junior year, the bad choices I'd made dropped my GPA to a 2.3, marginally above the threshold that would trigger expulsion. The two F's also put me on academic probation, meaning another bad quarter would also get me kicked out of school.

I immediately fell into depression, accompanied by deep reflection. As I assessed my life and what I hoped to achieve with it, I realized that, as humans, we're capable of constantly redefining ourselves; that while we can't change the past, we always have the power to shape the future.

This failure was a pivotal moment in my life and the boot to the face I needed to make me get my shit together.

After that, I stopped drinking. I cut back on social activities and invested my new-found time into studying. I coincidentally "discovered" computer science around the same time. The quarter after my grand failure, I happened to take a fundamental course in computer science (data structures and algorithms, for those familiar), which was optional for my major. About half-way through the course, something amazing happened. Something clicked. It was one of those moments where you suddenly just get it and the universe becomes incredibly transparent.

From that point on, I dove into computer science with passionate fervor. I filled as many of my upper-division requirements as I could with computer science and I excelled. I was getting nearly all A's and found myself programming in my spare time. That summer, I somehow convinced a startup to take a risk on me and got an internship as a software engineer. I soon started taking graduate-level courses and getting the highest scores in the classes.

Over time, I decided that I wanted to go to grad school to study computer science in more depth. By the time the application period opened, my GPA had turned around, but I'd done so much damage earlier that it was just below the 3.0 required for graduate admissions. Undeterred, I poured myself into the application, applying for a GPA exception and rallying support from the professors I'd gotten to know through my graduate-level coursework.

On a sunny San Diego afternoon, I was sitting in the basement of the computer science building and an email from the graduate admissions officer popped into my mailbox. I felt sick to my stomach and started trembling as I nervously opened the email and started reading.

I'd gotten in.

I nearly cried as an overwhelming flood of emotion came over me. Two years after I'd obliterated my future, I sat back and reveled in the moment when I knew I'd finally earned it back.

Friday, February 28, 2014

Welcome to the Future of Interactive Websites: Leap Motion

I stared excitedly as the lid of the suave, white box glided gently open to reveal a sleek, black device; a minuscule piece of hardware that made the bold promise of changing the way we interact with computers.


That little device was a Leap Motion, which arrived at my house unexpectedly in July, 2013. I had pre-ordered it in Nov 2012 and by the time July rolled around, had long forgotten that I’d done so, making it a pleasant surprise.

I plugged it in and started playing with it right away. The creators of the Leap did a fantastic job designing an Apple-esque end-to-end experience. The packaging felt great, the device itself had visual and aesthetic appeal, setup was simple, the APIs were well thought-out and documented, and the app store had some cool initial apps to play around with. Unfortunately, the apps were trivial or offered disappointing experiences, leading many friends to dial up eBay to unload unwanted devices. I have to admit that I was underwhelmed too, after having had my expectations set by the revolutionary vision promoted in videos released during the pre-order campaign.


But I’m a sucker for hardware, so I kept my Leap. After a few weeks, I found some free time and wanted to see what it would take to build an app. To my delight, I quickly discovered that they had cleverly architected the system such that it’s fairly easy to use with almost any programming language, and their APIs reflected this. I held my breath, hoping I’d find a JavaScript API and sure enough, there it was. “Wow!”, I thought. Suddenly I had the ability to take advantage of the most powerful software distribution channel in the world along with the ability to hack (via Chrome extensions) a unique interactive experience into the virtually unlimited software that was already available on the Web.

I began experimenting and found working with the Leap and its JavaScript APIs surprisingly easy and fast. One of the first things I built was a Chrome extension that allows me to control Reveal.js presentations with my hands. I then started playing around with WebGL. In no time, I was touting how much fun the Leap is to all my developer friends, which quickly led to a conversation with Will Little, co-founder and CEO of CodeFellows (an awesome program, if you haven’t already checked it out), and we started planning a workshop for the local community to learn how to program the Leap for the Web.

On February 20th, about 40 developers of all skill ranges shuffled into the basement of 511 Boren Ave North in Seattle, a venue otherwise lovingly known as “The Easy”. Leap Motion had generously sent us about 20 loaner devices in advance of the event, so as everyone settled in they went through the same magical experience I did when I first opened the box and lit up the device.


We went through a few basic examples, with participants making simple modifications to the sample code along the way (workshop presentation here). Then they were off to the races as we kicked off a brainstorming-and-open-project session. They came up with some cool ideas like a Theremin, an interface for exploring gene sequences, and a bunch of other ideas I don’t remember. While none of the more ambitious projects made sense for the short time we had, people built some fun stuff. The project I was most impressed with, which happened to be built by a pair of CodeFellows students, was a rock, paper, scissors app that accurately detected the count and final hand shape using the leap.


In summary, the Leap is a very cool tool that creates opportunities for unique interactive experiences on the web. People jumped way too quickly to concluding that it under-delivers on its promise. It’s easy to develop for and everyone who came to the CodeFellows workshop had a blast, regardless of skill level. I can’t wait to see more creative uses of this technology.

Sunday, December 1, 2013

1 Year After Microsoft


I still remember the funny feeling I had in my stomach as I drove home from work on November 30, 2012. It was my last day at Microsoft after working there for nearly 5 years.

Today is my 1-year anniversary of life after Microsoft. I left the company with the intent of becoming an entrepreneur, but had the fortune of landing at Madrona two weeks later. Both of these transitions weren't without concern at the time, though I remain exceptionally pleased with both decisions.

It's been an incredible year. Some experiences have been pretty much as-expected and others have come as a surprise. These are some of my observations and experiences one year after Microsoft.

(UPDATE: Be sure to check out links to other people's experiences at the end)

Life Outside the "Mothership"
  • While at Microsoft, I tried to actively engage in the broader Seattle community and thought that I was doing a good job building a diverse network. This made it all the more shocking when I realized shortly after leaving how heavily weighted my network was with Microsoft contacts. I love my friends and colleagues from Microsoft, but having a network that's concentrated on a single company and one that creates generic solutions rather than vertical-specific ones is a huge weakness when it comes to entrepreneurship. I suspect that it's also a weakness in business and career growth in general, but don't have as much evidence of this.
  • Concern about no longer having access to resources was unfounded. Microsoft provides vast resources to employees for both work and personal purposes, but living without those has been inconsequential.
  • I do miss the compensation. I took a massive pay cut when I left, but I believe more than ever that "compensation is the price a company pays for making you put up with bull$". I continue to live very comfortably. More importantly, I've found that I'm much happier than before, providing some validation to the non-linear relationship between financial compensation and happiness.
  • I tend to thrive in uncertainty, but I have to admit that there are occasions when the certainty of the Microsoft environment sounds nice.
  • External perceptions of Microsoftees are different from internal ones. Inside Microsoft, there's a sense of being among the smartest people in the world (which isn't unfounded - many brilliant people work there) and that the skills developed working there are a thing of pride. Outside Microsoft, perception increasingly looks like the kind of respect you have for dinosaurs. Many skills and accomplishments are irrelevant or limited in scope when looking outside Microsoft's bubble. In terms of false perceptions, I continue to hear disparaging remarks about how people at Microsoft work 9-5. I can't think of a single Microsoftee I've met, past or present, who works 9-5. 10-12 hour days, 6 days per week is more typical from my experience.
  • All companies have their issues. Sit around the cafeterias at Microsoft and you're bound to hear a good percentage of conversations complaining about something or other related to the company. However, over the past year I've had lunch with people from at least 50 different tech companies and every company, big or small, has its issues. What's really important for individuals is to take a holistic view and identify what's tolerable and what's a deal-breaker.

Personal Development
  • When I was at Microsoft, I didn't get much time to learn non-proprietary technologies. During nights and weekends any work I did was for a company project or learning internal technologies to support work I was doing. Since leaving, I've been able to invest in learning open source technologies, applicable across the dev stack (my prior focus had always been backend). I've also been learning about UX design and expanding my knowledge on the business side. All this comes with the day-to-day work I do as well as from flexibility that allows me to explore outside of work as well.
  • While at Microsoft, I also got caught up in some of the group-think that garnered overconfidence in my skills. I've since gained a clearer picture of both my strengths and weaknesses, including areas both technical and non-technical. There are fewer unknown unknowns and I'm hopeful that I'll have the opportunity to work with some of the amazing people I've met in the past year who have complimentary skill sets.
  • My network has exploded in the past year. This has been partly due to my work and partly due to intentional effort made after realizing how limited my network was. This has led to many benefits, not the least of which is new friends.
  • Over the last year, I've been in a good situation to evaluate what's important to me in a more objective manner than I have in the past. This has resulted in increasing confidence in what I want to do with my life.

I still think Microsoft is a great company, though it has its share of challenges. I can't say with confidence that I'd want to work there again, though I don't regret the time I spent there and I'm also not sure I'd want to work at any large company. Joining Seattle's startup ecosystem was absolutely the right decision for me and every morning I wake up excited about work.

I intentionally cut out some topics I'd like to share, such as what working at Madrona has been like, because I quickly found that I was writing about them at length and that they merit their own posts, so more on that later.

To my many fellow ex-Microsoftees who left around the same time last year (many of whom I've had the pleasure of meeting), happy anniversary!

-----
UPDATE: Stories from others

Here's a great 1-year post from an ex-Amazonian. I had similar plans when leaving Microsoft and have had similar experiences since leaving! Evan Jacobs of ReadWriteHack: My Most Productive Year

Here's a post from a friend who left Microsoft this year to become an entrepreneur. It includes some good reflection on the inner thoughts one has right before making a move like this. Avilay Parikh: Why I left Microsoft

Here's a post from an entrepreneur I recently met who, like my friend above, left Microsoft this year. Othmane Rahmouni: Goodbye Microsoft, Hello Startup World.

Monday, October 21, 2013

The Most Powerful Tool You'll Ever Use

The most powerful tool you'll ever use is storytelling. That's it. Done. You don't need to read on.


If you're still reading, you probably agree and appreciate validation or you disagree and want to find flaws in my reasoning. I'm sure you'll get plenty of both.

Wikipedia defines storytelling as "the conveying of events in words, and images, often by improvisation or embellishment." Although it seems intuitive when pointed out, it's insightful to observe that storytelling happens across cultures. In fact, "humans [inherently] think in narrative structures and most often remember facts in story form." Have you ever noticed how often and how naturally we use story-like analogies to explain complex situaitons? Or how people binge-watch their favorite TV shows?

The problem with Wikipedia's definition of storytelling is that it only states what it is and misses what it does. Stories are used for a variety of purposes. They entertain. They inform. They create bonds. They can be applied for the purposes of good or evil, but they always have a purpose and are most effective when carefully crafted to achieve that purpose.

Stories are incredibly powerful. Every startup that has ever been funded, has received its funding because of a story. Sometimes it's the story the entrepreneur tells and sometimes it's the story the investors tell themselves. Either way, an investor who's willing to commit a significant amount of money to an extremely risky endeavor believes that a series of events that hasn't happened yet is going to happen, and result in a happy ending.

Stories even have remarkable effects on the course of world-history. In 2008, Barack Obama was elected as president of the United States based on a powerful story that millions of Americans believed in; the idea that the American dream still exists and that no matter who we are, we can achieve it. This story wasn't accidental and neither was the success of the campaign.

Any time we interact with others, all the complexities of these interactions emerge. Every day, we repeatedly face the need to influence others. We have to convince people to join our team, we have to convince people to use (and pay for) our products/services, we have to convince people at other companies to partner with us.

And the best way to convince people? By telling great stories, of course!

So, how do great stories come into existence? The short answer is that great stories are intentional and carefully crafted. Think of storytelling as an art that can be enhanced by science. Art, or instinct, places constraints on a world of infinite dimension, making it conceptually manageable. Art "solves" the blank canvas. Then, once we have some idea as to what we want to paint, we can leverage science to optimize the layout and colors for maximum effect.

When we take control of our story and design it to deliver information in a convincing and compelling way, we win the hearts and minds of others. And we take a big step toward achieving our grand vision.

All of this is not to say that telling a great story is easy or that success is guaranteed. It actually takes a lot of effort. However, the most incredible thing about storytelling is that it's a learned skill. Think of it as a super-power you can gain without being bitten by a radioactive spider.

If you want to accomplish great things, start by learning how to tell a great story.

Saturday, October 19, 2013

How to Add a Dial to Your Arduino Project

This post is for hardware hackers interested in adding dials to their projects. It discusses what we learned about rotary encoders and provides info about how to add one to your Arduino project.

For the original timetravel.fm prototype, we used thumbwheel potentiometers (pots for short) as the dials for the radio. While these components worked well for the hackathon, they have a few limitations:
  • They have limited range
  • The mechanics of the component and Arduino limit precision
  • They are generally unattractive
Because the experience of using the device is extremely important to us, we place a lot of value on this element being (1) flexible, (2) pleasurable to use, and (2) attractive. While there are numerous types of pots, including ones that can rotate up to two full turns and allow a knob to be attached, a component called a rotary encoder performs better on each of the metrics that are important to us. Since I hadn't previously heard of a rotary encoder, I started out blindly searching Google using queries like "unlimited turn dial" (which I find humorous in retrospect). Eventually, I discovered the rotary encoder and pieced together what we'd need to experiment with them.

The first thing to note about rotary encoders is that they come in numerous different styles. While browsing the options at my favorite supplier, Digi-Key, it took me a while to figure out what all the features meant (actually, I didn't fully understand until I received my first order of encoders). Looking at an example encoder, some noteworthy characteristics include:
  • Encoder Type: The method with which the encoder determines rotation. The example encoder is mechanical, which is a good choice for basic projects.
  • Output Type: How rotation is encoded in the output. The example encoder uses quadrature, which means the output is represented by out-of-phase waves.
  • Pulses per Revolution: The number of times the output changes per full revolution of the dial. The example encoder will cycle through the output phases 12 times per full turn of the dial.
  • Actuator Type: This contains the diameter of the encoder's dial and the style of shaft. This information will help determine which knobs will fit.
  • Detent: Whether the dial "clicks" or rotates smoothly as you turn it.
  • Built in Switch: Some rotary encoders have a built-in switch that is triggered by pressing down on the shaft.
  • Mounting Type: This indicates how you mount the component onto your device. The example includes "PCB Through Hole", which means it has legs that allow you to lock it into place on the PCB, and "Panel", which mean that it has threaded metal at the bottom of the shaft that allows it to be locked into place on a device using a nut (see the example component).
  • In addition to the above, I'd also recommend looking at the part's datasheet to see the length-wise parameters of the shaft to make sure it fits the dimensions you're looking for and that any knobs you intend to use will fit properly.
To try the encoder out, I wanted to plug it into a solderless breadboard. However, I found that the PCB mounting legs prevented it from fitting. To deal with this, I drilled two small holes in the breadboard and the encoder snapped into place:


With the encoder set up on the breadboard, I was ready to create an Arduino project. I started by writing the following for Arduino UNO R3:
This code warrants some explanation. Two things are key to understanding what's going on. The first is that we are using interrupts to signal that the dial on the encoder is turning. The second is how we interpret the output of the encoder.

To create interrupts, we are using Arduino's attachInterrupt function. Different versions of Arduino work differently with this function. For the UNO, which the above code was written for, only pins 2 and 3 can be used for interrupts. The first parameter to attachInterrupt says which of these are used, meaning a value of 0 maps to pin 2 and a value of 1 maps to pin 3. The second parameter is the function to execute on the interrupt. The third parameter is when to trigger the interrupt. Here, we are asking for an interrupt to be triggered whenever the value of one of the pins changes.

Because we can't be certain about when a context switch might occur, we turn off interrupts before accessing _changeInTicks in our main loop. Before calling an interrupt handler, Arduino disables interrupts, so we don't need to do this in the handler, handleEncoderChange. What this gives us is that when the signal to pin 2 or 3 changes, handleEncoderChange is called.

When handleEncoderChange is called, we determine the rotation of the dial on the rotary encoder. Because the encoder we're using uses quadrature as it's output encoding, the signals to the pin will repeatedly iterate through the following pattern as the dial rotates to the right. When rotated to the left, it will go in reverse.

step 1step 2step 3step 4repeat...
pin100110
pin201100
result0001111000

The logic in handleEncoderChange observes the sequence of values read from the encoder to determine whether the dial is being rotated forward or backward. For several sequences, like 0011, we can't tell which direction the encoder was turning, because it is possible to generate them by rotating the dial in either direction. In testing the example encoder, I occasionally observed such values, which is why we purposely ignore them in the code. At this point, it's worth noting that writing to the serial line (e.g. using Serial.print) in an interrupt handler doesn't always work properly. When I tried doing this, I found that Arduino's serial monitor would occasionally hang.

With this simple program ready to go, we can hook the encoder up to the Arduino.


Encoders are designed to allow a knob to be attached. As mentioned earlier, when looking for a knob, you'll want to make sure it fits the encoder. For this example, we'll use this knob. When selecting a knob, make sure the specs for "shaft size" and "height" match the corresponding values for the shaft of the encoder. To get the precise dimensions, look at the part's datasheet.


It's not obvious from most pictures of knobs, but they typically come with a screw on the side that tightens down to lock onto the shaft of the encoder.


Attaching the knob to the encoder, gives us a nice dial for our project.


One last thing to cover here is the push-button feature of the example encoder. The following code, which can be combined with the previous code, turns on an LED when the encoder shaft is pushed down.
Now, we can connect the encoder button to the Arduino.


I've learned quite a bit of new things about encoders, knobs, and Arduino in figuring all this out. I hope sharing it helps accelerate your learning! Feel free to leave a comment if you have any questions.

Friday, September 6, 2013

10 Lessons From 10 Startup Weekends

If you know me or have read anything from my blog, it's probably abundantly obvious that I love hackathons and am particularly fond of Startup Weekend. Well, on August 18, I wrapped up my 10th Startup Weekend. I have a bunch of half-written blog posts sitting with reflections on my experiences and learning from these various events. However, with the tenth, I thought it would be fun to pick one thing I've learned from each event and do a kitschy 10-things post. There's nothing really novel here, but I think those who have been to Startup Weekend will be able to relate and hopefully those who haven't will be convinced to attend.



1. January 2012, "Rise of the Designer" Theme, Seattle, WA

What's the right size for a team? This was the first time I had ever attended Startup Weekend and the biggest lesson from this event was that a bigger team doesn't necessarily produce better results. The team I joined at this event ended up with 14 members and a leader who, while a great guy, was not ready to manage the challenges that arise when 14 people meeting for the first time and spend 54 hours in a high-pressure environment trying to deliver on a novel vision. The more people on a team, the more opinions there are, meaning the more prepared and willing the leader needs to be to manage it all. The team had some strong personalities that resulted in a lot of unproductive argument. Naturally, team size isn't an issue in isolation. Team productivity is the net of all the unique personalities that comprise it, the structure placed around its operation, and numerous environmental factors. It's important to choose teammates based on criteria that matter to you. Personally, I prioritize people I'd enjoy working with, who are aligned in what they want to achieve, and who have complimentary skills. I look for leadership that is willing to make unpopular decisions and follow through. It's not always comfortable, but it's often required to get things done on a tight timeline.


2. April 2012, "Government" Theme, Seattle, WA

Are you asking the right questions? After my first Startup Weekend experience, I was determined to (1) be part of a moderately-sized team and (2) play a leadership role. Before the initial idea pitches, I canvased the room to gather support for the idea I wanted to work on. Fortunately, things worked out. My idea was selected and I had the opportunity to lead a team. In bringing the team together, I was intentional about keeping it at no more than 6 people with a balanced set of skills. With a solid team in place, I focused my attention on putting customer development to practice. On the upside, I learned a lot about interviewing potential customers. On the downside, I spent way too much time putting together a survey. But I did learn a lot about how to tailor survey questions to produce meaningful data while avoiding inadvertent manipulation of the respondent's responses. The key is to ask behavior-based questions that are indicative of users' pre-existing behaviors. Making sure questions solicit objective responses ensures that we gather facts rather than supposition and speculation. If we must ask a subjective question, it helps to be aware of psychological influences like anchoring, etc. A great book on the topic of psychological influences is Influence: The Psychology of Persuasion


3. May 2012, General Event, Seattle, WA

What's a mentor? At this event, I was again in charge of a survey to collect customer data. However, what I learned this go-around was far different from what I learned at the prior event. To gauge whether the survey content would help achieve our goals, I ran it by several event mentors. Each time I spoke with a mentor, the feedback was essentially to rewrite the entire survey. So after each conversation, I would go back and spent over an hour hour carefully crafting a revision. When I got the same feedback a fourth time, I realized I was spinning in circles and that the information I wanted to capture was pretty well covered by the original rendition of the survey. This was the first time I had experienced "mentor whiplash". When getting feedback from mentors, it's important to remember that mentors are there to give guidance, not instruction (it's good for mentors to remember this too!). We shouldn't necessarily spin on our heels just because someone we deem as credible suggests that we're going down a wrong path. Usually, better decisions come from seeking out feedback from relevant individuals, internalizing their feedback, and making our own decisions.


4. July 2012, "Women's Edition" Theme, Seattle, WA

Have you ever walked in a room and been the only woman/man/adult/child/foreigner/student/whatever? If you haven't, it's an experience I'd recommend. The Women's Edition of Startup Weekend inverted the typical male-to-female participant ratio to encourage and inspire women, who are typically less well-represented at hackathons. For this event, the balance of participant gender was set at about 85% women and 15% men. Although I have long believed in the importance of supporting and being inclusive of minority groups, I don't know that I've ever had an experience that made me more acutely aware of being on the other side of the table. It's one thing to put yourself in that position by choice, for example through intentional selection of friends. It's something else completely when being a minority is entirely outside your control. I still remember the feeling of walking into the room where things were kicking off and instantly being struck by uncertainty, self-awareness, self-doubt, and a wave of other emotions. This was an eye-opening experience that has helped me to empathize with what minorities go through on a daily basis. It's up to everyone to choose how they address diversity and minorities, but at a minimum, I think it's important for everyone to be cognizant of what others experience.


5. September 2012, General Event, Seattle, WA

What do you do when things look dire? I attended this event with a close friend and while we didn't have a particular idea we wanted to work on, we knew we wanted to work together. Most of the ideas that were selected either weren't that appealing to us or ended up with teams to which we didn't think we'd add net value. One of the ideas that was chosen ended up without any team members aside from the person who pitched it. We found the idea somewhat interesting, so we decided to form a small, three-person team. We felt that this team size was an opportunity to get a more realistic experience of what it's like to be a co-founder. Like real founders, we certainly experienced plenty of ups and downs throughout the weekend (of course, all in a safe, low-stakes, low-risk, time-boxed environment). There were multiple times when we'd asked ourselves why we even bothered continuing with the weekend. We even hit one of these troughs around 5 hours before final presentations. But we pushed through, despite the tight deadline and the continual need to tweak or scrap the business model as we got feedback from potential customers. During the final presentation Q&A, one of the judges literally, word-for-word, told us we were "full of shit". But compared to what we'd been through the rest of the weekend, the words didn't phase us for a moment. It was actually great feedback... how can a tiny team possibly deliver on a big vision? Then again, we had persistence on our side.


6. November 2012, General Event, Kirkland, WA

What do you want to achieve? Having worked on a lot of serious projects at previous events, I was eager to work on something (1) fun and (2) hardware-related at this event. I pitched "SlapBot", a robot that slaps you when you send annoying or mundane tweets and Facebook posts. This quickly became ZapBot, which would give an electric jolt instead of a slap. Although the idea didn't get enough votes to officially become a project, there was interest from two other participants, so we formed a 3-person rogue team. The initial intent was purely to be a joke and to have fun, but the novelty of the gadget and the positive response from people we showed shifted the tone of our conversations toward evaluating the concept as a serious business. Unfortunately, this resulted in a final pitch was neither funny nor compelling as a business opportunity. It's important to know your objective, then tailor your actions and train your focus on achieving it. Understand the experience you need to be delivering and deliver on it. Be wary of shiny distractions. I later completely revised the pitch to focus on the humorous side of the concept and presented again in a different context. The second time around, the result was exactly what I had hoped for - lots of laughter and delighted conversation.


7. November 2012, General Event, Seattle, WA

When was the last time you let your hair down? After building a silly device like ZapBot, I was ready to get back to business. I had an idea I thought would be interesting and that might have a business behind it. But then someone jokingly pitched "Cartar", a keytar for jamming in the car. I was hooked. Try as I might, I couldn't get the person who pitched the idea to work on it. So, I did what any good entrepreneur would do. I stole the idea (with his permission) and formed another rogue team. From the first night, the team started dreaming up what the final presentation would look like. We wanted it to be an experience rather than a presentation - something people would remember. I also wanted our team to have a blast working on the project. Keeping those goals front-of-mind through the weekend, both were achieved in spades. I knew it was a success when one of my teammates, who had been to numerous Startup Weekends in the past, told me that this one was the most fun he'd ever had. I knew we'd delivered on the presentation (1) when Rich Barton, a special guest, looked up from his phone to watch our presentation, and (2) when the audience gave us a roaring ovation, the longest I've yet seen at a Startup Weekend. I wouldn't say there was a great business case for the product, but I will say with confidence that we truly captured the potential of what the Startup Weekend experience can be. And all because we focused on having a great time.


8. January 2013, Special University of Washington Event, Seattle, WA

What is a leader and what do they do? At this event, I joined a team comprised entirely of students, non of whom had been to a Startup Weekend before or had any industry or entrepreneurial experience. To be clear, there's a lot of potential for mischaracterization in that statement. These students were incredible. I've met professional programmers who can't program as well as the budding engineers who were on this team. I've also met business people who get locked up in over-analysis instead of making things happen, the way the other members of this team did. But experience is experience and that was the one thing they were lacking. It was clear very early on that this was leading to some decisions that would take the team down an unproductive path. At that point, it would have been easy to have stepped in and forcefully grabbed the reins to pull things in a different direction. However, this was one case in which it was especially important not to see anyone on the team discouraged. So instead of being direct, I tried encouraging discussion and helped guide conversations down a reasoned path, advocating the collection of data where knowledge gaps existed. This approach worked well as the team didn't hit the bumps and pitfalls first-time Startup Weekenders usually go through. More importantly, everyone left with a solid experience under their belts and eager to participate again in the future.


9. April 2013, General Event, Portland, OR

What are the rules about rules? Once again, I went rogue. I knew I wanted to work on something hardware related, but the idea I pitched didn't get picked and neither did the one other hardware project I was interested in (there were a total of three hardware ideas pitched). At this point, I'd had some experience going rogue before, so this time I had a pretty good idea of what I was doing. After it was obvious that my idea and the other one I was interested in weren't going to get enough votes to be selected, I grabbed the other person and we recruited two more people with complementary skills. The event organizers were surprised when we registered our team with an idea that hadn't been officially selected, but nothing really forbade this. With warnings of risk and votes of no-confidence, we proceeded with the usual paces, identifying and validating a promising market opportunity, building a solid prototype, and bringing it together with a strong presentation. This might have happened if we had gone along with what we were "supposed" to do, but we were all really glad we took the route we did. Given the choice of betting on luck or betting on myself, I'd choose myself. Rules are designed as constraints, but they're uni-dimensional in a multi-dimensional world. Shifting one's view opens up new possibilities that aren't immediately obvious.


10. August 2013, General Event, Seattle, WA

How much does team composition really matter? Many of the most important lessons I've learned at the various Startup Weekends I've participated in have to do with team (it just so happens that the most important lessons I've learn as a Startup Weekend organizer have also been team-related). At the most recent Startup Weekend I participated in, I had the great fortune of connected with someone who's skills complemented my own in an it's-too-good-to-be-true kind of way. As we talked about our areas of interest and backgrounds, lightening struck, followed by immediate clarity. There was no doubt that we were the basis of an ideal team to work on one of the projects we had in mind. While other participants weren't particularly interested in working on the idea, we convinced two talented friends of mine, who were actually simultaneously event organizers, to join the team. The result was an incredibly productive weekend that ran like clockwork. Everyone pretty much knew exactly what to do and got right to it. I think we were all pretty amazed with what we were able to accomplish in such a short timespan, but in retrospect it made sense. We were set up for success from the outset by forming a well-balanced team.



It's been a long journey since my first Startup Weekend, but looking back, I couldn't be more pleased with the amazing friends I've made, the knowledge I've gained, and the seriously cool stuff I've helped build. Startup Weekend doesn't begin to compare to actually founding and running a startup, but there's no question that the experiences it's offered will be a major contributor to any success I'm fortunate enough to have.

There are a ton of people to thank for all these incredible experiences, but the list would go on forever. You know who you are - thank you all for teaching me so much!