There is a lesson for all of us in the recent Public Relations disaster for United Airlines, a lesson about Customer Service, and being so focused on the rules that we forget what the rules are there for.
Even if you've heard about what happened, you will probably have missed a couple of salient facts. Firstly, this is not a story about over-booking. The over-booking issue was resolved before anyone got on the plane. Secondly, whatever you may think of United Airlines, they're not directly responsible for how that poor man was taken off the plane. Whatever the rights or wrongs, when law enforcement shows up and asks you to comply, you can either comply or be "assisted" off the plane. The real issue began when four crew members showed up who needed to get to another location for a flight the next day. United immediately decided that they would exercise their legal right to inconvenience four customers already on the plane, and ask them to leave. When no one volunteered, United "randomly" picked four customers and told them they had to leave the plane, no choices. Three of them got up and walked off. The fourth, well, he's now famous.
Everything they did, as their CEO explained, was completely lawful, and 'by the book' according their company regulations. However, when the 'by the book' approach results in calling the law, because someone outside your organization doesn't understand your book, then you have failed utterly.
There is a difference between the law and our belief about what is right and proper. Most of us believe, incorrectly, that if we paid for the flight and are in the seat, we get to fly. Even if the law and the company regulations says otherwise, any service-oriented organization must make what's in the book, and why, clear to its customers in a way that doesn't involve threatening them with law enforcement. If that approach fails then they need to find another person to yield their seat, or provide some other added incentive. Playing it by the book isn't an adaptive approach.
Do we, as DBAs ever resort to 'playing it by the book', rather than find a solution that represents a happy compromise, and provides a service? How else have we become stuck with the old, but frighteningly accurate joke about DBAs: "What's a DBAs favorite word?" NO!
Are you that person? When developers ask about adopting MongoDB for certain applications, or for help setting up a CI process, is your stock answer to say "no", and to quote corporate policy at them? How about when a corporate policy is set that all VMs, regardless of use or intent, will have a 4 GB max memory allocation, even though SQL Server 2014's minimum memory allocation is, ta-da, 4 GB. That 300 GB database will be fine operating in 4gb of memory, right?
Sometimes, 'the book' gives you the right to say no. However, the fourth or fifth time you say no, aren't people going to start to bypass you? If I were a developer, I sure would. When you call law enforcement (management) down on them, maybe you get management's backing and maybe you don't, but do the developers any longer consider you a partner? In other words, do your customers believe that you are serving their interests?
We can become so focused on the rules that we forget that the rules are there to establish how we provide a service, to enable things to happen. Let's be the organization enablers, not the people who do things rigidly 'by the book'.
Grant Fritchey (guest editor)
