I watched a video recently about what it feels like to be an engineer in the corporate world. I found it extremely funny in no small part because it reminded me so much of some of my interactions as a computer programmer with salesmen, project managers, and clients/business people. Before I go too much further, please visit http://www.collegehumor.com/embed/6961066/how-it-feels-to-be-an-engineer-in-the-corporate-world-sketch, then come back. (I can't embed the image in the blog - from what I can tell only embed Google-owned YouTube video in a Google-owned Blogger blog. Go figure.)
Ok, you've watched the video? Don't get me wrong - the majority of my interactions with others weren't like this. Generally people are understanding of what is possible and what is not, and generally I've been able to build something that makes everyone happy. What struck me, though, is that when conversations go sideways, they do so because they were making the same mistake that the people in this video were making. Instead of focusing on the problem at hand, they were focusing on the means by which the solution should be delivered.
This mistake is fairly common. We all want to skip the problem definition phase and jump straight into the solution. It's not hard to see why. The client/line-of-business team thinks they know the problem and merely look to the engineers (software or otherwise) to implement the solution. The engineer team all too often is focused on how to implement what is being asked. Neither side has the knowledge to evaluate the solution's ability to solve the problem at hand.
Instead, we must all focus on defining the problem. Most of the time, once the problem is defined, talking about solutions isn't filled with conversations about what's possible and what's not, but instead is filled with talking about what is worth the effort. And the latter is a much easier and more pleasant conversation.
No comments:
Post a Comment