
Pixar: Getting over embarrassment - 16BitTons
http://blog.protoshare.com/2011/04/getting-over-embarrassment-and-getting-done/
======
chrisaycock
Summary of Ed's talk:

\- 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.

~~~
icefox
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.

------
alexqgb
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.

~~~
VMG
> 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?

~~~
alexqgb
In the case of $100 million movies made by studios that are the better part of
a 100 years old? No, not even close.

~~~
AndrewDucker
Studios aren't equivalent to startups here - that would be the
producer/director who make the movie. Studios are effectively VCs.

------
lotharbot
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.

------
hoopadoop
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.

~~~
mikecane
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.]

~~~
officemonkey
>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.

~~~
mikecane
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.

------
Wickk
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.

------
ams6110
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.

~~~
michaelpinto
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.

------
Brashman
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.

~~~
alexqgb
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.

~~~
blahedo
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/>

------
prayag
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.

------
paufernandez
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!

------
hxf148
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.

