The talk

You have a reasonably well founded position, you almost certainly have enough to write about. You have arguments and counterarguments for the major things people are going to say. You have experiences that no one else has. So just write them out. Who can argue with what you have experienced? You’ve already done the hard work of thinking about this problem, why not get the benefits of writing it out? If anything, this will help clarify the thoughts that you have.

The specific phrases don’t matter, as long as you are getting out the main thoughts. You can always refine it over time—the great is the enemy of the good here. That’s what the edit functionality is for. I know you would love to include a beautiful graph or venn diagram to illustrate something, but just say it now and add it later if you must.

There is this nagging thought that says, “what if someone on the internet thinks I’m WRONG??“. That’s a vestigial fear coming out, like being worried about tigers or alpha male chimpanzees. The more rational concern, and the one you should focus on, is “does anyone even know that I exist?” The only way to solve this is to write.

You’re worried about being controversial? That is a good problem to have, it means someone cares enough to write a reply. And if you are wrong? Well, you learned a lot quicker than you would have if you kept it to yourself. Seems like a good deal.

Just ship it.

Just ship. Other people might want to read it. That publish button is scary? Just schedule it for two days from now or next week and keep on writing in the meantime. You’ll have forgotten all about it when it publishes and be surprised when someone asks you about the new post. “Which post?”

Writing might be the single best way of spreading knowledge that you have. It just makes everyone better off, including you. Instead of rehashing the same stories and thought patterns in your mind and with others, just write about it and refer them to the article.

Don’t have much time to write? Put down a nugget of inspiration for later. Just put the minimum intelligible sentence, and maybe instinct will take over. Just write it up real quick while you are thinking about it. You can surely find thirty minutes to just write what you’ve been thinking about or reading about. Could it be considered productive work if you are publishing something that will help your business grow?

Lastly, it might help someone else out a lot. It doesn’t take all that much time and you will feel better having done it. When you look back on this year, the posts that you have written are going to stand out in your mind as a high note. You will get better at writing and the next post will be even easier.

Wrap-up

Meta-reservation: I was worried about publishing this post. Then I scheduled it for a week and a half away.

Phew, that was quite a pep talk.

If you ever want something to write about, let me know and I’ll try to help out!

Original article: How to Write Without Reservations

• hearing about something
• reading a book about it
• knowing a similar technology
• writing a Hello World program
• doing a small project in an area
• having years of experience doing something

I think there could also be a weighting as to how much the person feels like they know a particular area. Maybe they “read” a book but didn’t feel like it really sunk in. Perhaps they don’t know a particular technology, but have two good friends who are well versed in that technology and can help in a pinch or introduce them to people in that space. In this way, an overall view of what a person has done and may be capable of can be more easily assessed. Take for instance someone has not done much C# but has done a lot of Java development. By understanding that these technologies are similar, someone outside of the development field can understand that this person has a higher capability for C# than in, say, embedded development.

The model might best be represented by a visualization. It could be shown as graph sized by relative experience. A large bubble means more experience, and smaller bubbles represent less experience. I could see using software to make this visualization dynamic to visualize progress over time and enable different views and drilldowns. There could be a weakening aspect for experiences that were a long time ago to show knowledge decay or obsolescence. Imagine that you could see what someone’s knowledge in a subject has been for the past five years. If I have knowledge years ago in a technology that is moving super-fast, it might not be all that useful. However, many years of experience in a slow-moving environment is a good thing to know about. I feel like some sweet images would be really helpful to illustrate this, but I’m going to punt for now.

Seems like there should be something out there like this, but I haven’t seen much. I have seen nice views of resumes (mostly by designers) but nothing for the average person. Perhaps this is a tangent, but I think it would be cool.

This portfolio model helps people see what they should strategically target to move to where they want to be. When someone notices a difference between the experience they have and what they would like to do, they can choose to bone up in the space that they want to be more active in and more actively try to pursue projects in that area. Seeing a disconnect promotes a mindset change. Also, it helps people view their own competence objectively, and leverage that knowledge going forward. Hence, this model and accompanying visualization has value whether it is show in private or public. It could just be a strategic planning tool, but could also be a new way to understand what people are good at and trying to do.

