Pixar: Getting over embarrassment(blog.protoshare.com)
blog.protoshare.com
Pixar: Getting over embarrassment
http://blog.protoshare.com/2011/04/getting-over-embarrassment-and-getting-done/
11 comments
One thing I noted in the talk is that Pixar didn't force their employees to work over christmas before diving into fixing Toy Story 2. I have been close to two groups that have had to do this and it is clear that the morale hit is never worth it and those few extra days are talked about for years in a very negative light. What they did is just as important as what they didn't do.
"Success hides problems" -- that's great insight.
Scary that some things in an organization can be so successful that it hides the cancer of rotting code/processes for a long time.
Scary that some things in an organization can be so successful that it hides the cancer of rotting code/processes for a long time.
An interesting insight: He thought the key to Pixars success was that they knew that the story was the most important. Then he discovered that every studio says "the story is the most important", even the ones with crappy stories.
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.
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.
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.
> 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.
Without having watched the talk, isn't that the fail early, fail often startup mantra?
Without having watched the talk, isn't that the fail early, fail often startup mantra?
In the case of $100 million movies made by studios that are the better part of a 100 years old? No, not even close.
Studios aren't equivalent to startups here - that would be the producer/director who make the movie. Studios are effectively VCs.
A finished movie is a large and costly project. Fail early would be to scrap a movie project based on an early draft or storyboard. But his point is that every project starts out crappy, and then is gradually improved through the process. His story about Toy Story 2 is about how a failed project turned into a great project.
So I don't think he actually agrees with that mantra.
So I don't think he actually agrees with that mantra.
The tendency to only show things "when they're done" means we only produce things we're able to complete without any help.
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.
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.
[deleted]
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.
The key phrase is held against you. This means bad ideas were punished, giving people an incentive to not be risky. Whereas the point of Pixar's process is you don't have to punish bad ideas--they won't become consequential.
That's an impression I got from reading the post (no time to watch the video). I also thought: Well, how many times do you get to suck before they think you don't belong there? Some ideas do need time to percolate and encapsulating them in a soundbite can lead to rejection without understanding the underlying depth. [This was previously posted elsewhere minutes ago due to a mis-click.]
>Well, how many times do you get to suck before they think you don't belong there?
As often as possible. Everything I've ever read about creativity starts with some variation of "Do you want a good idea? First have lots of ideas."
As a manager, I don't have a problem with people "sucking". I have a lot of issues with people being lazy.
As often as possible. Everything I've ever read about creativity starts with some variation of "Do you want a good idea? First have lots of ideas."
As a manager, I don't have a problem with people "sucking". I have a lot of issues with people being lazy.
I want to also add: My comment might be misinterpreted to think the person sucking is someone who's incompetent. That's not what I meant at all. But anyone can have a run of plain bad ideas before they strike gold. Or even silver.
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.
It might depend on who you're giving the demo to. If it's an internal team phase things may be informal — but if you were presenting something for Steve it should be tight.
Actually, the Apple Human Interface Guidelines say:
"The best way to make sure your product meets the needs of your target audience is to expose your designs to the scrutiny of your users. Doing this during every phase of the design process can help reveal which features of your product work well and which need improvement."
http://bit.ly/aAOuwQ
"The best way to make sure your product meets the needs of your target audience is to expose your designs to the scrutiny of your users. Doing this during every phase of the design process can help reveal which features of your product work well and which need improvement."
http://bit.ly/aAOuwQ
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.
However, the "just do it" idea of the post is great.
However, the "just do it" idea of the post is great.
It's also important to remember who you're presenting to. If they're people who really understand the process, the constraints, and - most importantly - where they want the project to go, then the feedback is likely to be excellent. Indeed, the resulting conversations (and ideally, that's exactly what they are) can be some of the most creatively inspired bits of the process. Also, very productive, in that they are likely to focus on the removal of obstacles.
On the other hand, if you're presenting to people who really don't have a sense of the big picture (and who are often insecure about their position and judgement), you tend to anticipate their tendency to (a) fixate on small, rough bits and (b) issue VERY specific instructions about those elements (often, while ignoring the rest). This is the exact mechanism by which incompetent managers paralyze creative talent, reducing any project to a derivative effort that hews as close as legally possible to "whatever worked before." In this case, management IS the obstacle, and good luck getting them to remove themselves.
In these situations, you're no longer focused on the work. You're thinking about dodging bullets and managing up, hoping to find the best 'compromise' between a great creative solution, and the need to placate the fragile egos of people who probably don't belong in their jobs. The awesome thing about Pixar is that they really seem to get this, and invest considerably resources in creating and staffing the kind of environment where people CAN iterate freely.
On the other hand, if you're presenting to people who really don't have a sense of the big picture (and who are often insecure about their position and judgement), you tend to anticipate their tendency to (a) fixate on small, rough bits and (b) issue VERY specific instructions about those elements (often, while ignoring the rest). This is the exact mechanism by which incompetent managers paralyze creative talent, reducing any project to a derivative effort that hews as close as legally possible to "whatever worked before." In this case, management IS the obstacle, and good luck getting them to remove themselves.
In these situations, you're no longer focused on the work. You're thinking about dodging bullets and managing up, hoping to find the best 'compromise' between a great creative solution, and the need to placate the fragile egos of people who probably don't belong in their jobs. The awesome thing about Pixar is that they really seem to get this, and invest considerably resources in creating and staffing the kind of environment where people CAN iterate freely.
But the question is, would daily iteration reduce the rate of bikeshed[0] arguments? I guess I could imagine how it would make it worse, but it seems more likely that it would make it better: the people who know nothing about the process (and don't care) won't be at the daily meetings, and the people that know just a bit about the process will be there and will learn all the details of the big project (i.e. the atomic power plant, to continue the original metaphor).
[0] http://bikeshed.com/
[0] http://bikeshed.com/
One thing that might help is to prioritize "end-to-end", happy-path work highest. Once you've got the bare-bones, end-to-end functionality working, go back and start filling things in.
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.
Always, always start with putting a very bad replication of the product in front of your users. Paper prototypes work very well.
Always, always start with putting a very bad replication of the product in front of your users. Paper prototypes work very well.
[deleted]
In my case this is great advice, thanks for sharing.
I've been meaning to polish it but... I think I'm going to put all my code in github now!
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.
- Success hides problems. Big organizations fall slowly.
- Daily reviews. Everybody gets reviewed everyday; this removes the embarrassment factor so that no one waits until "it's perfect" before presenting.
- 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.
- The only measurement that matters is whether the team functions together.
- Don't copy successful products, even if they're your own product. Either invent something new or fix an unsuccessful product.