Saying Yes Wed 11 Mar 09
Should we say Yes more often; or do we say Yes too often?
Seth Godin recently had a great blog post "Looking for yes" where he contrasted his experiences at the post office and Fedex. The post office personnel consistently looked for reason why they couldn't accept his package for shipment while the Fedex personnel recognized each issue but then went on to figure out a way to solve with the aim of making sure they could ship the package. It's an interesting perspective on customer service.
Godin went on to say "I don't think it should matter whether or not you're trying to make a profit. If you're out to provide a service, or organized to deliver a product, then look for a yes. At every interaction."
This reminded me of a post I made two years ago about Policy Parrots. This was based on Matt Moran's Policy Parrot stories about how we use our IT policies as an excuse for not doing something rather than trying to solve our customer's problem. In this post I also referenced an article by Ben Worthen [link no longer available].
Worthen quotes Rob Israel, CIO of the John C. Lincoln Health Network, who says “I’m the only person in IT allowed to say no.” His IT employees have only three options: approve a request, research it or pass it up to him.
In my post I offered up some suggestions how we can still have and use polices but maintain a positive customer service perspective.
The concept of always "Looking for yes" is a great one and I really think we should try to do this. However, as we all know, we can't say yes to everything and perhaps we need to rethink what we are saying yes to. While we shouldn't hide behind policies we might want to look at which project we say yes to.
I'm sure we've all seen projects that in hindsight were bad choices from the start. No doubt someone in IT said "yes" with the best of intention -- fulfilling a customer request. Often in cases like this we are really saying yes to a proposed solution rather than a true need.
Saying yes to a CRM implementation, an Access database, a new report is not necessarily the same as saying yes to helping a someone to manager their sales opportunities and contacts, or being able to sort and analyze data, or being able to monitor results and spot trends. It's not uncommon for customers to come to us with "solutions" in hand to be implemented rather than coming with problems asking for us to help solve them.
While, it is tempting to go down the easy path of always implementing the customer's solution it isn't always the best answer, as we've often learned the hard way.
My point in all of this is to suggest that yes we should be looking for yes, but we should be looking at the right issue. Finding the right issue is a matter of balance. Otherwise we end up making every request a major project. Sometimes setting up a simple Access database may actually be the right answer.
The hard part is in knowing when to go with the requested solution and when to dig deeper. It's not always easy but that's why they pay us the big bucks isn't it.
How do you know when to simply say yes to the request and when to say yes to the real issue?
"GRAFFITI YES" photo by Andy Welsh
If this topic was of interest, you might also like these: