Being understood versus understanding
May 30, 2007
Posted by on
A friend pointed me to this great article
from Business Week talking about Ford’s new CEO, Alan Mullaly, and some of Mullaly’s experiences in trying to change the culture within Ford. I found one paragraph
that correlated to some of my past experiences as a software developer:
After a couple of hours on the firing line, Ford’s engineers got defensive.
Interrupting the testers, they started airing their side of the story in front
of the new boss. Sensing that the meeting was deteriorating, Mulally says he
handed each one a pad and pen. “You know what? Let’s just listen and take
notes,” he said. The episode was a perfect illustration of what Mulally
considers one of Ford’s major problems: the tendency of employees to rationalize
mistakes instead of fixing them. “We seek to be understood more than we seek to
understand,” he observes.
Developers have all found themselves justifying certain design decisions in an effort to
complete tasks and move on. This is a natural part of the process of software
development. But if their focus changes from understanding their users to making their users
accept their design, then their software quality tends to suffer. It’s a difficult balance to maintain.
I find that following the last two points of the Agile Manifesto would go a long way towards maintaining this balance:
Customer collaboration over contract negotiation
Responding to change over following a plan
What are your strategies for understanding rather than being understood?