Pixar: Getting over embarrassment

Summary of Ed's talk:<p>- Success hides problems. Big organizations fall slowly.<p>- Daily reviews. Everybody gets reviewed everyday; this removes the embarrassment factor so that no one waits until "it's perfect" before presenting.<p>- Communication structure is not the same as organizational structure. A firm might require a strict hierarchy to ensure control, but that doesn't mean everyone should be prevented from talking to anyone else.<p>- The only measurement that matters is whether the team functions together.<p>- Don't copy successful products, even if they're your own product. Either invent something new or fix an unsuccessful product.

That whole talk is a gem of the first order. Don't skip over it thinking it's JUST about iteration. The segment on what it means to keep your crises small is especially good. It's also the single best explanation I've seen as to why Pixar has never released a dud.<p>Meanwhile, their less enlightened, less capable, and frankly less humble competition just assumes that most movies will end up losing money, and that what REALLY matters is getting a handful of hits that can offset endemic failure.

The tendency to only show things "when they're done" means we only produce things we're able to complete without any help.<p>By getting over the embarrassment of showing someone a product that sucks or isn't complete, we position ourselves to get feedback and assistance -- which means we can make things that we couldn't have made without help.

I worked at a world famous design studio. I was horrified to discover that there could be no 'brain storming' - everything you said or every drawing you showed would be judged and held against you. It made it almost impossible for someone to come up with a truly creative solution. You had to be very careful and measured about everything you said.

Very important thing to get over. In concerns to programming: The majority of what you code will look like shit to most people. Who cares. Do it anyway and learn.

This is interesting, because I've heard at Apple you don't demo anything that is not as polished as you can make it. E.g. layout perfect, no "Lorum ipsum" text, everything must be thought-through and a realistic example use case.

My issue with being evaluated very often is that I find myself fixing small things so I have something to show rather than working on bigger issues.<p>However, the "just do it" idea of the post is great.

This is actually analogous to that we teach in User Interface Design 101. There are distinct advantages of showing very early stage prototypes. When we show it to potential users they would be perfectly honest about what they don't like. Try it with a very finished product and the users would be polite and not mention the issues they faced.<p>Always, always start with putting a very bad replication of the product in front of your users. Paper prototypes work very well.

In my case this is great advice, thanks for sharing.<p>I've been meaning to polish it but... I think I'm going to put all my code in github now!

Love this, get out there, prototype, iterate, try things. The longer you wait to "release" the longer it will take you to be "done". If ever.