It could be useful for consulting/contracting organizations to get a feel for what their levels of expertise are and how to most actively manage them. If more competence in an area is desired, specific steps can be taken to increase that area.

Could you see using something like this for your resume or for evaluating working with others?

Original article: Formal Skill Modeling

It’s useful to note that all of the following stages are generally in play at any given time. If you focus only on the future, you might starve. If you focus only on the present, you might become short-sighted and hurt long term results. The idea is that one should have:

• a list of skills that have general value today,
• a list of skills that are becoming obsolete, and
• a list of skills that just might become very useful in the near future.

Essentially, it’s skill diversification, much like people diversify stock holdings.

The Cash Cow

This is something that you are very good at and is currently in hot demand. It differs from a core competency because this is something that you can make money doing for the near foreseeable future. This is web programming (and others) in the late 1990s. This is probably Ruby (and others) today. It might be something else tomorrow. Hopefully you will have learned enough about tomorrow’s cash cow in the second phase (small bets) to be good at it when it changes.

There are different kinds of cows. It could be that COBOL programming is the thing you are best at and can easily find a variety of work for. This would fit the criteria that I laid out. You might have some that are solid, and some that are getting to be less profitable.

If you follow this general process, you will eventually have multiple focused competencies that can be used in the future. This helps ensure losses in one area can be absorbed in another. For example, if for some reason the technology that you are working in suddenly comes into huge legal problems, you are alright because you have other skills that are useful.

It helps to have some competencies be similar so that you can leverage what you know, but it also helps to diversify. In either case, being able to quickly shift what you know and learn something new is going to be a benefit. If dinosaurs could adapt to changing climates, they would have been in much better shape.

Small bets for the future

The race is not always to the swift, nor the battle to the strong, but that’s the way to bet.
- Damon Runyon

It’s hard to predict the future. If you had a time machine, it would be pretty easy to beat the stock market (see Back to the Future: Part II.) What people commonly do today is to spread their investments out with the expectation that while any one of them might not do well, when all of the investments are taken into account they will be better off than if they held the investment money under their mattress. They also take on less risk than putting all of their money into one investment.

Likewise, the point of this phase is to place small bets on skills that you think will be big at least in the next few years. This satisfies the need to explore and contribute to new initiatives, while limiting the downside that new things may bring. For example, putting all of your investment in learning a proprietary technology and doing projects with it might be a good choice if it takes off. However, if it doesn’t take off, you might be out of a lot of time invested. Generally I’d rather invest than not invest because you end up learning something you can use later, but there is an opportunity cost to consider. Maybe you could have gotten a little better at something that would be more useful.

Later, when the future is clearer, you can double-down on the things that worked well. You gain information due to being an early adopter, and win out by having more experience in a given area. This could be working with Rails in 2006, or maybe some HTML5 + Coffeescript experimentation today.

Investors might be successful if they just diversify, but some do analysis as well to try to pick better stocks. With limited capital (time, attention, energy), it pays to think about what technologies might gain wide adoption in the future. Also, there is the added consideration of: “what skills do I want to have?” If mobile development does not appeal to you, it makes less sense to learn more about it than another hot technology.

A good example of some analysis in this regard is the Thoughtworks technology radar. They give an in-depth look at what technology choices to stick with, adopt, and move away from. You might agree or disagree with their choices, but if you are at least aware that a choice exists, you can potentially make an investment.

The earlier you invest in a technology the more likely that that investment will pay out over time. Instead of four good years, you might get six. Although on the flip side, you get more information as the technology gains adoption. However, as I previously wrote, being first in the mind is enough benefit to risk trying a few technologies publicly, even if they fail. Some of the time things don’t pan out, but the rest of the time it looks like you can predict the future.

Branching out

At the same time, it is possible to learn more about surrounding fields and seemingly completely tangential ones. This is the longest view possible and also has larger potential gains. It takes a long time to become an expert in one field, and it’s helpful to understand other fields to try to be at least oriented in a certain field. Again, this branching out takes into consideration that short term and medium term needs also need to be fulfilled for success.

