Draconian Responses To Gremlin Problems
Gremlins are wicked little mythological creatures that delight in causing mischief. Some of the problems we try to solve at work seem like gremlins. Just when we think we have one caged and harmless, two more appear and things are worse instead of better.
Sometimes we try to keep the gremlins out by fencing ourselves in. In other words, we put ourselves in a cage to protect us from the gremlins. This is what we do when we try to write rules and policies to prevent the gremlin problems. Unfortunately, as soon as we erect the policy cage, we find that gremlin problems start cropping up, inside the walls, because of the policy. We might be protected from the gremlins outside, but we’re trapped with the gremlins that manifest inside.
I’ve encountered a slew of such challenges this week. Here are three examples.
The shift to outsourced components and services makes our management of international trade regulations challenging. Even if our suppliers are domestic, we still need to manage supplier communications and interactions with international businesses where our data and information is concerned. Because of numerous events whereby sensitive technical data has escaped to international agencies where it shouldn’t, sensitivity to, and enforcement of, import/export laws and transmittal of sensitive information has necessarily increased.
The U.S. International Trade Administration (ITA) sets regulations concerning international trade. It doesn’t tell us how we are to ensure we meet regulations, but it holds us accountable to prove that we do, however we choose to do so. How we control our materials and information is up to us.
In a small organization where communication is fairly simple a quick, education about what constitutes controlled materials and information and leadership expectations that the regulations shall be satisfied, along with some decent record keeping, is generally enough to ensure compliance. In a larger organization, it isn’t so easy.
Larger organizations (to identify a common phenomenon, not to make fun of size) find it difficult to identify parties that might possess or control sensitive materials, much less educate them all on international trade and import/export compliance. It’s easier to simply issue a policy to everyone to treat everything as if it is controlled or sensitive information or material. There’s that fence to keep the gremlins out.
Here’s where the new gremlins manifest. Suppose an engineer wants to share some drawings, requirements, and specifications with a customer for review and approval before developing the design any further. Policy says that the information transmitted must be encrypted. But the customer doesn’t want it encrypted because then it doesn’t necessarily decrypt in a way that the models and drawings remain compatible with the software used to view or modify them.
Likewise, the ability to use software driven comment tools, don’t work when the requirements and specifications are no longer in editable word processor formats but are instead in encrypted/decrypted .pdf format. It’s inconvenient and the customer is irritated.
If that customer happens to be a government agency, we can’t send them a courtesy copy of the software systems or tools that enable a more seamless decryption because giving gifts of that nature violates policies put in place to prevent bribery and other incentive-type influences upon business dealings. In some cases, the solution has become to print documents and mail them instead of sending them digitally: no exaggeration.
Think for a minute how much paper one of your complete system drawing packages, including specifications and supporting data, would require sent to several parties in tandem. That’s an ugly gremlin!
Instead of enabling personnel across the organization to intelligently manage sensitive technical data, we are issuing policy to control all transmittal of data. That means we must enable an enormous database to record and track every transmittal of information, whether it includes technical data or not, and we must install encryption systems across the entire organization to every person with network access or access to data. That alone is expensive and time consuming.
While those systems are installed, the policy sets a trap for any correspondence that comes from or goes to anyone who is not connected to the system yet. That means that every e-mail or phone call or letter or package that doesn’t pass through the system is in violation of the policy, but there is no feasible way to enable the system for everyone all at once. People are necessarily violating policy or are unable to communicate or both. Those are some nasty little gremlins.
I ran into another similar problem on a personal level. I am a very small business; I’m one person. I can and do take payments for my work via credit card and, because of all the recent thefts of credit card data, my service provider requested that I prove my practices are compliant to the Payment Card Industry (PCI) Security Standard. I engaged a service that my service provider recommended to help me navigate the standard and make sure.
The service conducted a security test and provided me with a reasonably navigable on-line survey of questions directed at key points of the standard. My system of one person, one computer and one Internet portal passed the security test, but I failed the survey. My abundance of “not applicable” answers raised a flag. I also honestly answered that I did not have written policies about the handling of credit card data (I’m not in the habit of writing policies for myself).
I had to contact a live person to address the failure and get some clearer instructions regarding the most appropriate way to answer the survey given my overly simple business model and understand what did and did not apply. My conversation with a person in the know was very educational. Through that conversation, I learned more about the intent of the standard behind the survey process and was able to make some very intelligent decisions to ensure security against data hackers.
Unfortunately, in the end, in order to get my certificate of compliance I did have to write some policies, for myself, in order to address some critical questions for the survey. Yes, I believe it was not an especially valuable use of time, so I minimized the effort necessary to keep myself out of trouble.
Talking with a knowledgeable person about the meaning of the survey questions and my miniscule scale was valuable. If not for that ability, I either would not have been able to get my certificate, or I would have had to spend a great deal of time and money building a more elaborate system of devices and software (actually increasing the difficulty of maintaining security, by the way) just so that my format would better fit the expectations of the automated survey, which was clearly designed around restaurants, retail stores, and on-line retail models.
What the experience revealed, once again, is that one-size processes and policies do not fit every situation. It is better to address the needs and expectations of regulations, safety, security, and business intelligently, with understanding, than it is to adjust systems to fit the one-size-doesn’t-fit-all policy.
One last pet peeve policy to mention is the one so many businesses employ to ensure practice and compliance with continual improvement methods. So many insist that a process improvement may not be implemented if the work to determine and design the improvement doesn’t utilize a minimum set of tools and fill out an elaborate template form with data, measurements, answers to standard questions, and other general red tape.
I understand that standardization can be helpful, but sometimes we use it inappropriately. I also understand the motive to ensure people are actually practicing the methodology endorsed by the business by forcing them to prove it with the red tape and minimum expectations. That method of driving the practice backfires, though.
Instead of getting practice with the method, we get avoidance or we get secret, unapproved improvements so as to avoid the draconic policy of red tape and unnecessary work. We also must build an elaborate system of templates, forms, standards, and a way to track, review, and approve each request or solution.
None of us believe that every problem should be solved exactly the same way, so why would we expect to use the same tools and answer the same questions with each one? We do it because it seems easier to write policy insisting people learn and practice methods than it is to lead people to do it. Unfortunately, policy is a poor substitute for understanding and leadership. Draconian policy effectively shuts down intelligent thinking and often drives problematic activity or behavior as people do what is necessary to satisfy policy even if it doesn’t make practical or good business sense; gremlins.
Here is where I have difficulty completing my own thought with regard to the problem presented above and why I struggled with the writing of this post. My mission is to help us avoid problems, solve problems, or to act more wisely. Unfortunately, in this case I don’t feel like I have a good solution to the problem of draconic policy and the gremlins to which it gives birth.
The right and best answer is to address gremlin-like problems intelligently with education and understanding, with fundamental process improvement and instructions, and with leadership and guidance. However, I recognize that within large corporate businesses, when a response to regulatory demands must be swift and decisive, understanding, instructions, and leadership are both difficult and slow and policy seems like a more effective solution.
Thus, my advice, such as it is, is as follows. Do your best to avoid trying to eliminate gremlin problems with policy. It is better to give everyone in the organization the ability to prevent or eliminate gremlins than it is to build a fence that only traps some outside and the rest inside. If you absolutely must issue policy, try to make it versatile and scalable instead of one size that must be met by everyone. If you issue policy as a solution, be prepared for a whole slew of new gremlin problems to pop up as a result of the policy. Give people the flexibility to develop alternative solutions that satisfy the need, if not specifically the policy. At least the policy covers the business as solutions are developed. Understand that it will consume time and energy to develop those solutions.
Draconian policy often generates more problems than it solves, albeit different problems. Intelligent management of the issues that can lead to problems is better, but significantly more difficult. Unfortunately, the gremlin-type problems are inevitable. If you deal with them by issuing policy, be prepared to manage the consequences, including developing large, complex systems at significant expense.
Stay wise, friends.
If you like what you just read, find more of Alan’s thoughts at www.bizwizwithin.com.