10/22/2013

Iron Man's Initial Resistance to Teamwork

Walking through the front entrance where I'm currently consulting as a transformation coach, stands a life size replica of Iron Man. I don't yet know the significance of why it is there, but i




Iron Man's existence begins with a child prodigy who grew up to be a pretentious, mostly egocentric engineering genius named Tony Stark.  During the movies, comics, and books, Stark takes on the Iron Man persona, saving people, being a hero, and letting his selfishness shine through.  He can do it all.  He is the one who is the genius. He doesn't want anyone else involved.

However, as things progress, it becomes apparent that Stark cannot do everything by himself.  He needs his friends, his assistant/lover, his community to help him.

As I work with and coach teams, and organizations, I see this same mentality.  Famous quotes I'm used to include:
     "We're getting the product out the door, something must be right..."
     "I'd rather just get my work done than have to worry about a process..."
     "Having code reviews is a waste of time; I know what I'm doing..."
     "I don't want anything else added that takes up more time..."


Think about Stark; if he had not received help, he would never have survived.  His attempts at working solo show this.  It makes sense that we want to work on our own, to get things out the door quickly without working with others, to not "waste" time.  What doesn't make sense is that there are defects not caught earlier, time wasted on fixing those escaped defects, making the time after you thought you were finished a waste of time.

Jarvis, Stark's computerized expert friend, warned Stark many times about the dangers faced with an unfinished product that wasn't fully tested.  The result was a near death experience for Stark.  It is our duty as a team member to hear what other people are saying, to want to work with others, to want to deliver the best quality product.  Let's stop being egotistical, selfish, and pretentious, and start being team oriented, accountable, and open to feedback.

TIPS:

  • Understand that unit testing, code reviews, and peer programming are not meant to be a way to monitor your work.  The purpose is to work as a team to try your hardest to uncover issues and deliver the highest quality product.
  • Accept feedback and work with the feedback given. If you don't agree with the feedback, make sure you know why by testing it out; see if it is a good idea or not.  You don't want to be using hand or foot jet repulsors and they stop to work while your flying.  
  • Respect each other within your team. There will be times when members of the team do not agree; that is perfectly okay.  Take the disagreements and use them to power the work to be the best it can be.

No comments:

Post a Comment