The Accountability Trap

Allison was recently appointed Chief Compliance Officer in the IT department of a huge financial services company, and was set up to fail from day one.

The set-up was pretty obvious to an outsider, but not to her. She enthusiastically told me of the importance of regulatory compliance in their industry and the stature of her position as the one person accountable for the compliance of the entire IT function.

RELATED LINKS

Dotted Lines Do Little for IT Organization

How to Set IT Policies the Right Way

“The regulators require a single point of contact,” she explained. “We need to ensure consistent processes and metrics throughout the organization. And our CIO gave me the authority to make it happen.”

I was reminded of past discussions with Chief Security Officers, quality managers in the pharmaceuticals industry, and business continuity managers. All these people had been made accountable for other people’s compliance, and believed they had the authority to control other people’s behaviors.

Sigh. I hated to burst Allison’s bubble. But time and again, history has proven that this approach doesn’t work. Here’s why:

Executives have businesses to run, and they’re not going to let a compliance officer tell them how to do it. Sure, they’ll comply when it’s easy or when they really have to—with the big, visible initiatives. But on a day-to-day basis, Allison has three factors going against her:

1. Others are not being held accountable for their own compliance—she is. Why should they put effort into something that’s outside their own personal performance objectives?

2. Executives are held accountable for business results, and they aren’t going to let Allison cause them to fail at that. They’re not going to change their processes or disrupt their operations to help with her objectives.

3. Allison is the one who’s accountable. So if others mess up and bad things happen, she’ll take the fall.

Allison may as well have been given the title, “Chief Scapegoat.”

The Path of Accountability

The trap of the scapegoat occurs in many situations beyond compliance. It may be that ITIL “process owners” are tasked with implementing changes in the way the rest of the IT organization works. Or perhaps IT is asked to implement ERP and takes responsibility for changing clients’ business processes.

The organizational principle that applies in all these situations is straightforward: Accountability and authority must flow down through the solid lines of the reporting hierarchy. It must never flow sideways such that someone is given accountability or authority for peers’ behaviors.

Everybody in the organization must be accountable for their own behaviors, including for their own compliance. What this means is that everybody must balance operational objectives with compliance objectives. The degree to which operational objectives must be compromised to ensure compliance (or vice versa) is a decision that should be made by each manager for his or her own group (subject to review by his or her boss).

Idealists will claim that compliance helps achieve business results. That may or may not be true in the long run; but realists know that, at least in the near term, there’s often a trade-off.

Consider the extreme cases. If implementing compliance means shutting down production, a manager may choose to take the risks inherent in waiting to implement the compliance measure and pray that nothing bad happens. Conversely, if the risks of non-compliance are huge, the manager may choose to shut down production to implement the change. There’s no one right answer for everybody. The degree of compliance is a trade-off made in the context of specific business imperatives. Each manager is in the best position to make these decisions for his or her own group and must answer to the consequences.

Organizational Risks

After explaining this to Allison, she objected, “What if one guy takes a risk and something bad happens. Then the whole organization suffers the consequences.”

“Allison, would you advocate zero risk?” I asked.

“In public, I’d have to say yes. But I know that would be unrealistic. Zero risk would force us to shut down the business, at least for a while. We can’t do that. And the costs would be astronomical.”

“Right. So if you take a risk and something bad happens, the whole organization suffers the consequences, the same as if one of the managers had taken the risk. Whoever has the power to decide, the organization as a whole is at risk. The only question is who should make the decision on those trade-offs—you, or the managers running the business.”

Allison honestly felt she was in the best position to make those decisions. She thought her peers were likely to sacrifice compliance for near-term business results. While she agreed that making the managers accountable for compliance would swing the balance somewhat, she still wasn’t satisfied that they’d make the right decisions.

“You know there’s a good chance you’ll make the wrong decision too, Allison. Given your position, you’ll opt for more compliance than they would and in doing so you might sacrifice critical business results—maybe without even knowing it since you’re not in the trenches delivering IT services.”

We agreed that the trade-off between compliance and business objectives had to be made with a full understanding of both points of view. Either she could study the business and make the decision, or she could teach others the risks and let them decide.

I reminded her of the golden rule of organizational design: Authority and accountability must match. If she’s to make the decision, then she has to be held accountable not just for compliance but for everybody’s business results. Otherwise, what’s to stop her from deciding in favor of absolute compliance, sacrificing business results, and letting them take the blame when critical projects and services fail?