If I am a specialist in software development, it helps to branch out to related fields, like project management and gaining experience with running a business. These are clear wins. If I am interested in using some newer software techniques, I might want to learn more about bioinformatics to make the most of the tools that already exist, or more about the hard sciences to see what the open problems are so I can contribute to them. Basically wherever it makes sense to steal concepts or work with a certain industry.

These are likely long-term studies. One does not become better at them without sustained effort. But half an hour a day for five years adds up (about 900 hours if you take some holidays off.) For some, this might be continued formal education, for others, self study. Regardless, it adds up to more interesting work and increased options.

The nice thing about studying something mostly new is that the return on investment is significantly higher than learning a little more about something you’re already an expert at. If a professional programmer spends twenty hours reading a programming book, will she even move the needle on their professional skills? However, if this same hypothetical and clearly stereotyped-as-introverted programmer reads about how to interact better with others, this has a potentially huge benefit.

Synthesis

I’ve been trying to work the career calculus link in all post, but failed thus far. Now I feel better. This one is all about learning every day.

I think the overall goal is to maximize long-term value creation and ensure cash flow stays at an adequate level. I think opportunities should be evaluated for their lifetime value and short term impact. Value could come in terms of financial compensation, contacts, experience, work environment, and more. If someone wants a Fortran programmer and I’d like to move away from that technology, the other aspects of the project had better be good enough to justify having more knowledge about Fortran and not being able to do something else.

I’ll have more to say on formal skill models on Thursday.

How do you think about opportunities and skill acquisition? What did I miss or overgeneralize? Thank you for reading and leave a comment with your thoughts!

Original article: How to Look Like You Can Accurately Predict the Future of Technology

Here are some indicators that there is work that you need to do that is not captured in your current project management system. They should work well with almost any agile project management system. It’s a good way of finding and capturing latent stories for people on the project to see.

Patterns to watch for

“We need to revisit this in October.” or “We should probably do this at some point.”

Create a story for this item. Regardless of when you revisit the item, it’s nice to visualize the work that you believe you should do at some point. This can be effectively prioritized against the other work. You capture that you have something to do and can plan around it. This is useful in capturing work expansion as it happens.

“This isn’t perfect, but it works for now.”

Add a task to refine whatever the item is. I’m a big fan of progressive enhancement for stories. Get the basic thing done, and then you can add polish later.

“Hmm, that’s a bug, but I don’t want to fix it right now since I’m trying to finish something else.”

You can quickly add this. Put a quick description of where you were, what you did, what you saw and what you expected to see instead. If you want, speculate on what might have caused the problem. Then you can move on knowing it will be taken care of soon.

“I have this crazy idea that I haven’t discussed with the team”

Don’t add this as a story, yet. You’re only cluttering up the backlog, making it less valuable. First discuss it with the team, and if it is something that you plan on getting to soon, you can add it.

A long discussion in the group chat room or an important email

If there are things that pertain to the story that you are working on or will be working on, copy and paste the direct text or a public link to the text that is relevant. If there are other documents or relevant images, link these as well. Especially with the chat room, you are already having these conversations and making decisions, so you might as well put these somewhere so that everyone will see the conversation when in the right context. No need to have the same conversation twice or need to hunt through a long series of emails to get to the relevant information.

Other thoughts

I think that this technique should be coupled with good backlog management to ensure that the highest priority items are being done and obsolete stories are being culled. If your backlog is too big, you will waste time and energy just managing it. Consider trimming it aggressively. Any truly important things will keep coming back.

I find that cultivating this practice ensures that the team communicates well and everyone knows about how much important work remains to be done. There’s much less “oh yeah, I forgot to include you on that conversation.” It makes the ephemeral more concrete, and leads to people trusting that what is in the system is very close to what actually needs to be done.

When do you add something to your list of things to do? When do you wait to add something?

Original article: Spotting Hidden Stories

My thoughts

