The other day Grant Fritchey (Blog | @GFritchey) linked out the video below. It’s a quick little video, that isn’t about the nail. As I watched it, it spoke volumes to me from both personal and professional experiences. Check it out quick and then I’ll continue this blog post below.
It’s Not About the Nail from Jason Headley on Vimeo.
There are so many ways you can look at this video, but let’s be honest, it is about the nail. The problem is, she doesn’t want to hear about that from anyone else. She is looking for someone to listen and have empathy while she is on her journey to discovering that the problem is the nail. And telling her what the problem is, isn’t completing the journey for her, it is delaying it even longer.
This might sound quite hokey, but we come across this constantly in our professional lives. You might be working on project where the architect selected a terrible foundation to build the application on. And it may seem no amount of arguing or discussion will move their position. Discussion may actually have a negative effect and push the architect to defend the choices even more rigidly.
In another situation, you might review a database and see that there are no indexes or excessive indexes. When there are performance issues, it might be obvious to add or remove some indexes would solve the problem. But the lead developer, who brought the application up from an idea to a multi-server million dollar deployment might defend the design decisions as though their job depended on it.
The thing is, maybe their jobs do depend on these positions and decisions. It could be, that by making those choices, the cemented their expertise within the organization. But what are we to do?
We could argue with them over the choices, but that won’t long help our careers. A number of years ago, I had a friend who argued with his manager about the investment they were making in Microsoft Office over WordPerfect. My friend was adamant that the features of WordPerfect were superior and would provide long lists of the benefits. What he failed to listen to was the fact that the purchasing decision was made by the CIO and he was directly attacking that decision. And those questions cost him his job.
A better solution is to leverage a little listening skills and displaying some empathy, we might be able to figure out why they are taking their current position and let them discover the foolishness of their ways. There is less harm when you let, or help, the person discover the facts that support your position. You can share information that you know that supports other view points without discussing their view point.
Of course, in the end you might find that the position or architecture will never change. At that point, you need to decide whether you can live with it. If you can, then just let it drop and consider it a risk or constraint in all ongoing projects. And if not, you may need to move on. No matter what you choose to do, be sure to take caution not to let the nail poke your eye out.
