In business, we tend to obsess over the "how" -- as in "Here's how to do it." Yet we rarely discuss the "why" -- as in "Here's why we're doing it." But it's often difficult to do something exceptionally well if we don't know the reasons we're doing it in the first place. People at work are thirsting for context, yearning to know that what they do contributes to a larger whole. And a powerful way to provide that context is to spend a little less time telling how and a little more time telling why. - Drive: The Surprising Truth About What Motivates Us by Daniel H. Pink.

This has to be one of the most profoundly apt statements I have read related to my work. Over the last few years, I have consistently found myself asking "why" when getting dictated dates or given the detailed manifest of the must-have features. Unfortunately the answers aren't usually very compelling or meaningful.

Help Me Help You

What I typically find more demotivating than dates and pre-designed features, is the lack space "outside the box" to try and solve a problem. In my ideal world, I want to collaborate with my customers and business leaders on a business problem. I want to talk about the problem, do some root cause analysis, and come back with some ideas on we can help. Knowing the business problem, the real why behind what we are doing, is very powerful. It often gives me many different ways to frame a solution.

Inspiration

When I was a younger lad, I remember one of my mentors telling me a story about the importance of root cause analysis. He relayed a story about an earlier time in the company when they were rolling out a new system to hospitals. They had the system at a pilot site and things were going well. Not too long into the pilot though, some concerns came up from the users. The users were saying they needed more installations of the system and some additional features; if it was every going to work in busier units. The engineering teams took the data and started analyzing. Everyone got very nervous. In order, to make the changes and add the installations they were going to have add some delay in delivery and even worse the increased installations were going to break the cost saving aspects of the new system. It seemed like a doomed project. Desperate times called for desperate measures, and someone had the ingenious idea of sending a few of the engineers to the pilot site to observe the customer usage. Within the first day, the engineers realized they just needed to move a printer from one end of the unit closer to the system. I think they ended up going to an office supply store and buying a second printer. But with that change, they eliminated the need for new features and extra installations.

Lessons Learned

After hearing that story a few times, a few ideas stuck with me. One was the hope that one day I might have enough common sense to think of a solution like buying an extra printer. The second idea was that, while the customer is always right in terms of having a problem, his or her solution is not always the best one. The third idea, was that knowing the real problem is far more valuable than knowing how to treat the symptoms. There was also a smaller moral in there about paying an engineer to sit around and watch something for day ultimately saving a product...but that is another blog post. Finally, I realized that a system is often more than just the sum of its features.

Motivation

Pulling this all back together, the most rewarding part about what I spend most of my life doing is solving problems. Finding a simple solution to a tricky problem is satisfying, but I don't just mean a cool design pattern or nifty implementation technique. I mean solving a real user or business problem. Having someone use that solution is what keeps me coming back for more. When the "finding" of the solution is taken out of the equation it becomes much less interesting. If it's doubtful the software will ever be used, or there are long delays in getting feedback on working software, it starts to feel like empty effort.