What I Took Away from Creativity, Inc
After many friends independently suggested this book, I finally bought Creativity, Inc by Ed Catmull (Pixar) at a bookstore in SFO. Even though the book is about Pixar’s process to foster creativity, it is actually extremely applicable to software engineering and the general process of developing products and company culture. So I figured I’d share some of my personal takeaways. Disclaimer: I don’t claim to accurately reflect the author’s point of view. These are just some of my learnings and thoughts as I read the book.
Also, in case it isn’t clear, spoiler alert.
Encouraging Constructive Feedback
The main idea repeated time and again in Creativity, Inc is that solutions can come from anyone and everyone should feel responsibility and ownership to fix problems they see. That being said, it’s often difficult to build and maintain the culture of constructive criticism because (1) people don’t want to be labelled as complainers, (2) it’s human nature to want to avoid hurting others’ feelings, and (3) people often self censor and convince themselves that their feedbacks are probably wrong.
Here are some learnings for how to encourage constructive feedback at every level:
- Acknowledge that establishing and maintaining core values like candor requires constant monitoring and encouraging. It’s not once and for all.
- At a company level, Pixar has a Braintrust consisting of leaders in the company to provide feedback to directors on different iterations of the movies. Braintrust does not have power to make decisions on the film. It points out problems, but it’s up to the directors to decide what to do with the feedback.
- Each movie meets with Braintrust many times throughout its development process, and gets feedback every step of the way.
- The key to a successful Braintrust or feedback session is to be additive, not competitive. Competitive = either you win or lose the argument. Additive = everyone has something to contribute, even if their ideas mostly just contributed to fueling the discussion.
- Managers should be candid with their reports instead of maintaining secrecy. Without this, it is difficult to instill trust.
- Encourage everyone to showcase incomplete work and share rough-not-completely-thought-out feedback. It’s important to make sure people don’t self censor.
- In encouraging tough feedback, acknowledge that some feedback will feel personal and tough to read, but it is incredibly helpful and has led to real improvements.
- Balance and conflict amongst each functional group (i.e. design, engineering, PM) is essential and it’s the management’s responsibility to maintain that. If a particular group “wins” by getting what it wants, i.e. “making the most scalable or fast product”, the product as a whole loses, i.e. “might not have important features.”
Product Development Process & Taking Risks
The core idea here is every product (in this case, Pixar movie) that we think of as brilliant or creative was at some point an “ugly baby,” easily dismissed by people who prematurely judged it.
- Ideas are not singular. They are forged through thousands of decisions by dozens of people. There are no lone geniuses sitting in a room conceiving of the best ideas or designs; people discover and realize their vision through dedicated, protracted struggles.
- The product building and iteration process is inherently messy. For example, it would be unreasonable for Pixar to require that the whole script be finalized before production begins. Having the most efficient process is not the goal, making a great product is. Specifically, the pursuit of efficiency might result in ugly babies not having room to grow.
- Research trips and User research challenge our preconceived notions and keeps our cliches at bay. It helps us understand our customers much more, even though we might not know what we are looking for at first.
- If you are not experiencing failures, that means you have been trying too hard to avoid failures and not learning, experimenting, or exploring enough.
- Empower people to make decisions & try out risky projects. Don’t instill the fear of making mistakes.
- Instead of avoiding failures, make it less expensive to fail by having a cheap and safe way to experiment. Management’s job is not to prevent risk, but to build the ability to recover.
- Hack weeks and short risky projects let us experiment, take risks, and encourage people to have broader product experiences, and work with people they might not have otherwise to forge bonds.
Fear of change is a powerful force. We should always be watching out for that. This is especially true when the company has been successful. Success convinces us that we are right and shuts down alternative view points. We should be careful of that. Avoid making conclusions and pattern matching too early. You might be correlating success with a few random events.
Even amid success, we should always be looking for challenges ahead and try to resolve them.
Do postmortems after each project because they: (1) consolidate what’s been learned and fix things you might not have time to earlier, (2) teach others who weren’t there, (3) don’t let resentment fester, (4) use the schedule to force self reflection, and (5) let us ask the right questions on the next project.
Lessons to ensure productive postmortems: (1) vary the way you conduct them, otherwise, people might not learn new lessons, (2) people have an aversion to being critical; soften the process by, say, asking people to list 5 things that went well and 5 things that didn’t, (3) make use of data and measure progress, but know that data isn’t everything.
Problem Solving Session
One of the final chapters is dedicated to “Notes Day” where everyone drops what they would be doing, and instead goes sessions t0 brainstorm solutions to problems at the company. I can’t really get my head around the phrase Notes Day, so I’ll just call it “problem solving session” instead.
Recipe of a good “problem-solving session” (or brainstorm, etc):
- a good prompt, i.e. “imagine we achieved … in 2017, how did we do it?”, or “we propose to …”. These prompts should be determined by polling people in advance and categorizing important issues to solve.
- ideas and discussion.
- try to answer “what benefits does this idea have?”, “what drawbacks?”
- write down the next steps, “who should pitch this idea?”, “who’s the best audience for this?”
“Problem-solving day” worked at Pixar because: (1) there were clear and focused goals for each discussion, (2) it was championed by leadership/people who can actually make changes, (3) employees organized it and brought passion and context.
These are some tips specifically for management, and since I’m not a manager, I’ll just note them here for anyone else who’s interested:
- The future is unmade and we must create it.
- The right team is extremely important; a good team isn’t just about the smartest individuals in it, but how everyone comes together and complement each other.
- Don’t be afraid to hire people smarter than you or do things that make you insecure.
- When promoting new managers, pair them up with experienced managers to mentor them for an extended period of time.
- Before imposing any limitations or restrictions, ask how they helps people solve problems, not how they prevent people from screwing up.
- Company offsites and random classes (i.e. drawing, stand up comedy) help people socialize with others and be put into the beginner learning mentality, which helps the company in the long run.
- In an merger and acquisition, it’s important to make sure neither party feel like they have lost.
- Cash bonuses are desirable, but having someone they respect look them in the eye and sincerely say “Thank you” is also immensely rewarding. For example, John and Ed would personally present bonus checks to employees when they met their goals.
- The book never directly says this, but it seems to me like the Pixar top management directly addresses the entire company a lot to connect values at the company with the specific problem, task, or situation at hand (i.e. Notes Day), to both motivate people to solve the problem and reiterate values.
Thanks Sashko Stubailo for insisting that I write more and proof reading this. You are the bomb.