The key consideration in my mind is something along the lines of BATNA (best alternative to a negotiated agreement.) This concept applies to many business situations. In order to effectively negotiate with someone, you need to realize your next best alternative to negotiating. Perhaps your company is in good shape, and the deal would only be slightly beneficial. This puts you in a better negotiating position because you know that you can walk away from the deal without worrying. If your best alternative is your company going under, you are more likely to try to make the deal, even if it is at a slight disadvantage to you.

How does this apply to technical cofounders? Simple. They have a lot of alternatives to joining your early-stage company. They could do lucrative consulting or contracting. They could be working for better equity stakes at other companies. They might want to start their own company instead. Hmm, 5% equity at your company or 100% equity at their own company? Why would they work for a split of equity when they could be bringing down cash money for contracting, regardless of the success of the eventual product?

The meaning of this is that the company that an entrepreneurially minded developer joins needs to be pretty darn good. If you’re looking to recruit/enlist others to an idea with no product or no traction, it starts with you. Learn how to do as much as possible, and show that you can hustle. Learn how to code to throw a prototype together, and if you don’t do that, learn how to do some wireframes or at least talk with engineers. There are many tools out there that will get you most of the way, and you should gain experience using them so you can bust them out whenever necessary to get your startup moving along. You should know that people who know how to code Ruby on Rails probably have done some database work—be active in the local entrepreneur circles as well as the local tech circles to start getting your bearings.

Why should business cofounders in the technology industry understand tech well? Well, take it from Paul Graham:

In a technology startup, which most startups are, the founders should include technical people. During the Internet Bubble there were a number of startups founded by business people who then went looking for hackers to create their product for them. This doesn’t work well. Business people are bad at deciding what to do with technology, because they don’t know what the options are, or which kinds of problems are hard and which are easy. And when business people try to hire hackers, they can’t tell which ones are good. Even other hackers have a hard time doing that. For business people it’s roulette.
– Paul Graham, in 2005

The other main point is to demonstrate that you have some hustle. Do you have a record of being able to raise money? Do you have contacts in the industry you are interested in working in? Perhaps something else that the tech cofounder doesn’t already have or is not interested in. And so forth.

The posts

Andrew Chen’s post

Seth’s blog post about this

An IndyStartup post about this general topic

A good Hacker News post that a business-minded guy put out there. This is the example of how to do it right (hustle, knowledge, and social proof in the comments to boot.)

Interesting series on becoming your own tech cofounder

What if 1000 entrepreneurs learned to code just a little instead of lamenting the lack of engineers?

An interesting flowchart of tech cofounder equity. Potentially the most suited to the engineering mind.

Excellent piece on how to evaluate any company in its early stages, from a developer’s perspective generally. Get in their shoes!

Survey of actual developers. Again, this is pure gold if you want to understand what technical cofounders or early stage employees are thinking about and motivated by. How they look at potential companies and the “biz guys”.

Beating a dead horse by now, but another post about working for free and what developers look for in a business cofounder.

Last one!

What are your thoughts on this? Post a comment below, and thanks for reading!

Original article: “Finding A Technical Cofounder” Blog Roundup

Research

At the startup that I just worked at (RewardSnap), we decided to create a game to encourage people to do crowdsourcing of deal ratings. Instead of just crafting a game from scratch, I decided to do a bit of research into the mechanics of modern games. I figured there were companies like Zynga out there that were doing cutting-edge work on viral loops and making games engaging to people. Why not learn from others before setting off on a path that I had little knowledge about?

As I researched, I stumbled over Game-Based Marketing. It was an interesting look into the psychology and history of games for business purposes. Throughout history games and gimmicks have been used to sell merchandise and reward loyal customers. Everything from buy ten get one free, to loyalty cards, to frequent flier programs, to more modern alternatives like Foursquare. Frequent flier programs, in particular, are driven by status more than economic matters. People will literally go out of their way to take flights that earn them extra miles, in an effort to get a higher ranking in the program. If you’ve seen the movie Up In The Air with George Clooney, you might have an idea what this is like.

