As I stepped into the Perkins Coie conference room in downtown Seattle, I felt a sudden rush of self-conscientiousness. I was in the minority in a room with about 85% women. This was Startup Weekend Seattle: Women's Edition, a special Startup Weekend event focused on women in technology and entrepreneurship and I was one of a small number of men at this event. I immediately thought "this must be what it feels like for women who come to the majority of startup events that are predominantly male." I normally have no problem engaging in conversation with entrepreneurs and engineers, but this felt different. My mind flooded with questions. Would I be the annoying guy who came to participate in this women's event? Would I say something stupid and embarrass myself?
Walking through the room, I eased up a bit when I ran into someone I had met in the street only a few minutes prior, where I had helped her get a handle on parking in Seattle. She was a business professor teaching in southern Asia, who had just arrived from a Startup Weekend event in Australia. It was fascinating to hear about her experience teaching outside the United States and her thoughts about entrepreneurship. I moved on, a bit more comfortable with myself, shortly joining a conversation with a pair of women who had been exchanging backgrounds. I tried to learn more about them and told them a bit about myself. And with that, my fears came true - complete disinterest in speaking with me. One of the women excused herself right away and the other was fairly quick to distance herself conversationally. It's funny how this would go nearly unnoticed in the circumstances I'm used to, but how in this situation it felt incredibly acute. Fortunately, I then ran into a friend, Irena Menn, with whom conversation helped me to regain my composure.
Transitioning into the event kickoff, we all took seats as Julie Sandler of Madrona Vetnures and Shauna Causey of Decide.com, introduced us to the event and laid out what to expect from the weekend. Dalia Al Said followed with an inspiring story of her involvement in entrepreneurship in Egypt and how she organized the country's first-ever Startup Weekend. Next came Dawn Lepore, CEO of drugstore.com and one of the top businesswomen in America. These were remarkable speakers and I hope we'll continue to see such exceptional female leaders inspiring us in this way.
After hearing some fantastic pitches, we broke out and formed teams. With discussions ensuing, I quickly noticed that the style of communication and interaction was markedly different from what I was used to. Rather than giving quick bios and jumping into tasks involved in putting the project together, the team and I spent more time getting to know one another through casual conversation. I found it interesting how conscientious I was about this and how deliberately I had to resist the urge to push things forward prematurely.
The team and I shared some incredible experiences and it was really amazing getting to know my five female partners over the course of the weekend. Highlights for me included going out to the Pike Place Market to interview people in our target market, trekking around town for hours looking for a color inkjet printer to make iron-on t-shirts, seeing the pitch deck come together, and really getting to know the others over lunch. The exceptional ladies I worked with included Adriana Moscatelli, Bonnie Mattson, Karmin Mauritz, Hema Natarajan, and Nnenna John. Each was smart, fun to work with, and brought valuable unique skills and experience to the team. And most fortunate for me, they were completely accepting and kind to the "odd man out".
Something that always shines during Startup Weekend events is the mentors, and this was no exception. In fact, I would say the things were really stepped up a notch for this event with lots of leaders and great role models coming out to show their support. Kate Matsudaira made a critical contribution, giving us some early advice as the first mentor we talked to and setting us down the right path from the outset. We also got valuable advice from Janis Machala, Susan Sigl, and Jean Brittingham. And special shout-outs go to Bob Crimmins and Julie Sandler, each of whom spoke with us multiple times throughout the weekend to provide feedback and to help us refine our pitch.
As the weekend wrapped up, Adriana delivered a flawless pitch despite fretting over it during the run-up to our allotted time. As we waited for the results, the team was beaming with anticipation. At that moment, I distinctly recalled my first couple of Startup Weekend events and the uncontrollable excitement right before hearing who the judges had deemed "winners". I had decided to participate in this event to experience the diversity and to meet people who I hadn't had to opportunity to meet at typical startup and tech events. Although we didn't end up placing among the top three, I got so much more out of the weekend, even with the high expectations I had going into it, that I was nothing less than ecstatic. Though my teammates were disappointed with the results, we nonetheless regrouped in a mini-celebration, donning our custom-made t-shirts and sharing hugs before heading home for some much-needed sleep.
Monday, August 27, 2012
Wednesday, July 4, 2012
Lean Life
With all the thinking I've been doing about the lean methodology, I had a very interesting thought about life.
Consider that the "runway" a startup has is now defined as the number of build-measure-learn cycles founders can iterate through before having to give up on the company. The faster the iterations, the longer a company's runway. Thus, we are no longer defining a company's runway as time-dependent, but instead as cycle-dependent. This means founders with little time can still have a decent runway. It also means that founders with a lot of time can have very short runways. It all depends on the way in which they address progression.
So what if we stop thinking about life as being defined by time? What if we start thinking in terms of act-assess-learn cycles? Age would no longer matter and what we really care about is the number of times we can accomplish something and learn from it. It seems reasonable to ask what happens to the long, ambitious life goals? Well, just as build-measure-learn doesn't replace a company's vision, act-assess-learn doesn't replace having short and long-term goals. In fact, it makes it more likely that we'll reach our grand goals since we are taking short, measurable steps that result in verifiable progress and help push a flywheel that builds momentum off our experience.
In the act-assess-learn model, maximizing the number of cycles maximizes the length of our lives. What exactly does this mean? It means we have more control over our lives than we did when we measured them purely in units of time. It means we have to focus more on value and less on a ticking clock. It means we maximize the satisfaction we get out of life, satisfaction of course depending on the individual's values.
Consider that the "runway" a startup has is now defined as the number of build-measure-learn cycles founders can iterate through before having to give up on the company. The faster the iterations, the longer a company's runway. Thus, we are no longer defining a company's runway as time-dependent, but instead as cycle-dependent. This means founders with little time can still have a decent runway. It also means that founders with a lot of time can have very short runways. It all depends on the way in which they address progression.
So what if we stop thinking about life as being defined by time? What if we start thinking in terms of act-assess-learn cycles? Age would no longer matter and what we really care about is the number of times we can accomplish something and learn from it. It seems reasonable to ask what happens to the long, ambitious life goals? Well, just as build-measure-learn doesn't replace a company's vision, act-assess-learn doesn't replace having short and long-term goals. In fact, it makes it more likely that we'll reach our grand goals since we are taking short, measurable steps that result in verifiable progress and help push a flywheel that builds momentum off our experience.
In the act-assess-learn model, maximizing the number of cycles maximizes the length of our lives. What exactly does this mean? It means we have more control over our lives than we did when we measured them purely in units of time. It means we have to focus more on value and less on a ticking clock. It means we maximize the satisfaction we get out of life, satisfaction of course depending on the individual's values.
Monday, July 2, 2012
Lean Startup Machine Day 3
Strap yourself in... this is a bumpy one.
Yesterday night, we deployed a website late in the evening to test our hypothesis that experienced developers would sign up for an event where they'd work with startups on weekend-long projects to give both parties a chance to better evaluate one another. We wanted to try to get 20 experienced developers to sign up for the event by 10 am. The site was up and running quickly and we sought ways to promote it. Then came a huge mistake that we won't ever repeat and which we will share with others so they don't repeat it. After a verbal sign-off from someone we thought was associated with a particular brand, we added that brand's logo to our site to entice potential participants to sign up based on brand recognition. Looking back, it's hard to say why didn't further checks our facts before pulling the trigger. We really got caught up in the moment and let it blind us.
As today morning came around, we ramped up our marketing effort. We promoted as much as we could with a goal of hitting our target. In the end, we didn't make the bar and went back to analyze our next move. At this point, we realized that we had skipped a step by not interviewing developers first and finding out what their needs were. So our next hypothesis to test was that developers wanted to learn about and work at startups. But that's not nearly as noteworthy as what happened next.
I believe around 10:30am, we received a cease and desist call from the legal counsel of the company whose logo we had used. We immediately took the site down and started working on an apology to the involved parties. We knew we had messed up and wanted to do our best to undo any potential harm we had done to a brand we love. The right thing to do was to be open, honest, and sincere.
The ironic thing is that we probably would have had success if we had reached out to the company or a similar one through official channels to request a partnership. The test was also invalid since the result was driven by something we didn't have proper authorization to use and that would be difficult to replicate.
Before doing something, ask yourself whether you have checked all the facts appropriately. Use your good judgement and don't let your excitement or eagerness allow you to jump the gun. It's really just common sense.
This was a major failure, but we certainly learned from it. One thing I can assure you is that we will never make this mistake again. Our future judgements will be much better and we will share this experience with others to make sure they can learn from our mistake and won't repeat it.
Our sincerest apologies to everyone involved.
Yesterday night, we deployed a website late in the evening to test our hypothesis that experienced developers would sign up for an event where they'd work with startups on weekend-long projects to give both parties a chance to better evaluate one another. We wanted to try to get 20 experienced developers to sign up for the event by 10 am. The site was up and running quickly and we sought ways to promote it. Then came a huge mistake that we won't ever repeat and which we will share with others so they don't repeat it. After a verbal sign-off from someone we thought was associated with a particular brand, we added that brand's logo to our site to entice potential participants to sign up based on brand recognition. Looking back, it's hard to say why didn't further checks our facts before pulling the trigger. We really got caught up in the moment and let it blind us.
As today morning came around, we ramped up our marketing effort. We promoted as much as we could with a goal of hitting our target. In the end, we didn't make the bar and went back to analyze our next move. At this point, we realized that we had skipped a step by not interviewing developers first and finding out what their needs were. So our next hypothesis to test was that developers wanted to learn about and work at startups. But that's not nearly as noteworthy as what happened next.
I believe around 10:30am, we received a cease and desist call from the legal counsel of the company whose logo we had used. We immediately took the site down and started working on an apology to the involved parties. We knew we had messed up and wanted to do our best to undo any potential harm we had done to a brand we love. The right thing to do was to be open, honest, and sincere.
The ironic thing is that we probably would have had success if we had reached out to the company or a similar one through official channels to request a partnership. The test was also invalid since the result was driven by something we didn't have proper authorization to use and that would be difficult to replicate.
Before doing something, ask yourself whether you have checked all the facts appropriately. Use your good judgement and don't let your excitement or eagerness allow you to jump the gun. It's really just common sense.
This was a major failure, but we certainly learned from it. One thing I can assure you is that we will never make this mistake again. Our future judgements will be much better and we will share this experience with others to make sure they can learn from our mistake and won't repeat it.
Our sincerest apologies to everyone involved.
Sunday, July 1, 2012
Lean Startup Machine Day 2
Day 2 of Learn Startup Machine was another learning-packed day. Seriously, the mentorship is just outstanding. My team got an early start reviewing our learning hypothesis canvas (I really need to find a picture to link too...), our riskiest assumption, our validation metric, etc. After that, we immediately went to work making phone calls and doing a few in-person interviews with startups who hire software developers.
In our interviews, we tried to keep the conversations high-level so the interviewee could surface the issues that were really important to them. We generally started by asking whether they had ever made a hiring decision that they regretted later. It was really interesting to see the diversity of responses here. We really thought this would be a sure-fire "yes" all around. However, we got a lot of negative responses early on. A number of folks responded that they had never regretted a hire and demonstrated that they had extremely tight filters. Our criteria for passing validation was that 6 of 10 hiring managers had to indicate that culture was a top problem in hiring. We ended up with 11 interviews and 4 negatives, so the assumption was validated, but barely.
Although our assumption had been validated, we had to make adjustments to our hypothesis since we started with a very vague notion of what we were after and after our interviews, we had a ton of information. In the commonalities among the many interviews, we found that startups hiring technical talent have trouble ensuring that the candidates that fill their pipelines are high quality. We modified our canvas, got some feedback, and started on our next experiment. I can't share the next experiment yet because it would ruin it. However, I'll post more info later.
Before wrapping up, I have to say that I've been really pleased with the talks. Adam Berk is the lead on running everything and has been doing a stupendous job. He's given us a ton of feedback and kept the 9 teams on track. John Sechrest, who everybody loves, has also been around the entire time giving great advice at every opportunity. Patrick Vlaskovitz, Clint Nelson, Irina Menn, Bob Crimmins, and Charlie Kindel all gave really informative talks and spent time mentoring. All these folks supporting Lean Startup Machine are what makes Seattle an awesome place to start a company and they all have my deep appreciation for their commitment to the community.
Tomorrow is the last day and I'm eager to get to it! But first some much needed sleep...
In our interviews, we tried to keep the conversations high-level so the interviewee could surface the issues that were really important to them. We generally started by asking whether they had ever made a hiring decision that they regretted later. It was really interesting to see the diversity of responses here. We really thought this would be a sure-fire "yes" all around. However, we got a lot of negative responses early on. A number of folks responded that they had never regretted a hire and demonstrated that they had extremely tight filters. Our criteria for passing validation was that 6 of 10 hiring managers had to indicate that culture was a top problem in hiring. We ended up with 11 interviews and 4 negatives, so the assumption was validated, but barely.
Although our assumption had been validated, we had to make adjustments to our hypothesis since we started with a very vague notion of what we were after and after our interviews, we had a ton of information. In the commonalities among the many interviews, we found that startups hiring technical talent have trouble ensuring that the candidates that fill their pipelines are high quality. We modified our canvas, got some feedback, and started on our next experiment. I can't share the next experiment yet because it would ruin it. However, I'll post more info later.
Before wrapping up, I have to say that I've been really pleased with the talks. Adam Berk is the lead on running everything and has been doing a stupendous job. He's given us a ton of feedback and kept the 9 teams on track. John Sechrest, who everybody loves, has also been around the entire time giving great advice at every opportunity. Patrick Vlaskovitz, Clint Nelson, Irina Menn, Bob Crimmins, and Charlie Kindel all gave really informative talks and spent time mentoring. All these folks supporting Lean Startup Machine are what makes Seattle an awesome place to start a company and they all have my deep appreciation for their commitment to the community.
Tomorrow is the last day and I'm eager to get to it! But first some much needed sleep...
Saturday, June 30, 2012
Lean Startup Machine Day 1
I might just be addicted to hackathons. It seems I may have a bent towards building businesses over the course of a weekend. The latest is Lean Startup Machine, which focuses on early-stage customer development. Basically, I wasn't planning on going until Justin Wilcox, the brilliant guy behind the Customer Dev Labs blog convinced me. After the first night, I can say I am incredibly glad I am attending.
Earlier on I had thought Lean Startup Machine was going to be similar to Startup Weekend, which I've attended several times. However, I've found it to be quite different and a whole new learning experience. First, there's more structure. This is a huge value. We are given a framework to guide us and experienced mentors actively engage with us when we get stuck. The mentor-to-participant ratio is quite high, which is really fantastic. Second, it focuses on earlier stages of the process of customer development. The process is generally aided by the "Validated Learning Canvas", a great tool for honing in on key assumptions and testing them. Third... well, I could go one, but that's enough for now. Check out the website for more info.
So the night started out with some networking, which was fun since I met a number of new people and connected with a bunch of people I know from Seattle's startup scene. Shortly after an intro to the weekend, we jumped into pitches. I had planned to pitch since I will never be satisfied with my public speaking skills, but I hadn't put a lot of thought into what I wanted to go after. In the end, I decided to pitch a problem that really frustrates me - the fact that it's impossible to know what it's like to work with someone until you've worked with them.
To my surprise, this idea was picked as one of 5 that teams would form around for the weekend (there were also 4 pre-formed teams from the recent Angel Hack event). Actually, it was the problem that was picked since I really just presented the problem and didn't try to identify a solution. Then team formation kicked off and I was really excited when Justin and a good friend, Anupam, wanted to team up to work on this. Two new friends, Jim and Anthony, also joined. We had also had Arun Kumar, founder and CEO of Kerika and an avid member of TiE, join us, but after being told that there was a strict 5-person limit on team size, Arun generously volunteered to switch to a smaller team.
We spent the remainder of our time ramping up for our initial tests using the Validated Learning Canvas and even got in a few interviews with folks around the room. This team works really well together and I'm looking forward to learning and working with them throughout the weekend! I feel incredibly fortunate to be a part of this awesome group!
Earlier on I had thought Lean Startup Machine was going to be similar to Startup Weekend, which I've attended several times. However, I've found it to be quite different and a whole new learning experience. First, there's more structure. This is a huge value. We are given a framework to guide us and experienced mentors actively engage with us when we get stuck. The mentor-to-participant ratio is quite high, which is really fantastic. Second, it focuses on earlier stages of the process of customer development. The process is generally aided by the "Validated Learning Canvas", a great tool for honing in on key assumptions and testing them. Third... well, I could go one, but that's enough for now. Check out the website for more info.
So the night started out with some networking, which was fun since I met a number of new people and connected with a bunch of people I know from Seattle's startup scene. Shortly after an intro to the weekend, we jumped into pitches. I had planned to pitch since I will never be satisfied with my public speaking skills, but I hadn't put a lot of thought into what I wanted to go after. In the end, I decided to pitch a problem that really frustrates me - the fact that it's impossible to know what it's like to work with someone until you've worked with them.
To my surprise, this idea was picked as one of 5 that teams would form around for the weekend (there were also 4 pre-formed teams from the recent Angel Hack event). Actually, it was the problem that was picked since I really just presented the problem and didn't try to identify a solution. Then team formation kicked off and I was really excited when Justin and a good friend, Anupam, wanted to team up to work on this. Two new friends, Jim and Anthony, also joined. We had also had Arun Kumar, founder and CEO of Kerika and an avid member of TiE, join us, but after being told that there was a strict 5-person limit on team size, Arun generously volunteered to switch to a smaller team.
We spent the remainder of our time ramping up for our initial tests using the Validated Learning Canvas and even got in a few interviews with folks around the room. This team works really well together and I'm looking forward to learning and working with them throughout the weekend! I feel incredibly fortunate to be a part of this awesome group!
Sunday, May 20, 2012
Startup Weekend Seattle Day 3
Today was the final day of Startup Weekend and we dove right in, furiously researching our competition and doing market sizing analysis. The site was coming together very nicely and much of the day was spent working out bugs. Because the site was so far along, we had time to get some feedback from a designer on another team, which helped improve the look.
Since we had to prepare for pitches we ended up spending a lot of time putting the pitch deck together. This was a major challenge. Everyone had a different idea of what it should look like and the truth was that there were too many cooks in the kitchen. As the deck went back and forth and became more and more discontinuous, I became more and more frustrated with the direction things were going. Finally, I took a step back and said just one of us needs to own the deck and the others should be constrained to only giving feedback. The owner would be in charge of deciding whether and how to integrate feedback and would have the option of leaving it out. I didn't care whether this person would be me or someone else. I just wanted us to have the right information and to present a consistent story that flowed well. Cy took the lead on this and the rest of us continued working on gathering supporting data to include as well as giving feedback as the various slides came together.
I had a pleasant surprise about halfway through the day when I was talking with someone from another team. The team had started out building "a network for the 1%" and had pivoted into the exact idea I had pitched on the first night. I was glad to see someone working on this problem.
As pitches and judging kicked off, things got started with a great pitch from a 6-year-old for washable stickers. It's amazing how confident he was. When I was that age, I was incredibly shy. I still am, to be honest, but have gradually developed my confidence over time. I was super impressed and excited to see this future superstar entrepreneur.
Our pitch went great. The anti-climatic conclusion is that we didn't place in the top three. However, we did get great feedback from the judges afterwards. They liked the idea, but felt that there were technical challenges that were critical to the success of the business that we didn't solve. They admitted that it probably wouldn't have been possible to have solved them in the course of a weekend, but that's just how judging these kinds of things goes. Something else they felt came up short was that others had attempted to do what we were doing in the past and had failed. They felt we hadn't made a big enough leap to have a shot at escaping the same fate.
All in all, another great weekend of learning! While I'm sure I'll attend more Startup Weekends in the future, I'm really itching to do something over a longer duration where I can get more depth of experience and see the project through to growth or termination.
Since we had to prepare for pitches we ended up spending a lot of time putting the pitch deck together. This was a major challenge. Everyone had a different idea of what it should look like and the truth was that there were too many cooks in the kitchen. As the deck went back and forth and became more and more discontinuous, I became more and more frustrated with the direction things were going. Finally, I took a step back and said just one of us needs to own the deck and the others should be constrained to only giving feedback. The owner would be in charge of deciding whether and how to integrate feedback and would have the option of leaving it out. I didn't care whether this person would be me or someone else. I just wanted us to have the right information and to present a consistent story that flowed well. Cy took the lead on this and the rest of us continued working on gathering supporting data to include as well as giving feedback as the various slides came together.
I had a pleasant surprise about halfway through the day when I was talking with someone from another team. The team had started out building "a network for the 1%" and had pivoted into the exact idea I had pitched on the first night. I was glad to see someone working on this problem.
As pitches and judging kicked off, things got started with a great pitch from a 6-year-old for washable stickers. It's amazing how confident he was. When I was that age, I was incredibly shy. I still am, to be honest, but have gradually developed my confidence over time. I was super impressed and excited to see this future superstar entrepreneur.
Our pitch went great. The anti-climatic conclusion is that we didn't place in the top three. However, we did get great feedback from the judges afterwards. They liked the idea, but felt that there were technical challenges that were critical to the success of the business that we didn't solve. They admitted that it probably wouldn't have been possible to have solved them in the course of a weekend, but that's just how judging these kinds of things goes. Something else they felt came up short was that others had attempted to do what we were doing in the past and had failed. They felt we hadn't made a big enough leap to have a shot at escaping the same fate.
All in all, another great weekend of learning! While I'm sure I'll attend more Startup Weekends in the future, I'm really itching to do something over a longer duration where I can get more depth of experience and see the project through to growth or termination.
Startup Weekend Seattle Day 2
Today I got a shotgun lesson in surveying potential customers. Last startup weekend, my team and I blasted friends and family with requests for survey responses. This resulted in around 40 responses. My goal this time around was to increase the number of responses by a significant amount, do a better job validating the assumptions in our business model, and avoid spamming friends.
To start out, we took a close look at the various elements of our business model and identified the key assumptions that enabled the business. Based on these, we clarified what we wanted to learn from our study, came up with a set of questions, and created a Google Form to capture the information. As we went back over our initial set of questions, we felt they were too complicated and that the amount of mental energy spent answering them would cause participants to disengage before completing the survey.
After modifying the surveys, we got feedback from the Startup Weekend mentors. We spent some one-on-one time with them walking through the survey and looking for feedback on the questions that were being asked. Interestingly, it was difficult to get this kind of feedback because we found that once someone started reading through the survey, they'd jump into responding to it and it took significant focus to keep the conversation on track and ferret out opinions of the positives and negatives about the questions and structure of the survey itself.
Here's a big lesson we learned. Every mentor we spoke with gave different opinions, frequently with advice that was contradictory to what other mentors had advised. It seems so simple and obvious to say that everyone has a unique opinion, but it's different to actually experience receiving contrary suggestions from smart, experienced practitioners who are trying to help you. As has been said many times elsewhere, it's important to apply the right advice to the right situation and to make one's own decisions. Aside from our own revisions, we additionally revised our survey 3 times based on mentor feedback. After the third time, we took a step back and realized that we had just been churning without making much real progress. What is really important is to understand the feedback mentors are offering and the reasoning behind it. This knowledge can then be applied to the task at hand.
After this realization, we tweaked the survey one last time, and were satisfied that it would help gather the knowledge we sought. Once finally ready, we sent the survey out using Amazon's Mechanical Turk. This was highly effective and at about 5 cents per question, we filled our initial round of 100 responses in about 30 minutes. At this speed, we realized that we had overpaid, but all-in-all it wasn't too expensive anyways. We sought an additional 100 responses and tried pricing them at about 3 cents per question. This worked as well, but took somewhere between 6x and 8x the amount of time to get the same number of responses.
While all of this survey-related learning was going on, two teammates did an amazing job hacking together a prototype through the course of the day using Twitter Bootstrap and CodeIgniter. They actually got a functional site up an running before we wrapped up for the night.
With all our feedback and a functional prototype, things are looking promising!
To start out, we took a close look at the various elements of our business model and identified the key assumptions that enabled the business. Based on these, we clarified what we wanted to learn from our study, came up with a set of questions, and created a Google Form to capture the information. As we went back over our initial set of questions, we felt they were too complicated and that the amount of mental energy spent answering them would cause participants to disengage before completing the survey.
After modifying the surveys, we got feedback from the Startup Weekend mentors. We spent some one-on-one time with them walking through the survey and looking for feedback on the questions that were being asked. Interestingly, it was difficult to get this kind of feedback because we found that once someone started reading through the survey, they'd jump into responding to it and it took significant focus to keep the conversation on track and ferret out opinions of the positives and negatives about the questions and structure of the survey itself.
Here's a big lesson we learned. Every mentor we spoke with gave different opinions, frequently with advice that was contradictory to what other mentors had advised. It seems so simple and obvious to say that everyone has a unique opinion, but it's different to actually experience receiving contrary suggestions from smart, experienced practitioners who are trying to help you. As has been said many times elsewhere, it's important to apply the right advice to the right situation and to make one's own decisions. Aside from our own revisions, we additionally revised our survey 3 times based on mentor feedback. After the third time, we took a step back and realized that we had just been churning without making much real progress. What is really important is to understand the feedback mentors are offering and the reasoning behind it. This knowledge can then be applied to the task at hand.
After this realization, we tweaked the survey one last time, and were satisfied that it would help gather the knowledge we sought. Once finally ready, we sent the survey out using Amazon's Mechanical Turk. This was highly effective and at about 5 cents per question, we filled our initial round of 100 responses in about 30 minutes. At this speed, we realized that we had overpaid, but all-in-all it wasn't too expensive anyways. We sought an additional 100 responses and tried pricing them at about 3 cents per question. This worked as well, but took somewhere between 6x and 8x the amount of time to get the same number of responses.
While all of this survey-related learning was going on, two teammates did an amazing job hacking together a prototype through the course of the day using Twitter Bootstrap and CodeIgniter. They actually got a functional site up an running before we wrapped up for the night.
With all our feedback and a functional prototype, things are looking promising!
Saturday, May 19, 2012
Startup Weekend Seattle Day 1
I'm back at Startup Weekend again! This is my third event and as always, I'm super excited.
Having been to a few events in the past and being moderately well tuned into the startup community, I came into this event seeing a lot of familiar faces. As I got to meet a number of the participants, I was surprised to find that perhaps up to 50% of them work at Microsoft. In general, this wouldn't be a surprise around the Puget Sounds area, but when it comes to startup events, including the last two Startup Weekends I attended, I typically feel like the number is closer to somewhere between 10% and 20%. There probably isn't a lot to read into in that, but who knows.
As usual, I pitched and idea, but this time I only got two votes, one of which was mine. The problem I wanted to solve was the difficulty in determining whether a group of people are likely to work well together. My initial idea was to create a tool that could tell a person how well they'd fit in a particular team and for the team, how well the incoming person would fit them. It's just too hard to tell what it's like working with a group of people until you've actually worked with them. In general, the ideas that got most votes seemed to be the ones that addressed problems a lot of people in the room faced, were using exciting new technologies, built off of popular trends, or where the presenter had some wacky idea and did a great job presenting it.
After my idea was removed from the selection process, I connected with team whose idea was "10pictures," a product that showed 10 pictures from a person in the highest definition possible and as large as possible. I felt like there was a lot of potential in the possibility of it becoming a social platform and with the Twitter and Facebook overload was excited about the constraint on content. Aside from that, the team lead was a pretty cool guy, who seemed like he'd be fun to work with.
As the team filled out, it grew to over 10 people. The team members generally had strong opinions of how the product should look, overconfidence in what they could achieve in the course of the weekend, and were completely focused on the product vision rather than the business. I imagine they'll build something cool over the course of the weekend, but it's not the experience I'm looking for. It largely reminded me of my experience at the first Startup Weekend I attended. I learned a lot from that experience, but wouldn't repeat it.
As I grew increasingly concerned with my fit on the team, I decided to go check out some of the other teams around the room. I decided to focus on finding out what some of the smaller teams were working on. I quickly synced up with a team of four, comprised of people I had already been interested in collaborating with. As I talked with them, I become really comfortable and found that I meshed really well with them. The idea they were working on was pitched as a site where people could submit startup ideas and vote on them. Based on the pitch and the large amount of potential competition in the space, I wasn't terribly excited about the idea at first. What really sold me though was the awesome team. These guys were really easy to talk to, were already learning from one another, and had already started making some progress on the idea. Regardless of whether the the idea turns into something that might work as a business, I figured it would probably be a fun thing to work on.
After discussing the business model a bit, I felt like the ideas was more interesting and had some potential. I'm really looking forward to getting to know the people on this team better and building something with them this weekend!
Having been to a few events in the past and being moderately well tuned into the startup community, I came into this event seeing a lot of familiar faces. As I got to meet a number of the participants, I was surprised to find that perhaps up to 50% of them work at Microsoft. In general, this wouldn't be a surprise around the Puget Sounds area, but when it comes to startup events, including the last two Startup Weekends I attended, I typically feel like the number is closer to somewhere between 10% and 20%. There probably isn't a lot to read into in that, but who knows.
As usual, I pitched and idea, but this time I only got two votes, one of which was mine. The problem I wanted to solve was the difficulty in determining whether a group of people are likely to work well together. My initial idea was to create a tool that could tell a person how well they'd fit in a particular team and for the team, how well the incoming person would fit them. It's just too hard to tell what it's like working with a group of people until you've actually worked with them. In general, the ideas that got most votes seemed to be the ones that addressed problems a lot of people in the room faced, were using exciting new technologies, built off of popular trends, or where the presenter had some wacky idea and did a great job presenting it.
After my idea was removed from the selection process, I connected with team whose idea was "10pictures," a product that showed 10 pictures from a person in the highest definition possible and as large as possible. I felt like there was a lot of potential in the possibility of it becoming a social platform and with the Twitter and Facebook overload was excited about the constraint on content. Aside from that, the team lead was a pretty cool guy, who seemed like he'd be fun to work with.
As the team filled out, it grew to over 10 people. The team members generally had strong opinions of how the product should look, overconfidence in what they could achieve in the course of the weekend, and were completely focused on the product vision rather than the business. I imagine they'll build something cool over the course of the weekend, but it's not the experience I'm looking for. It largely reminded me of my experience at the first Startup Weekend I attended. I learned a lot from that experience, but wouldn't repeat it.
As I grew increasingly concerned with my fit on the team, I decided to go check out some of the other teams around the room. I decided to focus on finding out what some of the smaller teams were working on. I quickly synced up with a team of four, comprised of people I had already been interested in collaborating with. As I talked with them, I become really comfortable and found that I meshed really well with them. The idea they were working on was pitched as a site where people could submit startup ideas and vote on them. Based on the pitch and the large amount of potential competition in the space, I wasn't terribly excited about the idea at first. What really sold me though was the awesome team. These guys were really easy to talk to, were already learning from one another, and had already started making some progress on the idea. Regardless of whether the the idea turns into something that might work as a business, I figured it would probably be a fun thing to work on.
After discussing the business model a bit, I felt like the ideas was more interesting and had some potential. I'm really looking forward to getting to know the people on this team better and building something with them this weekend!
Monday, April 30, 2012
Seattle Government Startup Weekend
This weekend was another Startup Weekend. This time, the event had a government theme. The idea was to build a company that would rely on government datasets and serve the community well.
When I arrived Friday evening, there were a few people I recognized, but many more who I didn't. I think the theme of this event drew a different group of people than I normally interact with at startup events. I was certainly pleased with the opportunity to meet and converse with new people. I was also pleasantly surprised to run into Bharat Shyam, who I had known from when I worked on Windows Azure. It turned out he was one of the judges of the event, which is fitting given his role as CTO of Washington state and his involvement with startups.
Soon enough, the idea pitches kicked off. As usual, lots of interesting ideas. I was really excited about some of them as I'd love to see more projects and services that benefit our communities. The idea I pitched was a Kickstarter for community projects where people could contribute money or volunteer hours to make something happen in their community. One of the funnier ideas, but intriguing none-the-less was a tracking system to see where someone's poo goes as it leaves the bathroom and travels through city infrastructure to processing and eventual disposal.
After the idea pitches, we had some time to mingle and vote on ideas. I walked around and talked to a few people whose ideas I liked and also to a few folks interested in my idea. Some of the ideas got votes right away, but mine was slow going. But in the end, it just barely made the cutoff in the top ideas and so it became one of the team projects.
During the mingling time, I focused my time on conversations with people who seemed collaborative. I tried to drop out of conversations quickly when people were only interested in talking about themselves (i.e. had no interest in listening), talked condescendingly of others, or seemed acerbic. This seems to have paid off because once team formation happened, I was really fortunate to have collaborative people gather around the idea, wanting to work together. Another element that made me feel particularly lucky was to have 3 designers on the team.
The first night wrapped up with brainstorming. We all gathered around, discussed the problem and the idea and hacked at the idea until we felt we had a plausible business model (using the business model canvas). This team was seriously awesome to work with. Everyone got a long really well, where several other teams seemed to be having tension as early as the first night.
Saturday was a really full day. We got feedback from mentors and I ended up spending a large portion of my time putting a survey together. This was the first time I really worked on making a survey and found it more difficult than I had thought it would be. How does one come up with questions that won't lead the answerer's responses? How does one make sure the questions surface the information needed? How does one do all this and keep the survey short enough to avoid discouraging respondents from completing it? In retrospect, I made a number of mistakes, but here's what we ended up sending out (note that we selected the name "CivicRally" for our service):
In addition to surveying, I hit the streets to do in-person interviews. This was my first time doing this as well. Needless to say, I felt nervous and awkward walking up to random strangers to interview them. It admittedly got easier as I went on, but I still felt uneasy whenever people would turn me down or avoid eye contact and run away as I approached. But I ended up with some great feedback and even had two videos. Unfortunately, I can't post the videos since I didn't get verifiable consent to make them public, which I should have done for educational purposes. Next time, I'll try to do so.
On the final day, we started integrating everything and getting tons of feedback from mentors. Some of the people who really helped us refine our business model as well as our pitch deck were Carter Rabasa, a developer evangelist for Twilio, and Robi Ganguly, CEO at Apptentive. Twilio and Apptentive are really cool companies, by the way.
Our slide deck came together along with the prototype. Even on our highly collaborative team, there was a small amount of tension as the deadline drew close, but nothing tumultuous. Other teams, on the other hand had been blowing up all over the place. Some teams disbanded and didn't return after Saturday. Some teams were loudly arguing throughout the weekend. I was really glad about the great group of people I was working with.
Finally, we wrapped things up and pitches started. I was presenting our project, so had been rehearsing and getting feedback all afternoon. In the end, getting the feedback on the dry runs was key. The pitch went really well, and we all felt relieved and proud of our accomplishment. As the judges started asking questions, we were completely shocked when one said we had "accomplished more in a single weekend than what Code for America had in a year," which was followed by applause from the the entire audience. I didn't really know what to say, so I just replied with something that had been on my mind all weekend, "it was entirely because of this great team."
After a long deliberation, the judges came back and announced the winners. We came in third. While we were happy to have ranked, we were most excited about how well we had all worked together, all the learning we did, and what we had accomplished in a short time.
While I will not be continuing this project, several teammates expressed interest in continuing to work on it. You can check out the result here (only a prototype as of writing, but hopefully something more later): http://www.civicrally.org/.
When I arrived Friday evening, there were a few people I recognized, but many more who I didn't. I think the theme of this event drew a different group of people than I normally interact with at startup events. I was certainly pleased with the opportunity to meet and converse with new people. I was also pleasantly surprised to run into Bharat Shyam, who I had known from when I worked on Windows Azure. It turned out he was one of the judges of the event, which is fitting given his role as CTO of Washington state and his involvement with startups.
Soon enough, the idea pitches kicked off. As usual, lots of interesting ideas. I was really excited about some of them as I'd love to see more projects and services that benefit our communities. The idea I pitched was a Kickstarter for community projects where people could contribute money or volunteer hours to make something happen in their community. One of the funnier ideas, but intriguing none-the-less was a tracking system to see where someone's poo goes as it leaves the bathroom and travels through city infrastructure to processing and eventual disposal.
After the idea pitches, we had some time to mingle and vote on ideas. I walked around and talked to a few people whose ideas I liked and also to a few folks interested in my idea. Some of the ideas got votes right away, but mine was slow going. But in the end, it just barely made the cutoff in the top ideas and so it became one of the team projects.
During the mingling time, I focused my time on conversations with people who seemed collaborative. I tried to drop out of conversations quickly when people were only interested in talking about themselves (i.e. had no interest in listening), talked condescendingly of others, or seemed acerbic. This seems to have paid off because once team formation happened, I was really fortunate to have collaborative people gather around the idea, wanting to work together. Another element that made me feel particularly lucky was to have 3 designers on the team.
The first night wrapped up with brainstorming. We all gathered around, discussed the problem and the idea and hacked at the idea until we felt we had a plausible business model (using the business model canvas). This team was seriously awesome to work with. Everyone got a long really well, where several other teams seemed to be having tension as early as the first night.
Saturday was a really full day. We got feedback from mentors and I ended up spending a large portion of my time putting a survey together. This was the first time I really worked on making a survey and found it more difficult than I had thought it would be. How does one come up with questions that won't lead the answerer's responses? How does one make sure the questions surface the information needed? How does one do all this and keep the survey short enough to avoid discouraging respondents from completing it? In retrospect, I made a number of mistakes, but here's what we ended up sending out (note that we selected the name "CivicRally" for our service):
- Would you be interested in using a service like CivicRally?
- How often do you do volunteer work?
- When you volunteer your time, what type of organization you volunteer with most often?
- If you were to volunteer your time, which would your top preference be as to the community your effort supports?
- If it were easier to find out about community projects near your neighborhood, how likely would you be to volunteer for those?
- Is there a project you would like to see happen in your neighborhood?
- If you have a project in mind, please provide a one-sentence description.
- If you have a project in mind, how much funding would it require?
- If there was a way to create, share, and support local community projects, would you submit projects? Contribute time to projects? Contribute money to projects?
- Would you feel more inclined to start local community projects if it was easier to get support for the project?
- How would you prefer to create, discover, and sign up to support community projects?
- When you donate money, what type of organization you donate to most often?
- If you were to donate money, which would your top preference be as to the community your donation supports?
- If your neighborhood had a score indicating the level of community engagement, would you contribute money or volunteer time to increase the score?
- Now that you've thought about the other questions, do you think you'd use a service like CivicRally?
- Approximately what percentage of your friends and family do you think would use a service like CivicRally?
- Which social media networks, if any, would you use to tell friends and family about CivicRally projects?
- If you started a community project with CivicRally, would you ask others who had not joined CivicRally to sign up?
- Age?
- Gender?
- Home zip code?
- Please provide your email if you would like to hear more about CivicRally later.
In addition to surveying, I hit the streets to do in-person interviews. This was my first time doing this as well. Needless to say, I felt nervous and awkward walking up to random strangers to interview them. It admittedly got easier as I went on, but I still felt uneasy whenever people would turn me down or avoid eye contact and run away as I approached. But I ended up with some great feedback and even had two videos. Unfortunately, I can't post the videos since I didn't get verifiable consent to make them public, which I should have done for educational purposes. Next time, I'll try to do so.
On the final day, we started integrating everything and getting tons of feedback from mentors. Some of the people who really helped us refine our business model as well as our pitch deck were Carter Rabasa, a developer evangelist for Twilio, and Robi Ganguly, CEO at Apptentive. Twilio and Apptentive are really cool companies, by the way.
Our slide deck came together along with the prototype. Even on our highly collaborative team, there was a small amount of tension as the deadline drew close, but nothing tumultuous. Other teams, on the other hand had been blowing up all over the place. Some teams disbanded and didn't return after Saturday. Some teams were loudly arguing throughout the weekend. I was really glad about the great group of people I was working with.
Finally, we wrapped things up and pitches started. I was presenting our project, so had been rehearsing and getting feedback all afternoon. In the end, getting the feedback on the dry runs was key. The pitch went really well, and we all felt relieved and proud of our accomplishment. As the judges started asking questions, we were completely shocked when one said we had "accomplished more in a single weekend than what Code for America had in a year," which was followed by applause from the the entire audience. I didn't really know what to say, so I just replied with something that had been on my mind all weekend, "it was entirely because of this great team."
After a long deliberation, the judges came back and announced the winners. We came in third. While we were happy to have ranked, we were most excited about how well we had all worked together, all the learning we did, and what we had accomplished in a short time.
While I will not be continuing this project, several teammates expressed interest in continuing to work on it. You can check out the result here (only a prototype as of writing, but hopefully something more later): http://www.civicrally.org/.
Saturday, April 14, 2012
What Comes First, the Team or the Idea?
In the context of entrepreneurship, an idea is a set of assumptions that appear to have the potential to be turned into a successful business. Recently, several colleagues and I were discussing whether coming up with a great idea or assembling a great team is the first step in starting a company. Personally, I believe deeply in the power of teamwork and the concept of getting the right people on the bus first (and making sure they're sitting in the right seats). And yet, the question of whether the idea or the team comes first presents something of a catch-22. If we start with an idea, it's incredibly difficult to find the perfect team for that idea. In fact, we might not even have a place on the perfect team. But if we don't have an idea, it can be incredibly difficult to recruit teammates.
The various popular sayings about the (lack of) value of business ideas hold some merit even though they aren't axiomatic truths. For example: ideas are a dime-a-dozen and don't fall in love with your idea. Although there may be some cases of people who change the world through stubborn resolve, I think they are rare. I believe it is much more effective and productive to seek feedback and apply it to your situation in an intelligent way. We might analogize putting all of our energy into a single, immutable idea with putting all of our money on a single horse in a race with a million horses. If the rules of the race allowed us to change our bet as the race progresses, why wouldn't we take advantage of that?
There are also varying opinions about keeping our ideas locked up so no one steals them. Annecdotally, the general recommendation from those with experience seems to be to share our idea with as many people as we can. That's how we get feedback and identify issues we might otherwise miss as individuals. There is a saying about keeping equity to one's self that I think applies very well to the concept of ideas: "Equity is (ideas are) like shit. Hoard it and you'll end up with a great big pile of shit. Spread it around and amazing things happen."
This brings us to consideration of the relationships between ideas. How do we define the boundaries between ideas? There are numerous elements of a business idea, which from a high level are well-captured in the business model canvas, and there are innumerable details. Clearly, any two ideas are connected by an infinite number of paths paved with consecutive tweaks to the details of the ideas. Defining the distinction between ideas, then, is like the old philosophical question that asks, "at what point does a boat become a different boat if we gradually replace each plank, one-by-one?" This brings us back to the cautionary note on not falling in love with our idea. If one of the planks is rotting, we have to be willing to replace it or risk sinking the entire boat. Sometimes this happens repeatedly until the boat is quite different from what we started with.
So how does the team fit into all of this? Teammates contribute to making prudent judgments about when to bet on which horse, keeping the boat in good repair, and making sure we don't end up with a pile of shit. The question remains of how we assemble the team.
Given that change is a certainty, it's important to keep our destination in mind. Focusing only on the immediate path causes us to get stuck when we hit a road block. Having a team with an eye on the goal is having a team that will adapt to change, while continuing to move in the right direction. It means having a team that will not fall apart when we inevitably hit rough patches.
What all of this leads up to is that we need to change the way we think. Let's stop focusing on "killer ideas" and instead start talking about our goals and how we're going to change the world. When we tell someone about our vision for the future, they're likely to offer up ideas about how to make it a reality. If they do, that's great - we've found a potential partner. Of course, we need to make sure that our team's values are aligned and that our personalities mesh, but focusing on goals is good way to find one another in the first place.
Now back to ideas. Ideas are hypotheses. They are just assumptions about how we might achieve our goals. They are meant to be tested and modified as we learn. A solid team with strong leadership will generate good ideas and go through the necessary steps to test and refine them. In the end, I suppose the question of whether the team or the idea comes first is misgiving. The answer is that goals come first, then, if possible, the team, then numerous iterations of ideas.
The various popular sayings about the (lack of) value of business ideas hold some merit even though they aren't axiomatic truths. For example: ideas are a dime-a-dozen and don't fall in love with your idea. Although there may be some cases of people who change the world through stubborn resolve, I think they are rare. I believe it is much more effective and productive to seek feedback and apply it to your situation in an intelligent way. We might analogize putting all of our energy into a single, immutable idea with putting all of our money on a single horse in a race with a million horses. If the rules of the race allowed us to change our bet as the race progresses, why wouldn't we take advantage of that?
There are also varying opinions about keeping our ideas locked up so no one steals them. Annecdotally, the general recommendation from those with experience seems to be to share our idea with as many people as we can. That's how we get feedback and identify issues we might otherwise miss as individuals. There is a saying about keeping equity to one's self that I think applies very well to the concept of ideas: "Equity is (ideas are) like shit. Hoard it and you'll end up with a great big pile of shit. Spread it around and amazing things happen."
This brings us to consideration of the relationships between ideas. How do we define the boundaries between ideas? There are numerous elements of a business idea, which from a high level are well-captured in the business model canvas, and there are innumerable details. Clearly, any two ideas are connected by an infinite number of paths paved with consecutive tweaks to the details of the ideas. Defining the distinction between ideas, then, is like the old philosophical question that asks, "at what point does a boat become a different boat if we gradually replace each plank, one-by-one?" This brings us back to the cautionary note on not falling in love with our idea. If one of the planks is rotting, we have to be willing to replace it or risk sinking the entire boat. Sometimes this happens repeatedly until the boat is quite different from what we started with.
So how does the team fit into all of this? Teammates contribute to making prudent judgments about when to bet on which horse, keeping the boat in good repair, and making sure we don't end up with a pile of shit. The question remains of how we assemble the team.
Given that change is a certainty, it's important to keep our destination in mind. Focusing only on the immediate path causes us to get stuck when we hit a road block. Having a team with an eye on the goal is having a team that will adapt to change, while continuing to move in the right direction. It means having a team that will not fall apart when we inevitably hit rough patches.
What all of this leads up to is that we need to change the way we think. Let's stop focusing on "killer ideas" and instead start talking about our goals and how we're going to change the world. When we tell someone about our vision for the future, they're likely to offer up ideas about how to make it a reality. If they do, that's great - we've found a potential partner. Of course, we need to make sure that our team's values are aligned and that our personalities mesh, but focusing on goals is good way to find one another in the first place.
Now back to ideas. Ideas are hypotheses. They are just assumptions about how we might achieve our goals. They are meant to be tested and modified as we learn. A solid team with strong leadership will generate good ideas and go through the necessary steps to test and refine them. In the end, I suppose the question of whether the team or the idea comes first is misgiving. The answer is that goals come first, then, if possible, the team, then numerous iterations of ideas.
Sunday, March 25, 2012
Driving Your Own Agenda Leads to Failure
I've been on many teams in my lifetime. At work, in school, in social activities, etc. During recent reflection on past successes and failures, I noticed that among cases of failure, it is common for team members, or a key team leader, to be focused on their own agenda. As I thought about this observation more, I came to the conclusion that when someone drives their own agenda, whatever they're working on is highly likely to fail.
This hypothesis sounds like an over-generalization. But let's clarify what is meant by "driving one's own agenda". This statement refers to situations in which one is so focused on their personal goals that certain realities of the environment in which they are operating fall the periphery of their view. To take a simple example, consider someone who wants a promotion. Their singular focus is on getting that reward. I purposely use the term "getting" because when the focus is on the promotion itself, it devalues the act of earning it. As focus on the promotion becomes sharper and sharper, everything else becomes obscured.
So why do I believe this behavior is highly likely to lead to failure? As I mulled over the the failures I've been through, I considered them in this context and asked myself, "isn't focus a good thing?" The answer is clearly yes. Focusing on a small set of goals and removing distractions is a powerful technique in achieving success; we've all heard the saying "do one thing and do it well". Wasn't focus one of Steve Jobs' (RIP) techniques for success? This is all true and good, but the problems start when one ignores the vast web of interconnections that render our actions inalienable.
To be successful, it is important to understand one's relationship with fellow workers and communal goals. It is important to understand how the different actors affect the system. While certain actions are isolated, others have direct and obvious impact, and still others reverberate through the web in subtle ways. And we can't forget that we are not the only party taking action. We need to understand the structure of the web and how our goals play into it. If we are so caught up in driving our own agenda that we can't see beyond the immediate impact of our behaviors, we are highly likely to fail since we miss the broader dynamics at play. Elaborating on our example, if we are pursuing a promotion with tunnel vision, we may miss the fact that the organization we are part of needs to have the profits to fund the promotion. As we invest our energy into standing out from our peers and gaining influence on key organizational decision makers, we divest elsewhere, perhaps reducing the overall profit-earning capacity of the organization. Thus, our singular focus on our goal not only contributes to our failure to achieve it, but also negatively impacts those depending on us.
The thing to remember is to be aware of the complex web of interrelationships and how the different pieces influence one another. For success, understand the best way to invest your energy in this holistic context. From my experience, this usually means driving community goals rather than individual agendas.
This hypothesis sounds like an over-generalization. But let's clarify what is meant by "driving one's own agenda". This statement refers to situations in which one is so focused on their personal goals that certain realities of the environment in which they are operating fall the periphery of their view. To take a simple example, consider someone who wants a promotion. Their singular focus is on getting that reward. I purposely use the term "getting" because when the focus is on the promotion itself, it devalues the act of earning it. As focus on the promotion becomes sharper and sharper, everything else becomes obscured.
So why do I believe this behavior is highly likely to lead to failure? As I mulled over the the failures I've been through, I considered them in this context and asked myself, "isn't focus a good thing?" The answer is clearly yes. Focusing on a small set of goals and removing distractions is a powerful technique in achieving success; we've all heard the saying "do one thing and do it well". Wasn't focus one of Steve Jobs' (RIP) techniques for success? This is all true and good, but the problems start when one ignores the vast web of interconnections that render our actions inalienable.
To be successful, it is important to understand one's relationship with fellow workers and communal goals. It is important to understand how the different actors affect the system. While certain actions are isolated, others have direct and obvious impact, and still others reverberate through the web in subtle ways. And we can't forget that we are not the only party taking action. We need to understand the structure of the web and how our goals play into it. If we are so caught up in driving our own agenda that we can't see beyond the immediate impact of our behaviors, we are highly likely to fail since we miss the broader dynamics at play. Elaborating on our example, if we are pursuing a promotion with tunnel vision, we may miss the fact that the organization we are part of needs to have the profits to fund the promotion. As we invest our energy into standing out from our peers and gaining influence on key organizational decision makers, we divest elsewhere, perhaps reducing the overall profit-earning capacity of the organization. Thus, our singular focus on our goal not only contributes to our failure to achieve it, but also negatively impacts those depending on us.
The thing to remember is to be aware of the complex web of interrelationships and how the different pieces influence one another. For success, understand the best way to invest your energy in this holistic context. From my experience, this usually means driving community goals rather than individual agendas.
Wednesday, February 29, 2012
Who deserves credit for Lean Startup?
With all the excitement about Lean Startup (Eric Ries has made comments with concern about over-hype), it's easy to miss other important works. In particular, I have just finished reading The Innovator's Dilemma by Clayton Christensen, which was first published in 1997. While reading, I was awestruck by the concepts Christensen brings to light. But more on the thesis and general topics of the book at a later date.
What I want to point out is that every entrepreneur should read this book. A lot of important concepts Steve Blank elaborates on in The Four Steps to the Epiphany (2004) and Eric Ries simplified and popularized in The Lean Startup were already captured in The Innovator's Dilemma. In fact, Blank and Ries frequently recommend reading The Innovator's Dilemma. What Blank and Ries did was to help us understand the concepts, identify how they relate to our success as entrepreneurs, and give us a road map with tips and tools to use them.
A few excerpts from The Innovator's Dilemma will illustrate concepts very familiar to fans and practitioners of Lean Startup:
So aside from giving credit where it's due, what additional value comes from reading The Innovator's Dilemma? a general outcome is to understand what disruptive innovation is and its contrast to sustaining innovation. Readers will learn why entrepreneurs that develop disruptive offerings can compete and win against entrenched, well-funded competitors. People often talk about how startups have an advantage by being nimble and this book helps develop a definition of what it really means to be nimble and implicates how to strategize around that, turning it into a competitive advantage (against established players).
With the recent attention being given to the methods of Lean Startup, I want to recognize Christensen for identifying the concepts 15 years ago and at the same time thank Blank and Ries for developing them and spreading the practice. All are critical pieces that work together as part of the same puzzle. So if you haven't already done so, make a little space next to Blank and Ries on your Lean Startup shrine for Christensen.
Who else deserves recognition for identifying and publishing these concepts prior to Christensen?
What I want to point out is that every entrepreneur should read this book. A lot of important concepts Steve Blank elaborates on in The Four Steps to the Epiphany (2004) and Eric Ries simplified and popularized in The Lean Startup were already captured in The Innovator's Dilemma. In fact, Blank and Ries frequently recommend reading The Innovator's Dilemma. What Blank and Ries did was to help us understand the concepts, identify how they relate to our success as entrepreneurs, and give us a road map with tips and tools to use them.
A few excerpts from The Innovator's Dilemma will illustrate concepts very familiar to fans and practitioners of Lean Startup:
- Research has shown, in fact, that the vast majority of successful new business ventures abandoned their original business strategies when they began implementing their initial plans and learned what would and would not work in the market... Guessing the right strategy at the outset isn't nearly as important to success as conserving enough resources... so that new business initiatives get a second or third stab at getting it right. Christensen cites supporting research that goes as far back as 1992.
- But in disruptive situations, action must be taken before careful plans are made. Because much less can be known about what markets need or how large they can become, plans must serve a very different purpose. They must be plans for learning rather than plans for implementation... Discovery-driven planning, which requires managers to identify the assumptions upon which their business plans or aspirations are based, works well in addressing disruptive technologies. Here he references work from 1995.
- Moore suggests that products are initially used by innovators and early adopters in an industry - customers who base their choice solely on the product's functionality... Moore observes that markets then expand dramatically after the demand for functionality in the mainstream market has been met... A third wave of growth occurs... pulling in the late majority customers. Note that Crossing the Chasm was published all the way back in 1991.
- Although we don't have a clue about where the market is, the one thing we know for certain is that it isn't an established... market segment.
- But, although we may target this market first, there's a high probability that our initial concept will prove wrong. So we've got to get the first models done fast and on a shoestring - leaving ample budget to get it right once feedback from the market starts coming in.
So aside from giving credit where it's due, what additional value comes from reading The Innovator's Dilemma? a general outcome is to understand what disruptive innovation is and its contrast to sustaining innovation. Readers will learn why entrepreneurs that develop disruptive offerings can compete and win against entrenched, well-funded competitors. People often talk about how startups have an advantage by being nimble and this book helps develop a definition of what it really means to be nimble and implicates how to strategize around that, turning it into a competitive advantage (against established players).
With the recent attention being given to the methods of Lean Startup, I want to recognize Christensen for identifying the concepts 15 years ago and at the same time thank Blank and Ries for developing them and spreading the practice. All are critical pieces that work together as part of the same puzzle. So if you haven't already done so, make a little space next to Blank and Ries on your Lean Startup shrine for Christensen.
Who else deserves recognition for identifying and publishing these concepts prior to Christensen?
Saturday, January 28, 2012
Leadership Lessons I Learned From My Dogs
I know there are a lot of useless "everything I need to know..." lists including plenty about what people have "learned" from their dogs. In fact, there's even an entire management book on it. There may be a few useful entries on these lists, but usually, they feel as though the authors were adding filler to reach some specific number of lessons or to make the list as big as possible.
At risk of adding yet another entry to the over-abundance, I assembled my own list of leadership lessons that I learned from my dogs. Each item in the list is experience-driven, originating in the confluence of personal reflection on leadership experiences at work and trying to take care of my dogs. Many of them came from morning and evening walks when the dogs are trying to find a good place to poop and I am preparing mentally for the day ahead or winding down from the day now passed. This is why there are precisely 7 entries, rather than 5 or 10 or 100.
These are the genuine lessons in leadership my dogs taught me:
At risk of adding yet another entry to the over-abundance, I assembled my own list of leadership lessons that I learned from my dogs. Each item in the list is experience-driven, originating in the confluence of personal reflection on leadership experiences at work and trying to take care of my dogs. Many of them came from morning and evening walks when the dogs are trying to find a good place to poop and I am preparing mentally for the day ahead or winding down from the day now passed. This is why there are precisely 7 entries, rather than 5 or 10 or 100.
These are the genuine lessons in leadership my dogs taught me:
- Encourage desired behavior by using rewards. The best way I have found to get my dogs to sit on command is to reward them when they do it. This is called operant conditioning, in the form of positive reinforcement. The important observation is that punishment is not an tool for extracting desired behavior. The same goes for people. If you want to, for example, get people to be collaborative, the best way to do so is to reward the behavior. It is also worth understanding negative reinforcement. A product that breaks easily even though it shouldn't will result in a lot of support calls and lost customers. The pain associated with each call and lost customer is encouragement to make your product more resilient.
- Different rewards are appropriate at different times. Sometimes a dog needs a big, beefy treat, like when it is learning a completely new trick. Sometimes it only needs a pat on the head, like when it is performing a behavior it has internalized. With people, big rewards are needed when, for example, cultural change is initiated. Smaller rewards are needed after the desired culture has been established and the person exhibits according behavior.
- Punishment is appropriate to stop misbehavior. Trying to teach a dog to stay out of the street by making them come to you with a treat whenever they start to walk into the street really just teaches them that they can get a treat by walking into the street. Punishment sucks for everyone involved, but it is an effective tool for stopping undesired behavior. If you shout at a dog when it walks into the street, it will quickly learn that there is a negative consequence for this action. When people are fighting at work, the most effective way to put an immediate stop to the behavior is to punish it. To state the obvious, combining multiple stimuli is more effective than applying a single one. This risk with punishment is that when the enforcer is removed, the opportunity for the undesired behavior to return surfaces. If we stop people from fighting with punishment, then help them to observe the rewards of collaboration, we have an impact that lasts much longer.
- Everything is about influence. At this point, it is probably clear that the overarching statement of this post is that leadership is effective application of influence. Keep in mind that influence is not just an outbound process. My dogs try to influence me all the time. When they get in trouble, they really do make puppy eyes and it's incredibly hard to punish bad behavior when the puppy eyes are on full blast. Influence goes in all directions. At work, our peers influence us, our employees influence us, our bosses influence us, our customers influence us, our suppliers influence us, and so on.
- Keep on schedule and follow through with commitment. When I don't keep on schedule and follow through with my commitment to my dogs, they pee on the floor. Having a schedule makes their lives predictable, so they know when they'll get to go outside. My commitment to them is to take them out on that schedule. When I don't, I'm punished, even though the dogs aren't punishing me on purpose (at least I hope not!). When a commitment is made to an employee or customer, we must follow through. Otherwise, they will justifiably leave us. Or if they're crazy enough, they might pee on our floors.
- Sometime you just have to pick up poo. Dogs poop. In fact, everyone poops. As a dog owner, it's my responsibility to pick up their poop. Things don't always go right and as leaders, sometimes we have to clean up messes even if we didn't directly cause them. It comes with the territory, so if one is not okay with cleaning up from time to time, they should reconsider whether leadership is for them. And we should all keep in mind that it's perfectly fine not to be a leader! The decision depends on our aspirations, goals, and personal values. Those of us who do wish to be leaders have a responsibility to create the best situation possible, so we must use our skills of influence to reduce the occurrence of messes.
- Their health is important to our health. Having pets purportedly has many health benefits. I don't know if they really reduce stress (try telling me that when I'm picking up poop), but I certainly enjoy walking with them, playing with them, and telling funny stories about them. As a leader, all the people around us enhance our ability to do whatever we do. The health of a leader's career depends on the health of those around him or her. When our customers are not doing well, neither are we. When the people we work with become unhappy or sick, our capacity to work towards a goal dissipates. It is important to take care of those around us and to be a force for good in their lives.
Sunday, January 22, 2012
Startup Weekend: Lessons and tools
There are innumerable lessons to be learned through the course of any Startup Weekend. Here are the key take-aways from my first experience:
Follow my Startup Weekend Seattle experience through the following progression of posts:
- People first: You're going to spend 54 hours working closely and under high pressure with a group of people you (probably) haven't met before. Make sure you pick people you'll enjoy working with. A great idea is exciting, but choosing the right people will make or break your weekend. This also means you should try to find people who are looking to get the same thing out of the weekend as yourself.
- Bring your own skills: You don't need to be an expert in everything, but don't set your project up such that it will fail if you don't have access to specific talent. Several teams didn't have any prototype whatsoever when demo time came around and this hurt them in the judging. If you have no technical background, dabble in HTML, which in many cases will be enough for you to mock something up. Or familiarize yourself with the process of off-loading the work to others through oDesk or your personal rolodex. If you are technical, but have no business skills, have some resources prepared that can guide you through the steps needed to assemble a pitch deck. For Startup Weekend, things don't need to be perfect - they just need to be done.
- Leave your ego at the door: A big ego has no place at Startup Weekend. This will drive people away from your team. Let someone else be the expert. One of the devs I worked with was less experienced than myself and preferred to use a technology I hadn't used in the past, but we went ahead and chose that. I felt that it would make the experience more enjoyable for the group and that it would be an opportunity for me to learn something new. Throughout the weekend, I probably asked him questions every thirty minutes, but I didn't have a choice since we were in a time crunch. In the end, I felt that even though I was slower, we were fairly productive as a team. Plus I learned a lot from him.
- Also, leave your way of doing things at the door: Remember that you're working with new people and each of them are used to doing things in their own way. Everyone needs to be flexible and coalesce around a common approach. No one has to agree about whether any ways is right or wrong, but everyone has to be willing to go with one approach during the next 54 hours.
- Don't wait: Make sure that throughout the weekend, you keep the time limit in mind. You might feel like you need to hammer out the monetization scheme before going out and getting feedback, before giving the devs implementation tasks, etc. This is a mistake that will lead to a missed deadline. Devs can and should get started on something. The same for designers and business people. Don't worry about whether any of it will be thrown away. Try to work smart so that there are re-usable pieces that can be applied after your customers tell you your idea sucks and you have to change it. Remember that you're just hacking together a rough prototype.
- Relentless focus: It's unbelievably easy to get caught up in getting to know your teammates better, pontificating about the virtues of different approaches to the project, etc. Everyone needs to be incredibly focused on whatever they're responsible for. It even goes as far as (politely!) turning away mentors when you have to. Trust me, they'll understand.
- You can call a turd sacred, but it's still just a ball of poo: You're in prototype mode the entire weekend. 85% or more of what you create during the weekend will be thrown out if you even continue with the idea at all afterwards. Don't treat anything as sacred. You built a sweet app, but the target customers don't have iPhones? Throw it out. You came up with a brilliant way to trigger viral marketing, but you can't get the viral coefficient to be greater than 1? Throw it out. This doesn't literally mean let the ideas fall off the face of the Earth entirely, but for the weekend, focus on what works. You can come back to all the other ideas later.
- Remember, it's only a weekend: Startup Weekend takes place during the weekend and lasts only 54 hours. This means you're not missing work, you're not making any career commitments, you're not taking financial risk, etc. This is a great environment in which to experiment, learn new things, and meet some great people. On Monday, you'll get to return to your day job, where you report to your manager, have health insurance, and have a steady paycheck. Or maybe you won't... by your own choice. ;)
- Bring water: This pointer is simply related to the fact that you probably aren't familiar with the facilities you'll be working in, so be sure to bring some extra supplies. There wasn't enough water to go around during my first Startup Weekend, so everyone was a bit parched. Perhaps you'll find that you need an extra jacket because the heater isn't working. Just be sure to bring what you need to be comfortable and focused.
- Lot's of sticky notes and pens: We used these to brainstorm and track ideas as well as tasks.
- github: Online code repository for source control.
- php fog: PHP host that helps you get your service up and running in minutes.
- CodeIgniter: PHP framework to help build web apps.
- MySQL: Database.
- HTML5, JavaScript, CSS: Standard technologies for building web clients.
- jQuery: A JavaScript library that helps make your JavaScript coding more productive.
- Google Maps JavaScript API: Useful for presenting location-based information.
- Dropbox: We used this extensively to share documents and other miscellaneous files.
- SurveyMonkey: We sent a survey out to poll potential customers about our idea.
- iPhone Camera: We used phone cameras a few times to capture information, including to record the product demo that was included in our presentation.
- Business Model Canvas: The business model canvas helps map out the elements of a business model and identifies areas in which assumptions need to be validated.
- The design team also used a variety of tools, though I'm not sure what.
Follow my Startup Weekend Seattle experience through the following progression of posts:
- Initial thoughts
- Pre-Startup Weekend bootcamp (Jan. 12, 2012)
- My pitch idea
- Day 1 of Startup Weekend Seattle (Jan. 13, 2012)
- Day 2 of Startup Weekend Seattle (Jan. 14, 2012)
- Day 3 of Startup Weekend Seattle (Jan. 15, 2012)
- Post-Startup Weekend lesson summary (this post)
Tuesday, January 17, 2012
Startup Weekend: Day 3
I arrived at the Hub on day 3 of Startup Weekend to find that two more team members tapped out. The dev who had been programming the iPhone interface sent us an email mid-morning because there was too much snow in the streets and we simply never heard from the dev who had been working on the HTML. The only HTML code that was checked in was the setup I had prepared the night before and I was thankful that I had started it.
The biz team had sent a survey the night before and I forwarded it to a few friends. Several of them actually wrote me a quick message in response showing their support for my involvement with this project, for which I'm thankful:
Part way through the day, the graphics came in and were beautiful. I've never worked with artists or designers before and it was a great experience to do so, seeing their expertise in action. The truth is, we didn't approach our product as something that was meant to solve a problem, as would a traditional startup. Rather, our aim was to create an experience that introduced joy into people's lives. The art and user experience design were integral to making this happen.
Since we were so tight on time, we knew that on the dev side we were going to have a pretty rough prototype. However, we wanted something more complete for the demo. One of our designers had done mock-ups of the app to show the user experience and to guide the dev team in what to implement. We took the mock-up and extended it to present a series of steps that captured the user experience. This was recorded on video and included in the demo. It came out great!
Through the day, the biz team was working out details in the concept and putting together ideas for the presentation. The presentations were alloted 4 minutes each with time for Q&A from the panel of judges. The team worked on a slide deck and for most of the day, we didn't see them since they were practicing and refining the presentation.
My partner dev and I coded right up to presentation time. Just as presentations were starting, we wrapped up the last bit of functionality we thought was required for the prototype and cheered a bit because we had actually gotten it done! We quickly created a bitly link and ran it over to the biz team so they could include it in the presentation.
My fellow dev, Michael, working right up until presentation time!
As the presentations began, the biz team kept practicing. In short time, we were next up to present. Naturally, disaster struck as the computer on which the presentation was hosted refused to display to the projector. The organizers allowed us to swap places with the proceeding team and take another shot at setting up the presentation. Our team scrambled, transferring the presentation to another computer and making another attempt at getting it on the screen. Fortunately, it worked this time and we were up!
The illustrious judge panel (left) and the exhausted audience (right).
More disastor hit as we began presenting because at that point we were simply too tired to give a coherent talk. So we bumbled a bit with the informational portion of the presentation, but luckily the sense of the concept was more or less conveyed. The video lined up in the presentation and did its job of showing the experience the product creates. We never made it to the deeper explaination of the business model and customer validation, though we got a little of that out in the Q&A session. While we did an awesome job through the weekend, the steam ran out at the end and there was no way we could rank among the top projects. However, I had such an incredible experience and enjoyed working with the team so much that it didn't matter to me.
The presentation (left), including a pre-recorded video (right).
After presentations, we had a chance to talk to our fellow teams congratulating one another and getting more information about the cool things they had created over the course of 54 hours. The room was alive and everyone seemed pleased with what they had accomplished in such a short time.
A few minutes later, the judges came back and began announcing winners. They started with an honorable mention for best design. Then they moved on to best experience. To my team's astonishment, they proclaimed that we had won! It's hard to describe the incredible feeling of that moment, when we weren't expecting anything and yet were awarded one of the top spots in the competition! The judges continued with awards for best presentation, best market validation, and best overall. Afterwards, our team regrouped and the emotion spilled over. We were estatic!
We wound down the night with a beer at a bar across the street from The Hub, discussing the weekend and our experiences. A day later, we were notified that an article had been written up on GeekWire summarizing the weekend and mentioning our team as one of the winners.
This was an incredible end to an incredible weekend. I was completely amazed as I drove home, reflecting on everything that had happened. No amount of reading or conversation could have equaled the experience of actually doing it. I had a blast and can't wait until the next Startup Weekend! If you're around, I'll see you in Redmond!
Note: If you enjoyed reading about my Startup Weekend experience, check out my buddy Dwight's write-up to get another perspective. Dwight produced all the amazing art and branding for our project. You can get a third perspective from Katie, the dev who left the team the first night to help a team with no devs, at her blog.
Follow my Startup Weekend Seattle experience through the following progression of posts:
The biz team had sent a survey the night before and I forwarded it to a few friends. Several of them actually wrote me a quick message in response showing their support for my involvement with this project, for which I'm thankful:
- Very cool - Good luck! - R.B.
- I loved the idea. I will be a user. - R.S.
- Cool, Hakon. I like the idea and love that you are building it! - M.D
Part way through the day, the graphics came in and were beautiful. I've never worked with artists or designers before and it was a great experience to do so, seeing their expertise in action. The truth is, we didn't approach our product as something that was meant to solve a problem, as would a traditional startup. Rather, our aim was to create an experience that introduced joy into people's lives. The art and user experience design were integral to making this happen.
Since we were so tight on time, we knew that on the dev side we were going to have a pretty rough prototype. However, we wanted something more complete for the demo. One of our designers had done mock-ups of the app to show the user experience and to guide the dev team in what to implement. We took the mock-up and extended it to present a series of steps that captured the user experience. This was recorded on video and included in the demo. It came out great!
Through the day, the biz team was working out details in the concept and putting together ideas for the presentation. The presentations were alloted 4 minutes each with time for Q&A from the panel of judges. The team worked on a slide deck and for most of the day, we didn't see them since they were practicing and refining the presentation.
My partner dev and I coded right up to presentation time. Just as presentations were starting, we wrapped up the last bit of functionality we thought was required for the prototype and cheered a bit because we had actually gotten it done! We quickly created a bitly link and ran it over to the biz team so they could include it in the presentation.
My fellow dev, Michael, working right up until presentation time!
As the presentations began, the biz team kept practicing. In short time, we were next up to present. Naturally, disaster struck as the computer on which the presentation was hosted refused to display to the projector. The organizers allowed us to swap places with the proceeding team and take another shot at setting up the presentation. Our team scrambled, transferring the presentation to another computer and making another attempt at getting it on the screen. Fortunately, it worked this time and we were up!
The illustrious judge panel (left) and the exhausted audience (right).
More disastor hit as we began presenting because at that point we were simply too tired to give a coherent talk. So we bumbled a bit with the informational portion of the presentation, but luckily the sense of the concept was more or less conveyed. The video lined up in the presentation and did its job of showing the experience the product creates. We never made it to the deeper explaination of the business model and customer validation, though we got a little of that out in the Q&A session. While we did an awesome job through the weekend, the steam ran out at the end and there was no way we could rank among the top projects. However, I had such an incredible experience and enjoyed working with the team so much that it didn't matter to me.
The presentation (left), including a pre-recorded video (right).
After presentations, we had a chance to talk to our fellow teams congratulating one another and getting more information about the cool things they had created over the course of 54 hours. The room was alive and everyone seemed pleased with what they had accomplished in such a short time.
A few minutes later, the judges came back and began announcing winners. They started with an honorable mention for best design. Then they moved on to best experience. To my team's astonishment, they proclaimed that we had won! It's hard to describe the incredible feeling of that moment, when we weren't expecting anything and yet were awarded one of the top spots in the competition! The judges continued with awards for best presentation, best market validation, and best overall. Afterwards, our team regrouped and the emotion spilled over. We were estatic!
We wound down the night with a beer at a bar across the street from The Hub, discussing the weekend and our experiences. A day later, we were notified that an article had been written up on GeekWire summarizing the weekend and mentioning our team as one of the winners.
This was an incredible end to an incredible weekend. I was completely amazed as I drove home, reflecting on everything that had happened. No amount of reading or conversation could have equaled the experience of actually doing it. I had a blast and can't wait until the next Startup Weekend! If you're around, I'll see you in Redmond!
Note: If you enjoyed reading about my Startup Weekend experience, check out my buddy Dwight's write-up to get another perspective. Dwight produced all the amazing art and branding for our project. You can get a third perspective from Katie, the dev who left the team the first night to help a team with no devs, at her blog.
Follow my Startup Weekend Seattle experience through the following progression of posts:
- Initial thoughts
- Pre-Startup Weekend bootcamp (Jan. 12, 2012)
- My pitch idea
- Day 1 of Startup Weekend Seattle (Jan. 13, 2012)
- Day 2 of Startup Weekend Seattle (Jan. 14, 2012)
- Day 3 of Startup Weekend Seattle (Jan. 15, 2012) (this post)
- Post-Startup Weekend lesson summary
Sunday, January 15, 2012
Startup Weekend: Day 2
Day 2 of Startup Weekend kicked off at 9:30 am and about half the team was at The Hub when I got there. We started going over the idea again to figure out the types of technologies the dev team would need to set up (e.g. do we need a payment system? a database? etc.), but there was some thrashing since each person had a slightly different vision of the product. And of course, the large size of our team didn't help the situation. Fortunately, there were some things that overlapped regardless of the vision, so the dev team wasn't blocked. As a group, we agreed that an iPhone app would probably be the best way to present the experience we wanted to capture and we had a dev with iPhone experience, so he started setting up the basics. Another dev and myself started putting together a database and a RESTful service in front of it. The last dev really wanted to work on HTML5 and though the value of that work wasn't clear for the purposes of the event, at the time we had less work than could keep us all occupied, so he started working on that.
By 11:30 am, the biz team hadn't yet hit the streets to validate the idea with customers. The problem was primarily around figuring out how to monetize the product. To help resolve the deadlock, we regrouped to determine what assumptions we were going to start out with. We listed a number of key questions on a whiteboard such as "do our customers have smart phones?" and spent 30 seconds voting on the initial assumption for each one. Several questions were unnecessary to answer at the time including several that required other questions to be answered first. After doing this, we had our initial set of assumptions and could continue making progress. Some time shortly after that, the business team set out to talk to coffee shop owners and the dev team continued chugging away. In truth, identifying the right questions and the initial assumptions is not an easy task, or at least not when it's one's first time doing it.
The business team hard at work (left) and our assumption board (right).
Although there were challenges, something we did that was really important was to trust one another to deliver on their tasks. As the dev team, we trusted that the business team would deliver us a business model to implement, while they trusted us to deliver a prototype in time for the demo. The design team created an experience and trusted us to bring it out in the product. Likewise, the business team trusted the design team to bring the experience expressed in the vision to life. While we often worked together, giving feedback across teams and aligning ourselves, there was significant trust involved, which ties back to the importance of individual picking the right team and the team picking the right members.
Unfortunately, we had some additional attrition on the business side of the team by the afternoon. Two folks departed, leaving us with 10 people. At that point, we had 3 business people, 2 designers, 4 devs, and the team leader, who worked on both the business and the design (he's a designer by trade). Again, it was sad to see the departure, but probably better for everyone's overall experience.
As the day progressed, we ran into an issue on the dev team. Since only one team member had a Mac, we quickly got bottle-necked on iPhone development. We were able to whip out the backend fairly quickly thanks to its simplicity and the awesomeness of phpfog. When that happened, those of us who did not have implementation tasks made sure the backend was well-documented and ready for integration and researched services we might want to rely on such as various payment systems.
Unfortunately, I had to head out early around 5:30 pm due to a family emergency. Two other devs decided to take off at the same time as it had started snowing and they didn't want to get caught unable to reach home. I was able to come online later in the evening and found that the business team had sent out a survey using SurveyMonkey. I filled out the survey and forwarded it on to a select set of friends who I thought would be interested in responding (thanks to all who filled out the survey!).
Snowing in Seattle during Startup Weekend.
As I was reviewing the day and emails that were sent this evening, something disastrous dawned on me. There's no way we'll have the prototype for tomorrow. With only one iPhone developer, we're out of luck going down that path. I refuse to give up though. We will have a prototype to present, even if it's a big ball of tape and glue. The HTML5 code was never checked in, but it might be what we need to pull things back together. Since I don't know what the status of that code is, I started putting some pieces together myself to make sure we'll have a foundation to work from tomorrow when we'll need to seriously crank things out.
Follow my Startup Weekend Seattle experience through the following progression of posts:
By 11:30 am, the biz team hadn't yet hit the streets to validate the idea with customers. The problem was primarily around figuring out how to monetize the product. To help resolve the deadlock, we regrouped to determine what assumptions we were going to start out with. We listed a number of key questions on a whiteboard such as "do our customers have smart phones?" and spent 30 seconds voting on the initial assumption for each one. Several questions were unnecessary to answer at the time including several that required other questions to be answered first. After doing this, we had our initial set of assumptions and could continue making progress. Some time shortly after that, the business team set out to talk to coffee shop owners and the dev team continued chugging away. In truth, identifying the right questions and the initial assumptions is not an easy task, or at least not when it's one's first time doing it.
The business team hard at work (left) and our assumption board (right).
Although there were challenges, something we did that was really important was to trust one another to deliver on their tasks. As the dev team, we trusted that the business team would deliver us a business model to implement, while they trusted us to deliver a prototype in time for the demo. The design team created an experience and trusted us to bring it out in the product. Likewise, the business team trusted the design team to bring the experience expressed in the vision to life. While we often worked together, giving feedback across teams and aligning ourselves, there was significant trust involved, which ties back to the importance of individual picking the right team and the team picking the right members.
Unfortunately, we had some additional attrition on the business side of the team by the afternoon. Two folks departed, leaving us with 10 people. At that point, we had 3 business people, 2 designers, 4 devs, and the team leader, who worked on both the business and the design (he's a designer by trade). Again, it was sad to see the departure, but probably better for everyone's overall experience.
As the day progressed, we ran into an issue on the dev team. Since only one team member had a Mac, we quickly got bottle-necked on iPhone development. We were able to whip out the backend fairly quickly thanks to its simplicity and the awesomeness of phpfog. When that happened, those of us who did not have implementation tasks made sure the backend was well-documented and ready for integration and researched services we might want to rely on such as various payment systems.
Unfortunately, I had to head out early around 5:30 pm due to a family emergency. Two other devs decided to take off at the same time as it had started snowing and they didn't want to get caught unable to reach home. I was able to come online later in the evening and found that the business team had sent out a survey using SurveyMonkey. I filled out the survey and forwarded it on to a select set of friends who I thought would be interested in responding (thanks to all who filled out the survey!).
Snowing in Seattle during Startup Weekend.
As I was reviewing the day and emails that were sent this evening, something disastrous dawned on me. There's no way we'll have the prototype for tomorrow. With only one iPhone developer, we're out of luck going down that path. I refuse to give up though. We will have a prototype to present, even if it's a big ball of tape and glue. The HTML5 code was never checked in, but it might be what we need to pull things back together. Since I don't know what the status of that code is, I started putting some pieces together myself to make sure we'll have a foundation to work from tomorrow when we'll need to seriously crank things out.
Follow my Startup Weekend Seattle experience through the following progression of posts:
- Initial thoughts
- Pre-Startup Weekend bootcamp (Jan. 12, 2012)
- My pitch idea
- Day 1 of Startup Weekend Seattle (Jan. 13, 2012)
- Day 2 of Startup Weekend Seattle (Jan. 14, 2012) (this post)
- Day 3 of Startup Weekend Seattle (Jan. 15, 2012)
- Post-Startup Weekend lesson summary
Saturday, January 14, 2012
Startup Weekend: Day 1
I'm finally about to go to sleep after a long evening. I can already say that Startup Weekend has been one of the most incredible experiences I've been through and I feel as though I've already gotten my money's worth in what I've learned in the 7 hours I spent there today.
Startup Weekend Seattle kicks off
Before pitches began, I was able to practice my pitch a few times. People liked it and those who had heard my previous ideas felt that this idea had more footing. I hate when people say "my product is like X for Y", but the immediate reaction of several people was that Keynote Reputation was like Yelp! for people. It does kind of make sense. The analogy isn't enough by itself, but it helps the listener get an immediate mental model of what the idea is. So, in the end I included the analogy in my pitch, which you can check out below:
My (nervous!) pitch
I felt that the pitch itself went well enough, considering that I was extremely nervous. Each of us who pitched had 1 minute to describe our idea in an effort to convince others to help us create a business around it in the next 48 hours. Afterwards, we were given some time to mingle and vote on the ideas. As I walked around, people remembered both me and my idea. Looking for a deeper understanding, I asked how people remembered. As it turns out, the analogy that I didn't want to use ended up being a key factor! The stickers I made also helped.
After voting, my idea ended up with 4 our 5 votes, one of which was my own (we were each given three votes). This was not enough to make it into the top 13, so my idea wasn't one of the ones that became a weekend project. I'm actually pretty pleased with the results, given that there were about 60 pitches and many got no votes. All in all, I was quite impressed with the pitches. There were a lot of great ideas and passionate people.
Since my idea didn't make it past voting, I had to find a team to join. I ended up going with an idea I was pretty excited about and had wanted to work on anyway. In a nutshell, it's an app to leave a friend a gift in a specific location, with the friend getting a notification of the gift when they are within a certain proximity of it.
Aside from the pitch experience, there were three important lessons I'd like to share. The first is that large teams can be difficult to manage. We ended up with 13 team members to start (hmm... I'm not superstitious, but it's an interesting coincidence that it's Friday the 13th, there are 13 teams in the program, and my team had 13 members). There was a suggestion that we split the team in two and have two independent teams work on the same idea. We did not do this though, being optimistic about our ability to work together and make progress on this idea. Easier said than done, but I think we're doing well.
The second lesson was that identifying assumptions and figuring out how to iterate on an idea can be difficult. We found that our conversation frequently fell into details without recognizing that we were making assumptions that needed to be validated. Even in just the roughly 3 hours that we spent as a newly-formed team, we found that we had to modify the idea. This is great though! One of the benefits to having a large team is that we have lots of great input from people with different backgrounds and expertise. The trick is to keep it well-managed.
The last lesson is related to the mention of falling into details above. When talking about the idea and the business, we need to be willing to step out of our traditional roles. When in the depths of solving technical problems, a lot of technical detail is usually appropriate. However, discussing implementation details is not appropriate when trying to figure out the vision and the business model. As the team tried to narrow in on a vision for the idea, there were several times when we started talking about the technical implementation, marketing strategy, sales, design, and more to a degree that was distracting. For the vision, I would argue that these specifics are not appropriate at all. The vision simply captures the fundamental elements of what you want to create. For development of the business model, these various aspects should get more attention, but no more or less than needed. Personally, I found that I needed to make a conscientious effort to step back from the deep technical details I'm used to working with and see things at a higher level.
Before the night was over, one of our devs decided that the team was overcrowded and respectfully bowed out to join a team that was had no devs. We were sad to see her go, but I believe the decision will probably lead to a better experience both for herself and for our team, which was then down to the still large size of 12 people. I expect that we'll face some new challenges in addition to the ones mentioned above because of the size of our team as we move forward, but I think we'll manage through it and come out with something really great in the end.
I can't wait for tomorrow!
Follow my Startup Weekend Seattle experience through the following progression of posts:
Startup Weekend Seattle kicks off
Before pitches began, I was able to practice my pitch a few times. People liked it and those who had heard my previous ideas felt that this idea had more footing. I hate when people say "my product is like X for Y", but the immediate reaction of several people was that Keynote Reputation was like Yelp! for people. It does kind of make sense. The analogy isn't enough by itself, but it helps the listener get an immediate mental model of what the idea is. So, in the end I included the analogy in my pitch, which you can check out below:
My (nervous!) pitch
I felt that the pitch itself went well enough, considering that I was extremely nervous. Each of us who pitched had 1 minute to describe our idea in an effort to convince others to help us create a business around it in the next 48 hours. Afterwards, we were given some time to mingle and vote on the ideas. As I walked around, people remembered both me and my idea. Looking for a deeper understanding, I asked how people remembered. As it turns out, the analogy that I didn't want to use ended up being a key factor! The stickers I made also helped.
After voting, my idea ended up with 4 our 5 votes, one of which was my own (we were each given three votes). This was not enough to make it into the top 13, so my idea wasn't one of the ones that became a weekend project. I'm actually pretty pleased with the results, given that there were about 60 pitches and many got no votes. All in all, I was quite impressed with the pitches. There were a lot of great ideas and passionate people.
Since my idea didn't make it past voting, I had to find a team to join. I ended up going with an idea I was pretty excited about and had wanted to work on anyway. In a nutshell, it's an app to leave a friend a gift in a specific location, with the friend getting a notification of the gift when they are within a certain proximity of it.
Aside from the pitch experience, there were three important lessons I'd like to share. The first is that large teams can be difficult to manage. We ended up with 13 team members to start (hmm... I'm not superstitious, but it's an interesting coincidence that it's Friday the 13th, there are 13 teams in the program, and my team had 13 members). There was a suggestion that we split the team in two and have two independent teams work on the same idea. We did not do this though, being optimistic about our ability to work together and make progress on this idea. Easier said than done, but I think we're doing well.
The second lesson was that identifying assumptions and figuring out how to iterate on an idea can be difficult. We found that our conversation frequently fell into details without recognizing that we were making assumptions that needed to be validated. Even in just the roughly 3 hours that we spent as a newly-formed team, we found that we had to modify the idea. This is great though! One of the benefits to having a large team is that we have lots of great input from people with different backgrounds and expertise. The trick is to keep it well-managed.
The last lesson is related to the mention of falling into details above. When talking about the idea and the business, we need to be willing to step out of our traditional roles. When in the depths of solving technical problems, a lot of technical detail is usually appropriate. However, discussing implementation details is not appropriate when trying to figure out the vision and the business model. As the team tried to narrow in on a vision for the idea, there were several times when we started talking about the technical implementation, marketing strategy, sales, design, and more to a degree that was distracting. For the vision, I would argue that these specifics are not appropriate at all. The vision simply captures the fundamental elements of what you want to create. For development of the business model, these various aspects should get more attention, but no more or less than needed. Personally, I found that I needed to make a conscientious effort to step back from the deep technical details I'm used to working with and see things at a higher level.
Before the night was over, one of our devs decided that the team was overcrowded and respectfully bowed out to join a team that was had no devs. We were sad to see her go, but I believe the decision will probably lead to a better experience both for herself and for our team, which was then down to the still large size of 12 people. I expect that we'll face some new challenges in addition to the ones mentioned above because of the size of our team as we move forward, but I think we'll manage through it and come out with something really great in the end.
I can't wait for tomorrow!
Follow my Startup Weekend Seattle experience through the following progression of posts:
- Initial thoughts
- Pre-Startup Weekend bootcamp (Jan. 12, 2012)
- My pitch idea
- Day 1 of Startup Weekend Seattle (Jan. 13, 2012) (this post)
- Day 2 of Startup Weekend Seattle (Jan. 14, 2012)
- Day 3 of Startup Weekend Seattle (Jan. 15, 2012)
- Post-Startup Weekend lesson summary
Friday, January 13, 2012
Startup Weekend: Get the right people on the bus
According to Jim Collins, the first step to building a great business (actually, turning a good business into a great one, but I think the concept still applies) is to "get the right people on the bus". At Startup Weekend, this starts with an idea pitch to convince other people to work with you on an idea you have. I've iterated over lots of ideas over the past two weeks, getting feedback from everyone I could about what is interesting and what is not, and something finally stuck at the last minute. It's about helping experts build their reputations and helping event organizers find speakers for their events. Here's my pitch:
You’re an expert. You’re good at what you do and you love it. But I don’t have to tell you that because you already know. The problem is that other people don’t! There are people looking for you right now and they don’t know how to find you.
Real-world events, big and small, need experts every day and each event is an chance for experts to build solid reputations. There is a huge opportunity to change the way experts connect with the people who need them for real-world events, while building their reputations.
The team name is Keynote Reputation and we need expert developers to make it real, expert designers to make it magical, and expert business people to make it profitable. Come talk to me to change the way reputations are built.
Hopefully it doesn't seem too gimmicky, but I've also created some stickers that will be useful to other attendees and hopefully get people interested in Keynote Reputation early on. Here's a snapshot:
Follow my Startup Weekend Seattle experience through the following progression of posts:
You’re an expert. You’re good at what you do and you love it. But I don’t have to tell you that because you already know. The problem is that other people don’t! There are people looking for you right now and they don’t know how to find you.
Real-world events, big and small, need experts every day and each event is an chance for experts to build solid reputations. There is a huge opportunity to change the way experts connect with the people who need them for real-world events, while building their reputations.
The team name is Keynote Reputation and we need expert developers to make it real, expert designers to make it magical, and expert business people to make it profitable. Come talk to me to change the way reputations are built.
Hopefully it doesn't seem too gimmicky, but I've also created some stickers that will be useful to other attendees and hopefully get people interested in Keynote Reputation early on. Here's a snapshot:
Follow my Startup Weekend Seattle experience through the following progression of posts:
- Initial thoughts
- Pre-Startup Weekend bootcamp (Jan. 12, 2012)
- My pitch idea (this post)
- Day 1 of Startup Weekend Seattle (Jan. 13, 2012)
- Day 2 of Startup Weekend Seattle (Jan. 14, 2012)
- Day 3 of Startup Weekend Seattle (Jan. 15, 2012)
- Post-Startup Weekend lesson summary
Pre-Startup Weekend bootcamp
I went to a pre-Startup Weekend "bootcamp" tonight and had a pretty good time. While there were a few folks who had been to past Startup Weekend events, I felt like most of them were in the same first-timer boat as me. There were probably about 40 people (out of 120 registered for the main event) in attendance. The aggregate skill set was a bit skewed towards software development probably due to the bootcamp being somewhat developer-focused. However, people talked about everything from Google App Engine to business models to pitches.
Since I really want to pitch an idea to get the full experience of the event, I've been trying to come up with ideas over the past couple of weeks. I had six ideas I was considering, some of which I think would be pretty fun to work on, but after getting feedback from colleagues, friends, and new acquaintances from the bootcamp, I'm not convinced any of them will attract much interest from other folks at Startup Weekend. At this point, I think I need to just go with one and cross my fingers. Even if it doesn't come out well, the practice will be good for me and I'll still be excited about working on another project.
Something else I've been doing in preparation for the weekend is searching for tools to help manage the project and assist with business development. In terms of management, my favorite tool is Trello. I already use it for personal stuff and it's so easy to use and share that I think this will be a great help during the weekend. One of the cooler customer feedback tools I'm hoping I'll get a chance to try is aytm (ask your target market). It's a very focused survey tool that lets businesses survey their target audience.
At the end of the weekend, I'll write a review of the experience and share a list of the tools that we actually used. I'm excited!
Follow my Startup Weekend Seattle experience through the following progression of posts:
Since I really want to pitch an idea to get the full experience of the event, I've been trying to come up with ideas over the past couple of weeks. I had six ideas I was considering, some of which I think would be pretty fun to work on, but after getting feedback from colleagues, friends, and new acquaintances from the bootcamp, I'm not convinced any of them will attract much interest from other folks at Startup Weekend. At this point, I think I need to just go with one and cross my fingers. Even if it doesn't come out well, the practice will be good for me and I'll still be excited about working on another project.
Something else I've been doing in preparation for the weekend is searching for tools to help manage the project and assist with business development. In terms of management, my favorite tool is Trello. I already use it for personal stuff and it's so easy to use and share that I think this will be a great help during the weekend. One of the cooler customer feedback tools I'm hoping I'll get a chance to try is aytm (ask your target market). It's a very focused survey tool that lets businesses survey their target audience.
At the end of the weekend, I'll write a review of the experience and share a list of the tools that we actually used. I'm excited!
Follow my Startup Weekend Seattle experience through the following progression of posts:
- Initial thoughts
- Pre-Startup Weekend bootcamp (Jan. 12, 2012) (this post)
- My pitch idea
- Day 1 of Startup Weekend Seattle (Jan. 13, 2012)
- Day 2 of Startup Weekend Seattle (Jan. 14, 2012)
- Day 3 of Startup Weekend Seattle (Jan. 15, 2012)
- Post-Startup Weekend lesson summary
Sunday, January 8, 2012
An Example Technical Interview
Previously, I outlined the typical interview day at Microsoft. In this post, I'm going to give an example of a technical interview with a team member. When reading through the example, it is important to keep a few things in mind:
1. The Warmup
The warmup is all about helping the candidate to relax a bit. We all know interviews are nerve-wracking and we want to test the undiminished skill of the candidate. In the actual job, there will be many times when there is intense pressure and the team must be able to operate under such circumstances. However, we don't want candidates to be worried about whether they'll get the job. Rather, the pressure should come from the limited time they have. This is more like the deadline-driven pressure they will face later.
Interviewer: Hi, my name's Alice. Pleased to meet you, Bob.
Candidate: Hi Alice. Likewise.
Interviewer: I hear this is your first time in Seattle? How are you liking it so far?
Candidate: It's nice. It doesn't seem as wet as I thought it was going to be.
Interviewer: Yeah, it does actually rain a fair amount, but it's more like drizzle than downpour. So, have you a chance to talk much with other folks about our team and our product?
Candidate: I actually ran out of time in the last interview, but I got a high-level view when I talked to John this morning.
Interviewer: Did you find anything to be of particular interest?
Candidate: Yeah, the asynchronous processing seems really interesting. I've done a bit of that in the past and there are some good challenges around it.
...
What's going on here is a bit of selling the candidate on Seattle, finding out what the candidate's interests are, seeing if there's something for the candidate to get excited about on the team, and a friendly conversation about technology/problems the candidate is interested in. In all, this should be about 5 minutes. 10 minutes would be long since that would take up over 15% of the time allotted to the interview.
2. The Filter
Next comes a simple whiteboard problem that is meant to see whether the candidate should be in the interview at all. This usually isn't an issue since pre-screening over the phone is a fairly effective means of identifying whether the time and financial expense that goes into bringing someone in for a full interview should be paid.
Interviewer: Alright, I hate to interrupt our conversation, but we should really move on. Are you ready for some whiteboarding?
Candidate: Yeah, let's go ahead.
Interviewer: Great. Can you write some code to reverse a list?
Candidate: Sure. In what language?
Interviewer: What are you most comfortable with?
Candidate: I'm pretty comfortable with C, Java, and Perl. I think Java would be my preference.
Interviewer: Okay, perfect. Go ahead with Java then.
...
When you do code interviews, interviewers will usually ask you to work in whatever language you're most comfortable. Of course, there are some cases in which that won't be true. For example, when the interviewer is only familiar with languages similar to C and your preference is to work in LISP, some accommodation is probably in order.
The filter problem should really take between 5 and 10 minutes, including some validation of the solution. When candidates struggle with this one, it's usually a good indication that they aren't quite ready for the job they're applying for. Again, keep in mind all interviewers are different and not all of them will start with a simple problem. Whatever the case, try not to think too much about the mechanics of the interview and stay focused on solving the problems.
Sometimes, poor results on a filter problem will lead to cutting the remainder of the day short. If this happens, it's nothing to be embarrassed about. It just means you need to continue building your skills and come back for another try later (assuming that's what you want). In most cases, shortening the day is the right thing to do since it's respectful of both the candidate's time and the interviewers' time.
To practice for this type of question, my recommendation is to find as many simple problems as you can (or make them up) and try solving them on a whiteboard while you time yourself. If you can, get a friend or two to watch while you do this and point out mistakes. You might get a face full of humble the first time you do this, but if the job is worth it, this practice is also worth it. Over time, you'll find that you get better at solving these kinds of problems quickly as you develop a methodology for cranking out a validated solution. The added benefit is that methodology will also be applicable to...
3. The Real Coding Problem
This is the part of the interview that is really meant to challenge candidates in terms of their ability to solve algorithmic problems with code. This will require a solid understanding of more advanced concepts like pointers, recursion, concurrency, etc.
Interviewer: Looks good. So, here's another one. We need a dictionary class that can print the word list in alphabetical order. Can you implement the class for me?
Candidate: Yeah, definitely. Since we need to print the list of words, I'm assuming the dictionary is dynamic. Can I also assume that word-lookups are frequent and printing the list is relatively infrequent?
Interviewer: Yeah, that's fine.
Candidate: Are there any constraints on how long the function takes?
Interviewer: It should be as efficient as possible, given how we've defined the problem. *smile*
Candidate: *smile*
...
Remember to clarify the assumptions you are making in solving this problem. Many or even most of the assumptions will be up to the candidate as long as they make sense. For years I used to think that candidates needed to ask questions to show the interviewer they are careful in understanding requirements. Once I had spent some time on the other side of the table, I realized that while understanding the requirements of what you're creating is, indeed, important, what's more important to the interview is just getting the assumptions on the table as quickly as possible. That will maximize the amount of time spent on coming up with a great solution to the problem and answering any additional questions the interviewer may have.
In the end, this problem shouldn't take too long to solve. The key is to come up with a reasonable solution quickly and code it up. In my opinion, the biggest challenge is deciding on a single solution since there is some ambiguity around the problem. We don't want to fall into the trap of analyzing every trade-off in excruciating detail. What's more important is for the candidate to make it known that he or she is aware of the trade-off. Something to keep in mind is that even though coding is quiet-time for most people, you need to be vocal in interviews so the interviewer is aware of what's on your mind. Interviewers do want to see a candidate's ability to identify and evaluate trade-offs, but not to the detriment of getting through the interview and having a full picture of the candidate's skills. There will be plenty of evaluation of trade-offs in the open-ended design problem.
When the interviewer does need a little more insight, he or she will ask questions. Expect plenty of them both during and after the coding. Some example of questions include:
4. The Open-Ended Design Problem
Do you remember all those open-ended math problems, essay questions, and projects you had to do in high school and college? They just keep coming. Life is full of ambiguity and businesses are built on making good decisions in the face of uncertainty. The open-ended design problem tests a candidate's familiarity with important concepts and their ability to made reasoned trade-offs.
Interviewer: Okay, there's a bit of a change with the next problem. I'd like to talk about how you'd solve a larger problem. You won't need to write anymore code, but feel free to use the whiteboard.
Candidate: Sure.
Interviewer: Assume we have a very large distributed system. A major challenge in building and maintaining distributed systems is debugging. How would you design logging to support this system?
...
This kind of question can be open-ended to an extreme. Clearly, there are innumerable ways to solve such problems. What the candidate needs to do is work with the interviewer to define the constraints. In this case, spending some time exploring the options is expected and, in fact, required. It's not so much about hammering out a solution as it is about the path taken to get there. In this part of the interview, the interviewer will look for the ability to identify and address requirements, limitations, strengths, and weaknesses. The interviewer will also look for the process the candidate uses. Do they try to do all the thinking up-front and stick with the initial solution? Or do they do it iteratively, coming up with a rough concept first and continually refining it?
There will definitely be some weaknesses in the system, just as there will be strengths. The candidate should be able to describe what these are while working towards a solution and give reasoning for why they went one way or the other.
5. Question Time
At this point, the candidate may have a few extra minutes to ask some questions of the interviewer. Some interviewers expect candidates to have good questions and some don't care if they ask anything at all. Personally, I like it when candidates ask questions since I appreciate inquisitive nature and it usually provides an opportunity to know a little more about the candidate. But it isn't important and holds no bearing in the hiring decision. Of course, questions like "how much do you make" are in poor taste and shouldn't be asked. That will be taken as being invasive of the interviewer's privacy and indicative that the candidate is more interested in money than the team, product, and company. The time for money questions will be a few weeks later when, hopefully, you'll get an offer!
And that concludes this technical interview. On to the next hour with the next interviewer!
- Every interview is different. While there may be many similarities between different interviews, every interview will be unique. Every interviewer has a different style and every candidate has a different background. Various other factors come into play as well like time of day. Interviewing in the morning can be different than interviewing in the afternoon, especially candidate or interviewer is not used to waking up early.
- The questions asked will vary depending on the position and the level it's at. The example here is meant to represent the kind of interaction that would take place with someone who is interviewing for a developer position requiring a college degree and some experience. This persona is assumed purely to facilitate the discussion. Interviews for positions at lower and higher levels follows a similar pattern. In many cases, the same questions will be asked of people at different levels with different expectations for the responses given. In response to the persona, I'd also like to point out that a college degree isn't an absolute requirement for most positions. It does help with getting an interview in the first place though.
- The important part is the method, not the specifics of the example. I would highly recommend against memorizing problems and solutions. Knowing how to solve problems is the key to success.
- This example focuses on the technical interview.Some of the interviews will be technical in nature, but won't involve coding. Some won't be technical at all and will focus entirely on the candidate's personality. While it may happen on occasion, don't expect that every interview through the day will follow the pattern of this example.
1. The Warmup
The warmup is all about helping the candidate to relax a bit. We all know interviews are nerve-wracking and we want to test the undiminished skill of the candidate. In the actual job, there will be many times when there is intense pressure and the team must be able to operate under such circumstances. However, we don't want candidates to be worried about whether they'll get the job. Rather, the pressure should come from the limited time they have. This is more like the deadline-driven pressure they will face later.
Interviewer: Hi, my name's Alice. Pleased to meet you, Bob.
Candidate: Hi Alice. Likewise.
Interviewer: I hear this is your first time in Seattle? How are you liking it so far?
Candidate: It's nice. It doesn't seem as wet as I thought it was going to be.
Interviewer: Yeah, it does actually rain a fair amount, but it's more like drizzle than downpour. So, have you a chance to talk much with other folks about our team and our product?
Candidate: I actually ran out of time in the last interview, but I got a high-level view when I talked to John this morning.
Interviewer: Did you find anything to be of particular interest?
Candidate: Yeah, the asynchronous processing seems really interesting. I've done a bit of that in the past and there are some good challenges around it.
...
What's going on here is a bit of selling the candidate on Seattle, finding out what the candidate's interests are, seeing if there's something for the candidate to get excited about on the team, and a friendly conversation about technology/problems the candidate is interested in. In all, this should be about 5 minutes. 10 minutes would be long since that would take up over 15% of the time allotted to the interview.
2. The Filter
Next comes a simple whiteboard problem that is meant to see whether the candidate should be in the interview at all. This usually isn't an issue since pre-screening over the phone is a fairly effective means of identifying whether the time and financial expense that goes into bringing someone in for a full interview should be paid.
Interviewer: Alright, I hate to interrupt our conversation, but we should really move on. Are you ready for some whiteboarding?
Candidate: Yeah, let's go ahead.
Interviewer: Great. Can you write some code to reverse a list?
Candidate: Sure. In what language?
Interviewer: What are you most comfortable with?
Candidate: I'm pretty comfortable with C, Java, and Perl. I think Java would be my preference.
Interviewer: Okay, perfect. Go ahead with Java then.
...
When you do code interviews, interviewers will usually ask you to work in whatever language you're most comfortable. Of course, there are some cases in which that won't be true. For example, when the interviewer is only familiar with languages similar to C and your preference is to work in LISP, some accommodation is probably in order.
The filter problem should really take between 5 and 10 minutes, including some validation of the solution. When candidates struggle with this one, it's usually a good indication that they aren't quite ready for the job they're applying for. Again, keep in mind all interviewers are different and not all of them will start with a simple problem. Whatever the case, try not to think too much about the mechanics of the interview and stay focused on solving the problems.
Sometimes, poor results on a filter problem will lead to cutting the remainder of the day short. If this happens, it's nothing to be embarrassed about. It just means you need to continue building your skills and come back for another try later (assuming that's what you want). In most cases, shortening the day is the right thing to do since it's respectful of both the candidate's time and the interviewers' time.
To practice for this type of question, my recommendation is to find as many simple problems as you can (or make them up) and try solving them on a whiteboard while you time yourself. If you can, get a friend or two to watch while you do this and point out mistakes. You might get a face full of humble the first time you do this, but if the job is worth it, this practice is also worth it. Over time, you'll find that you get better at solving these kinds of problems quickly as you develop a methodology for cranking out a validated solution. The added benefit is that methodology will also be applicable to...
3. The Real Coding Problem
This is the part of the interview that is really meant to challenge candidates in terms of their ability to solve algorithmic problems with code. This will require a solid understanding of more advanced concepts like pointers, recursion, concurrency, etc.
Interviewer: Looks good. So, here's another one. We need a dictionary class that can print the word list in alphabetical order. Can you implement the class for me?
Candidate: Yeah, definitely. Since we need to print the list of words, I'm assuming the dictionary is dynamic. Can I also assume that word-lookups are frequent and printing the list is relatively infrequent?
Interviewer: Yeah, that's fine.
Candidate: Are there any constraints on how long the function takes?
Interviewer: It should be as efficient as possible, given how we've defined the problem. *smile*
Candidate: *smile*
...
Remember to clarify the assumptions you are making in solving this problem. Many or even most of the assumptions will be up to the candidate as long as they make sense. For years I used to think that candidates needed to ask questions to show the interviewer they are careful in understanding requirements. Once I had spent some time on the other side of the table, I realized that while understanding the requirements of what you're creating is, indeed, important, what's more important to the interview is just getting the assumptions on the table as quickly as possible. That will maximize the amount of time spent on coming up with a great solution to the problem and answering any additional questions the interviewer may have.
In the end, this problem shouldn't take too long to solve. The key is to come up with a reasonable solution quickly and code it up. In my opinion, the biggest challenge is deciding on a single solution since there is some ambiguity around the problem. We don't want to fall into the trap of analyzing every trade-off in excruciating detail. What's more important is for the candidate to make it known that he or she is aware of the trade-off. Something to keep in mind is that even though coding is quiet-time for most people, you need to be vocal in interviews so the interviewer is aware of what's on your mind. Interviewers do want to see a candidate's ability to identify and evaluate trade-offs, but not to the detriment of getting through the interview and having a full picture of the candidate's skills. There will be plenty of evaluation of trade-offs in the open-ended design problem.
When the interviewer does need a little more insight, he or she will ask questions. Expect plenty of them both during and after the coding. Some example of questions include:
- Are you satisfied with your solution?
- Are there any problems with the algorithm/code?
- How would you optimize this?
- What is the run-time?
- What if multiple thread were accessing it at the same time?
- What if this were running on a system with limited memory?
- What is an alternative way in which this could have been solved?
4. The Open-Ended Design Problem
Do you remember all those open-ended math problems, essay questions, and projects you had to do in high school and college? They just keep coming. Life is full of ambiguity and businesses are built on making good decisions in the face of uncertainty. The open-ended design problem tests a candidate's familiarity with important concepts and their ability to made reasoned trade-offs.
Interviewer: Okay, there's a bit of a change with the next problem. I'd like to talk about how you'd solve a larger problem. You won't need to write anymore code, but feel free to use the whiteboard.
Candidate: Sure.
Interviewer: Assume we have a very large distributed system. A major challenge in building and maintaining distributed systems is debugging. How would you design logging to support this system?
...
This kind of question can be open-ended to an extreme. Clearly, there are innumerable ways to solve such problems. What the candidate needs to do is work with the interviewer to define the constraints. In this case, spending some time exploring the options is expected and, in fact, required. It's not so much about hammering out a solution as it is about the path taken to get there. In this part of the interview, the interviewer will look for the ability to identify and address requirements, limitations, strengths, and weaknesses. The interviewer will also look for the process the candidate uses. Do they try to do all the thinking up-front and stick with the initial solution? Or do they do it iteratively, coming up with a rough concept first and continually refining it?
There will definitely be some weaknesses in the system, just as there will be strengths. The candidate should be able to describe what these are while working towards a solution and give reasoning for why they went one way or the other.
5. Question Time
At this point, the candidate may have a few extra minutes to ask some questions of the interviewer. Some interviewers expect candidates to have good questions and some don't care if they ask anything at all. Personally, I like it when candidates ask questions since I appreciate inquisitive nature and it usually provides an opportunity to know a little more about the candidate. But it isn't important and holds no bearing in the hiring decision. Of course, questions like "how much do you make" are in poor taste and shouldn't be asked. That will be taken as being invasive of the interviewer's privacy and indicative that the candidate is more interested in money than the team, product, and company. The time for money questions will be a few weeks later when, hopefully, you'll get an offer!
And that concludes this technical interview. On to the next hour with the next interviewer!
Subscribe to:
Posts (Atom)