Are You a Policy Parrot?
I've been enjoying Matt Moran's stories about "when customer service personnel become policy education experts - explaining to you the policy versus listening and reasoning through your concern or situation." He calls them his Policy Parrot stories. We all have these stories. It is a common situation where have a problem and are extremely frustrated only to hear "Squawk! I'm sorry but our policy doesn't allow . . . Squawk!" The parrot label is very appropriate.
In hindsight these stories always seem humorous especially if someone else is the "victim". However, the fun soon disappears if we see ourselves in that story, not as the victim but as the parrot. Realizing that at times I've been a policy parrot is not a good feeling. However, as with so many other problem situations the first step in recovery is to recognize that you have a problem.
Reflecting back on earlier discussions of Shadow IT I talked about why users would often prefer to use Shadow IT instead of the formal IT organization. Specifically some of the reasons were ease of use (no forms or policies) and the responsiveness. And no policy parrots either!
I'd like a smaller laptop computer. Squawk! Sorry our policy says only there is only one size. Squawk!
I need more email storage space. Squawk! Sorry our policy says everyone is limited to the same amount. Squawk!
I want to talk to a programmer about some possible report changes. Squawk! Our policy says you have to fill out a project request and have it reviewed by a projects committee first. Squawk!
Sound familiar? I'm sure it does. So what do we do about it? In a followup posting on Shadow IT I referenced Ben Worthen's article Users Who Know Too Much (And the CIOs Who Fear Them). 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.
Although that approach will certainly take care of the policy parrot syndrome I'm sure it has you thinking "but we can't always say 'yes' to everything our customers want". It is easy to imagine chaos if user requests are fulfilled without question, IT will become gridlocked with inefficiency. Fortunately, there may be ways to control that without reverting to being a policy parrot.
When you look at policies we can place them in to 2 general categories. One is based on making IT (and/or the company) cost efficient. For example, many companies have a program of standard PC equipment and configuration for all users. A request for a non-standard PC (or gasp, a Mac) would likely be denied as a matter of policy because of the extra effort and cost that IT would incur in providing and supporting it. This is analogous to a store in which a customer wants a customized product. Most store owners would gladly agree but at a price to cover their extra costs. If the customer perceives the value as worth the extra cost they readily agree. If they believe the cost is higher than the value than they accept the standard model. We should do the same. Working with the Accounting folks we should "charge" or adjust the budgets for special non-standard requests. In many cases this will self-police the requests, in other users will feel the value merits the costs and be willing to fund the work.
The second category of policies deals with protection/compliance issues. For example, all PCs being required to have anti-virus software programs to protect valuable company data and systems or blocking of certain Internet sites to maintain a safe non-harassing work environment. In these cases we need to recognize that a request for a variance is usually based upon the need to solve a problem. We need to be creative and figure out a way to maintain the protection/compliance needs while solving the problem. Worthen cites the example of employees copying files on thumb drives to work with them off-site. Rather than trying to stop this practice due to data protection concerns IT distributed thumb drives with encryption software on them. This creative solution addressed the user need while maintaining the required security.
Often being a policy parrot is the easy thing to do. Blame the lack of service on a policy issue, get rid of the customer and move on to other things. As shown above coming up with alternative ways of addressing these situations takes extra effort. It requires us to be flexible and creative. It's not easy to do. However if we want to excel at customer service and replace Shadow IT we need to be willing to try tactics such as this.
What are your thoughts?
Parrot photo by Andy Tinkham
If this topic was of interest, you might also like these:
Tell a Friend
View blog reactions

















In Defense of the Parrot
Mike, I really enjoy your blog and think you are usually right on the money. However, I find your attitudes towards IT policies somewhat cavalier. Policies - IT and otherwise - are enacted to protect the company's interests. I find it hard to believe, for example, that the CFO would readily approve exceptions to the company's expense report policy. IT policies are no different. At the companies I have worked for there is a vehicle for reviewing requests that fall outside company policy - the IT Steering Committee, which is composed of business managers as well as IT. If a request can be justified on business grounds an exception can be made, of if necessary, the policy is updated. The alternative would be chaos. As Benjamin Franklin once said, "Gentlemen, we must all hang together or surely we will hang separately!"
Milburn Smith
Posted by: Milburn Smith | Milburn Smith | Mar 12, 2007 5:51:35 PM
Milburn
Thanks for commenting. And thank you for the kind words about my blog.
You are correct, policies are enacted to protect the company's interests. The problem is that policies can not be written to cover all situations and exceptions should be made when it is in the company's interest to do so.
Recall I talked about 2 categories: policy for efficiency and policy for protection. Let's take a look at your example of the CFO and the expense reporting policy. The CFO could say our expense reporting policy requires an employee's manager or designee to approve it (protection aspect) and employees will be reimbursed only once per month (efficiency aspect). The CFO will not grant an exception to having the proper approval (holding firm on the protection aspect) but will likely make an exception to when an employee is reimbursed if there is a good reason (will accept a certain inefficiency within the accounting department because there is a higher benefit somewhere else to make it worthwhile).
Conversely, a policy parrot will say, "Absolutely no exceptions no matter what justification or benefit or how logical it is to make an exception. I don't care if the employee is out thousands of dollars of their own money, we won't reimburse for another 3 weeks - that's the policy." A policy parrot hides behind the policy for the sake of their own efficiency even if it is counter-productive, i.e. not in the best interests of the company.
The trick is to have some mechanism to know for which parts of the policy an exception might be granted and having a method for deciding whether or not an exception is appropriate. What this method is can vary depending on the significance and materiality of the exception. In some instances a steering committee is appropriate, in others it is appropriate to have the individual handling the situation decide.
Likewise for an IT example of someone asking for more storage space for email. This is a cost/efficiency consideration. You should consider that for some users additional space is warranted. In determining this you should work with the user to review their needs and see if it is appropriate to delete some un-needed email to reduce their requirements. What I am suggesting is that we not be a policy parrot and simply say "No more space - that's the policy."
I try not to be too cavalier in regard to policies. However, I also try not to let policies inappropriately be a hinderance to good business. I may be wrong but I don't think we are really all that far apart in opinion.
Mike
Posted by: Michael Schaffner | Michael Schaffner | Mar 12, 2007 8:13:05 PM
Mike,
Glad you enjoyed my contribution to this discussion. As the above comment indicates, policy is, when correctly implemented - a protection and efficiency for both the company and their customers (or employees).
My policy parrot post are not meant to detract from a well-intentioned policy but to point out the - sometimes - lock-stepped adherence to policy over all else.
Certainly, no company should place policy decisions in the hands of customer service - but customer service should be instructed to listen to the customer, ascertain whether the concern is reasonable, and take it to a higher authority.
In the cases that I am presenting, this is not the pattern. These were clearly situations that called for a closer review as to whether the policy was achieving its intended objective.
Thanks again.
Posted by: Matthew Moran | Matthew Moran | Mar 13, 2007 11:41:31 AM
Matt,
You've created an icon for poor customer service with the "policy parrot" label - it's great, I love it.
You're right, the problem is usually not with a bad policy but rather with the as you say lock step adherence to a policy without regard to any other consequences.
I look forward to your continuing saga.
Mike
Posted by: Michael Schaffner | Michael Schaffner | Mar 13, 2007 12:33:14 PM