There was a discussion of Bartle’s player types (Achiever, Explorer, Socializer, Killer). Different people play games for different reasons. However, these archetypes are not evenly distributed in the general population. Many more people play games to socialize than to, say, kill others. In addition, people generally play games for status first, then access, then power, and lastly, stuff. It’s unfortunate this acronym is SAPS… So instead of motivating people by giving away a television, it would be far better to motivate them by giving them in-game, or real-life, power (and so forth). As a slight extrapolation, people want to be respected and able to have sex on demand more than they want more than getting material possessions.

Our Game

At RewardSnap, we set up a points-based game, where the maximum number of points for rating a deal was 100. There was a naive leaderboard that showed just the top ten overall, and all users were anonymous because we didn’t implement login until later on. We would just highlight your user id if you were on the leaderboard. To get on the leaderboard, some people scored tens of thousands of points, with a few people earning over hundreds of thousands of points. This means that people were rating thousands of deals for free to get on an anonymous leaderboard in a small game universe. Tweet

One person would rate a bunch of deals, and then the next day someone else would try to catch up and beat them. To me, the results were surprising. Rating a bunch of deals in a game was not something that I think I personally would have done. However, I’m sure there are a bunch of games that I played way too much for reason alone to make sense. It felt like we were hacking human motivation, and it was really strange to see the results. I think that there is a lot of deep behavioral psychology, intricate social , and motivational hacks at work in gamification. It felt spooky because we were playing with dark magics, things that we have yet to fully understand and that have great potential power.

One key takeaway was making sure that the incentives in the game corresponded to the business purpose that you wanted to achieve. We got a lot more action than I thought we would through just a simple leaderboard mechanism, although the incentives ended up being poorly aligned. The first rater of a deal would get a bunch of points regardless of their rating of a deal, and so their rating didn’t matter. They would just spam (in the gamer-speak sense) the “10″ rating since it was closest to the next deal button, and do this hundreds of times without looking at the deal at all. Future voters would get points based on the crowd average, so the first voter would skew the points rating all of the deals in one sitting. It ended up that the ratings on the deals were not really accurate, thus undermining the crowdsourcing of the deals and thwarting our business goals. However, this example was more of an implementation failure than a failure of gamification in general.

Extensions

While it’s a bit nefarious to use game motivations to get people to buy stuff, why not use the principles to try to get people to do things that are in their best interests? Cue the whole “with great power comes great responsibility” quote. Modern businesses like Health Month are trying approaches along these lines. Straightforward extensions include using games to motivate yourself to work on personal projects, clean the house, improve your community, and other useful activities.

Sometimes it’s hard to see the light at the end of the tunnel. It’s easier and more fun in the short term to play Farmville for an hour than it is to contribute meaningful significant work in an hour. Why work hard now when I can just slack off and play word games with friends online? But in the long run, it’s sad to see so much potential be wasted. Everyone needs downtime, but maybe we can do more with these motivational hacks. Why shouldn’t mind-numbing work be gamified to make it more interesting to those who are participating in it? Can we make seemingly difficult work like writing books or starting businesses be more like a game by providing smaller milestones and more effective feedback? Dan Pink in Drive has the workplace in mind when considering motivation. Interesting ideas to consider.

Have you had any experiences with gamification? What are the most addicting game mechanics, and how might you use them to better your life? Have you used Health Month or a similar social/motivational game? Post a comment below!

Original article: Gamification Is Not Entirely Bullshit

Immediacy and Inspiration

It’s more useful to write about experiences at a recent conference right now instead of two months from now. The time delay not only dampens memory, it also weakens excitement. It definitely helps to write about things when I am first excited or think about them, because once the enthusiasm fades it feels more difficult.

Topics that I once thought were fascinating are no longer so after I have been exposed to them for awhile. Strike while you are inspired with learning, because after that energy passes, you are less likely to be interested in it because you have already internalized the concepts. It’s hard to get fired up about something that you see as obvious. Here is a great summary of this idea.

I internally model this as your brain being in roughly a steady state. Something comes around that shakes up your mental models, and the resultant attempt to put your brain back into equilibrium causes a great deal of energy to be put off. After this happens, it’s tough to recreate the level of energy that happened, and it’s also hard to difficult to remember what your brain state previously was.

