Wag the dog
As creators of regulatory policy, we are often concerned that the tail should not wag the dog - that the implementation of regulation should not drive regulatory policy. We believe that the policy should triumph, that the regulatory goals are paramount.
As regulatory practitioners, we can often struggle to translate the policy into practice. Can the policy goals and its (usually) legislative outline be implemented in an effective and appropriate way? For the front-line regulator, what is the tail and what is the dog is more unclear than ever – how do I, as a regulator, make this work in practice?
Increasingly, this interface between the policy and the practical delivery is mediated by some kind of IT infrastructure which must be designed and built; that needs to meet the requirements of both the legislation and those being regulated.
Across my career, I have seen a number of different approaches to closing the circle between regulatory policy and implementation. At one extreme, when asked to implement a new government program with no new resources, I have seen an agency attempt to twist the design of a program to fit an existing IT system to allow a commitment to be delivered with little more than a name change and a tweak of requirements. I have also seen processes where those trying to implement requirements were constantly having to go back to a no longer existing committee to try and interpret what they meant in order to translate the ideas to practical regulations. There is the challenge that new regulatory requirements are often required to be delivered a lot faster than it is possible to deliver new systems (or even get a second pass business case approved), so generally there will always be half measures and patches and dodgied up approaches to try and make things work – sometimes for years. Misunderstandings of how legislation can be applied can arise when these approaches are used and practice can creep to resemble what is easily possible and practical through systems, rather than what is actually required by law.
In the building of new regulatory approaches, often everyone sees that their role is the most important and that if they do it right, the policy goals will be achieved. The lawyers will focus on the drafting, the policy people on the policy, the regulators on the implementation. The truth is, without bringing these all together, regulation will either not be effective, will end up with gaps or will be vulnerable to legal challenge. The simple truth for regulators is that we create risk for ourselves when our practice deviates from our legislative mandate.
How do we address this risk? The answer seems incredibly obvious to me now, but that doesn’t mean that it didn’t take me a while to reach it. In the design of policy and legislation, you need a multidisciplinary team from the start. You need someone who understands how to draft legislation, you need someone who has thought deeply about the policy intent and what is to be achieved, but critically you also need someone who understands the practicality of regulating and someone who knows what a computer system can and can’t do, and how complex (and expensive) it would be to create. If your process is impossible to implement without highly complex systems, or your rule is something that the regulatory field officer can’t effectively do or judge by themselves, you set your regulation up for failure.
Building effective regulation is about WAY more than the legislation – it is the IT system, it is the ability of officers to implement, it is the understanding of the regulated entities. All these things must work harmoniously for to achieve the policy goals effectively. In this sense, there is no tail – if the whole dog isn’t heading in the right direction, your regulation is headed for trouble.