“I can’t be held accountable for everything going on in IT!” she cried.

“Exactly,” I said. “Therefore, you can’t be the one making these decisions.”

Practicalities of Change

“Okay,” Allison sighed, “I’ll grant that if everybody accepted their accountability for compliance, we could let them decide when and how much to change. But how do we get them to take that accountability seriously?”

“Let’s look at their incentives,” I replied. “Sure, if something bad happens, the whole organization suffers. But whose job is it to fix the mess; or in the worst case, who gets fired? It doesn’t do any good to fire you when the managers running the business make poor decisions and cause a serious problem. In fact, using you as a scapegoat only reduces others’ incentives for real compliance.”

She eagerly agreed. “Scapegoat” does not look good on a resume!

I reminded her that, in reality, getting changes to happen is far more likely if everybody is accountable and hence willingly implementing compliance initiatives to protect their own hides. On the other hand, the odds of successful change are far lower if she’s forcing it on the organization. Thus, overall, the success rates of compliance initiatives are higher, not lower, when the decision is left to each manager for his or her own group.

Compliance as a Service

“But remember,” Allison said, “the regulators require a single point of contact. And even if it weren’t required, process changes cut across organizational boundaries. Someone has to look after the big picture.”

This was a perfect segue into discussing how she could achieve the critically important objectives of compliance without accountability for others’ behaviors or authority over how others run their groups.

I suggested that Allison think of her job as a “coordinator” who sells services to her peers (though money doesn’t change hands) to help them with their accountability for compliance. One of those services is to bring others together and help them agree on changes that cross organizational boundaries. She can then help them implement the change in their respective groups, not as the project manager accountable for results but rather as a project facilitator and coordinator.

In a similar vein, if people outside the IT organization (like regulators) ask for information or impose an audit, she can coordinate the organization’s response. But every manager must be held accountable for his or her own piece of that response.

She also can coordinate planning. At one level, she can teach individual managers how to put together their own plans. Beyond that, her coordinating services include consolidating all their plans into an organizational plan, and bringing people together to work out the integration of the various pieces. Again, this is a service. Everybody must be accountable for planning; Allison is there to help them satisfy this requirement.

The same roles apply to testing the plan, as in the case of business continuity. Allison can coordinate the test, while everybody remains accountable for their own groups’ responses.

Throughout this service-oriented role, Allison can teach her peers the regulatory requirements, the risks of non-compliance, and the kinds of changes required to mitigate those risks. Educating others puts them in a position to decide the trade-offs. In the spirit of education, Allison may offer a risk assessment service, if her peers are willing to “buy” it from her.

“One final concern,” Allison said. “What if they just don’t do anything about compliance? Who’s to catch them? Their bosses may not know enough about the regulations to know that they’ve got a problem.”

There may be a need for auditing, I granted. But here too, a service approach works best.

“Remember,” I replied, “the real auditors are outside the organization—the regulators, hackers (in the case of security), or Mother Nature (in the case of business continuity). If you are seen as an auditor, doors will close as you approach and you won’t be able to implement meaningful change. But you can sell “compliance assessment studies” to managers which help them get ready for the real, external audit.”

The difference between an audit and an assessment is this: An audit is imposed, and the results are reported to others than those being inspected. An assessment is voluntary (if not requested by the manager, then by his or her boss). And the results are reported back to those who were inspected.

“Describing it this way keeps the accountability where it belongs, and keeps you on their side of the table—there to help them, not judge them. You’ve got to maintain good relationships to implement meaningful change.”

Stay On the Line

Allison could have stubbornly insisted that someone needs to be in charge or it won’t happen. But fortunately for her, she saw the light. “I’ve got to go back to my boss and renegotiate this position,” she said.

“Absolutely right!” I said. It’s the responsibility of the CIO to get accountabilities sorted out properly, and never to put one manager at odds with peers or set someone up to fail.

Whether in the form of compliance, security, business continuity, or process owner, the same fundamental organizational principle applies: Accountability and authority must follow lines of reporting. Everybody must be held accountable for their own behaviors.

Compliance, security, business continuity, and other change agents must limit their accountability to providing a highly effective coordination service. And C-level executives must step up to the plate and demand accountability in all the right places.

You can read another version of this column on consultant N. Dean Meyer’s website with with links to other Beneath the Buzz columns, relevant white papers, books, and other resources. Contact him at dean@ndma.com.