This goes back to Steve Pavlina’s concept of writing within 48 hours of getting the idea:

I don’t maintain a list of article ideas, I don’t actively brainstorm ideas in advance, and I generally don’t ask for suggestions. I’ve done all of those things in the past, but they don’t work well for me in practice. At one point I had a list of about 200 new article ideas. When I scanned it for something to write about, I was usually bored by everything on it.

If I get a suggestion from someone for a new article, I’ll normally write about it that same day if it excites me. Otherwise I simply let it go. Ideas by themselves have no value to me. There’s an infinite supply of ideas. The present-moment inspired ideas are the ones worth exploring.

Inspirational energy has a half life of about 24 hours. If I act on an idea immediately (or at least within the first few hours), I feel optimally motivated, and I can surf that wave of energy all the way to clicking “Publish.” If I sit on an idea for one day, I feel only half as inspired by it, and I have to paddle a lot more to get it done. If I sit on it for 2 days, the inspiration level has dropped by 75%, and for all practical purposes, the idea is dead. If I try to write it at that point, it feels like pulling teeth. It’s much better for me to let it go and wait for a fresh wave. There will always be another wave, so there’s no need to chase the ones I missed.

Why Writing Backlogs Are Harmful

One problem with maintaining a backlog of things to write about is that the overhead of managing all of those ideas. There is too much work in process, and thinking about too many things causes thrashing. This reminds me of my post on limiting reading work in progress and books in progress.

Keeping a backlog of writing ideas becomes especially problematic when a long lead time between when the ideas are written down and when they are implemented occurs. Often I’ll forget what I was thinking about when I wrote a nugget for a post seed. Or I will read a book and have to re-read parts of it to get the context back. This process causes waste.

It’s certainly possible for cutting-edge ideas to become stale over time. This is also a form of waste.

Of course, it can be tough to get important things done while making time to write. Queueing by utilizing a backlog is one potential path, but a better solution seems to be more frequent and regular writing. By just sitting down and getting the ideas out there right after a new association is made, better writing can actually happen with less effort.

I think having less of a backlog contrasts a bit with the Fieldstone Method of Writing by one of my favorite authors, Jerry Weinberg. However, there seems to be some overlap, in that action with inspiration is easier than action without inspriation.

Do you find that you have too many ideas for posts, or too few? If too few, do you want some ideas?

Original article: The Case Against Writing Backlogs

Pregame

Make sure you have alerted friends and acquaintances about the weekend so that they know they probably won’t see much of you. This helps clear any potential distractions. It definitely helps to clear your plate as much as possible. At one of the competitions I had to fix something at work that couldn’t wait, and it took half of Saturday up. As you can imagine, it was frustrating for me and I wasn’t much help to the team.

Before the event might be a good time to start eliciting help for electronic voting. Something along the lines of, “hey, I’m doing a business competition this weekend, and part of our final score comes down to people texting a certain number.”

For the sake of everyone at the event, if you are pitching an idea, do some basic groundwork on the idea. Nobody wants to hear your pitch if the idea has already been done or is way too big for a startup weekend or is mumbled. You are just wasting everyone’s time. If you have an original take on an existing idea, fine. Just make sure you know enough about the environment you are considering working in to actually know about prior art. An hour of your time saves sixty people from hearing and voting on a minute pitch. It might sound equivalent, but it’s a net gain in terms of attention and energy. There were about forty pitches at the last startup weekend that needed to later be voted on, which took time.

Pitches

Along the same lines, when at the pitches, listen for ideas that are pretty well-defined and that preferably have some sort of validation already. About the worst thing you can do is spend half of the weekend figuring out what you actually want to work on. About as bad is trying to do something for awhile and then basic research suggests that the idea has already been executed well by someone else. At that point the team flails for a few hours. Not a good start.

