Iron Giant Thinking
A few weeks ago, I listened to a talk by Bob Sutton, author of Good Boss, Bad Boss and professor of Management Science and Engineering at Stanford University.
He tells a great story in his book about Brad Bird, director of The Incredibles and Iron Giant. (Interestingly, I freelanced at Disney at the Ink and Paint building when both Bird and Pixar’s John Lasseter were working at the studio but never met the animators.)
The story is about Bird’s experience working on the animated film Iron Giant. “The Iron Giant team worked on a climate of fear before Bird arrived, which he worked to repair by telling them:
As individual animators, we all have different strengths and weaknesses,
But if we can interconnect all our strengths, we are collectively the greatest
Animator on earth. So, I want you guys to speak up and drop your drawers.
We’re going to look at your scenes in front of everybody. Everyone will get
humiliated and encouraged together. If there is a solution, I want everyone to
hear the solution, so everyone adds it to their tool kit, I’m going to take my shot
at what I think will improve a scene, but if you see something different, go ahead
and disagree. I don’t know all the answers.
Sutton continues, “Bird’s statement drips with wisdom: It shows how much people need each other and the virtues of exposing one’s weaknesses. His line “Everyone will get humiliated and encouraged together” captures the essence of psychological safety.
I see a lot of companies where you sense the psychological safety net either doesn’t exist or is so infinitesimally small that both constructive confrontation and risk taking are rare events.
There is a balancing act that leaders have to do -- simultaneously remaining open and supportive but then having to make decision that is ultimately theirs. This high-wire act goes with the territory.
But when I see organizations that are closed or leaders that are closed or don’t encourage Iron Giant thinking, you can feel a different kind of tension. It’s a sweat of unexpressed ideas. Unchallenged assumptions. And a general inability to disagree, agreeably.
That's the tripwire for less productivity, faux collaboration and an us vs. them mentality.
Sutton sums up the story with some advice, “Fight for what you believe, but gracefully accept defeat.”
So, at your next meeting or group interaction, ask yourself, “Giant Problem or Iron Giant?”
Tech Republic has 10 great commandments for egoless programming. You don’t have to be a programmer to appreciate the Iron Giant thinking.
1. Understand and accept that you will make mistakes.
The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
2. You are not your code.
Remember that the entire point of a review is to find problems, and problems will be found. Don't take it personally when one is uncovered.
3. No matter how much "karate" you know, someone else will always know more.
Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it's not needed.
4. Don't rewrite code without consultation.
There's a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
5. Treat people who know less than you with respect, deference, and patience.
Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience.
6. The only constant in the world is change.
Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
7. The only true authority stems from knowledge, not from position.
Knowledge engenders authority, and authority engenders respect -- so if you want respect in an egoless environment, cultivate knowledge.
8. Fight for what you believe, but gracefully accept defeat.
Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don't take revenge or say, "I told you so" more than a few times at most, and don't make your dearly departed idea a martyr or rallying cry.
9. Don't be "the guy in the room."
Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
10. Critique code instead of people
Be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.


Reader Comments