I generally pitch something that meets the criteria above and/or look for an idea and team leader that I think I will be able to work well with. I also check out the people who are joining the team and try to make sure that they are an impedance match. Talking with people before the event gives an idea of who I can most easily work with. You don’t have much time to butt heads, so picking a good team is really useful. Plus, nobody wants to spend the whole weekend working without having a little fun. I want a good story to tell, and picking a bad team, even if only for a weekend, is not a fun story to relive.

If you are just doing a small event, the same pitching process happens, and you can just pick the best idea out of the ones that you have come up with. Make sure to write down the other good ones in the event that you are going to do another event and want some ideas.

A New Team

Being productive with a team of strangers works best when you get off to a good start. Here are some patterns that I’ve observed.

Go around and introduce yourself and explain why you are interested in working on this idea. This lets everyone get to know each other, notice any biases or preconceived notions, and generally start forming around the idea of working on a shared project together. You can see why everyone picked this idea and team as the one they wanted to work on, and it leads effortlessly into the next time block.

This time period is always interesting because people may still join or leave the team. Just stay focused on the process, and the introductions and problem solving will work themselves out.

Next, everyone goes around and says at a high level what they think the idea is as they heard it from the person who pitched it. This puts the idea out there in a few different forms. After this comes a period of adjusting to the different viewpoints and emphases. Hopefully everyone is generally on the same page, and gelling occurs as you work out the key things that need to happen.

Generally at this point, it makes sense to solidify the problem you are trying to solve. Any talk of product or solution should be written down on a separate sheet of paper, preferably at the other side of the room. You must figure out the problem you are trying to solve before you can reasonably attempt to solve it. This will help marketing and development efforts greatly. You may identify many different problems or potential stakeholders, but for the sake of time it makes sense to focus only on the most valuable or easiest segment.

At this point in the process, I think it makes sense to take a step back and do some administrivia. Figure out who will be your team communicator that talks with advisors or other teams and communicates at startup weekend status update meetings. These can consume a lot of time, so it’s best to have one person to handle this. This person is still involved in the workings of the startup, and also has this extra role.

Keeping with administrative tasks, one person should be the head time keeper, in charge of letting everyone know when the next meal or meeting is. At this time, go over the whole weekend and get a lay of the land. You want to budget enough time for everything that you want to do during the weekend. Ask everyone if they are free for the whole weekend. Maybe someone has a soccer game that they need to watch, maybe someone has a party that will take a couple of hours. It’s useful to know these because then it isn’t a surprise and everyone feels that they can do what they need to do without being “that guy”.

Are We At The Solution Part Yet?

Well, if you are using a lean startup methodology (generally most applicable to Lean Startup Machine events), now is the time to validate that this is actually a valuable problem to solve. It’s part of producing the value that you need to produce (validated learning.)

Next, figure out a potential solution path. This should include what specifically you are going to build next, what the goal is for the weekend, and extensions. It’s good to start with a vision of greatness and then taper it down so you can show some progress. For more tips on defining the solution, check out Jared Brown’s post on defining the message of your startup.

If you are using lean startup techniques, at this time you should validate as you are building the solution to ensure that you are building the right thing and that it resonates with people.

Iteratively build until you just about run out of time. I suppose not much needs to be said about this.

Finally, work on the pitch to make sure that you don’t blow your time. Often you will only get a few minutes to describe what you did during the whole weekend to a group of people that has heard nothing of your idea. I’ve seen way too many teams blow this with irrelevant information. You are completely wasting your time if you talk about any of the people on your team unless they happen to be super-famous. The judges don’t care about who is on your team, they want to see what you got done or learned during the weekend.

Although I recommend practicing the final presentation a few times, it’s definitely not enough to have a good pitch and no product. A demo is worth a thousand words, which happens to save you quite a bit of time. You need to have something to show. If you can’t make a full product, make a prototype. If you can’t get to a prototype, lay out some screenflows. Any artifact that represents your thinking and the conversations you’ve had is better than just words. Arguably the screenflows should come before the prototype so that at any point you have something that best represents your product.

Random Thoughts And Question

I’d enjoy seeing some more non-tech startups at startup weekends, and even working on one. Also, some more non-profit or philanthropic companies would be interesting. The key here is coming up with a business model and proving the validity. It seems like this would be doable in a weekend.

Have you done a startup weekend? Does this experience relate to what you have seen? I haven’t won any, so maybe I’m going about this all wrong…

Original article: Startup Weekend Patterns

I could wait two years until someone decides I’m ready for the next level, or I can decide that I’m ready—experience be damned. At a certain point, more book learning or current level learning isn’t helpful.

I could talk myself out of taking the next opportunity, or I can just do it and try my very best.

I could whisper to myself that once I learn X, then I’ll finally be able to do that thing that fascinates me. (Hint: X usually changes to Y once you know X. Or you say that you don’t know X well enough yet. And repeat.) I’d rather try using what I know and learning just-in-time and take a chance that I won’t figure it out in time.

Whether adventures are deemed a success or failure, I learn more about myself and gain more skills than had I taken the more known route. What’s more, I gain experience in the skill of advancing by my own will.

One problem with coasting is the opportunity cost of not doing something more interesting or valuable. The best are continually improving, so by standing still you are going backward by comparison. If you are in the top 1% of the world at something, there are still sixty million people to compete with.

When you can’t really fail, there is no downside. However, this means there’s probably little potential upside. Exposing yourself to risk is the key to getting disproportionately higher upsides.

Financial advisors say to take risks with your 401k when you’re young because you can make more money and there is still time to recover from setbacks. I say to be risky with your career when you’re young, because you have a lot of time to use what you learn, and that on average you’ll make more impact (and money) in the long run.

I think most risks are far overstated. Using the analogy above, always taking the safe route is actually more risky in the long run.

Therefore, I propose a life heuristic: if there is little to no chance of failure in what you are currently doing, you are missing out on something.

The actionable advice of this is: actively seek to put yourself in a position where you can fail.

If I am wrong about my abilities or the amount of actual risk, I want to know this as soon as possible so that I can course-correct. Putting myself in positions where I can fail lets me fight my way out of problems. I’ll learn by having the chance to mess up, and then succeed.

Original article: Put Yourself In A Position Where You Can Fail

I’m sorry I wrote such a long letter. I did not have the time to write a short one.
– Abraham Lincoln

For a long time, I strove to be efficient in communication. I would carefully consider the right words for things, especially when writing. But I realize now that good communication should have some redundancy.

Most of the time, the point of communicating is to convey information. Of course, there are other reasons people might converse. Redundancy is nice because it gets the message across eventually. Communication is inherently a very lossy channel.

For example, in Permission Marketing, Seth Godin says “you have to run an ad twenty-seven times against one individual before it has its desired impact. Why? Because only one out of nine ads is seen, and you’ve got to see it at least three times before it sinks in.” (87)

You can apply this to your own communications. One tweet or one phone call or even one meaningful conversation probably won’t get the point across.

Good teachers are redundant. They might approach the same subject from different angles by giving an audio, tactile, as well as visual learning experience.

Most religious leaders are probably pretty redundant. How many ways can you express the same fundamental truths?

An interesting side effect of being alright with redundancy makes for more personable communication. I am not as worried about getting the exact right words at all times, because I know that with time, the errors will work themselves out. As a result, conversations are less curt, which enables both people to feel safe.

Interestingly, people change their minds over time. If you assume they still think and do the same things as when you last talked to them, you are likely incorrect. So while you might have the same conversation twice, you might just learn something new or say something in a way that the other person understands better than the first time you said it.

Instead of getting bothered at needing to repeat myself, I should welcome the opportunity to say how I feel and what I believe. (Perhaps this is for relatives who haven’t adjusted to my internal perception of myself.)

Even if you ask the same questions multiple times, you might hear something you didn’t the first time, or the other person might be in a different state of mind than the last time.

The other concept that this relates to is to just start explaining what I am thinking before worrying about whether it is the best way to express the ideas within. An article doesn’t need to be perfect before it can help someone. People who really want the value are ready to read past typos and poor construction.

So be mildly redundant. It might be more useful than you think.

Original article: Redundant Communication Redundancy