Danny was military. He makes sure you know it, and his colleagues grumble that he acts like he still is. Danny likes discipline and controls, especially when he's the one with his hand on those controls.

As assistant to the CIO, Danny was put in charge of policy. He was dubbed the "policy czar."

"Policy" means a constraint on the way we work -- a "how to" procedure or "you must" requirement. The dictionary defines policy as: a definite course or method of action selected from among alternatives and in light of given conditions to guide and determine present and future decisions.

A policy, once established, narrows one's choices about what to do, how to do it, or which alternative to choose.

Which Policies?

During a leadership-team meeting, I asked Danny which policies he felt he was responsible for. His answer was, "All." (I was disconcerted that he neglected to add "sir" to the end of his terse reply. I thought that was policy.)

"All?" I asked incredulously.

"All," he replied assertively.

"Even those that apply to a single line of business, like the policy on what gets connected to the network?" I queried.

"Absolutely," Danny answered. He seemed annoyed that I'd had the insolence to ask.

Undaunted, I pressed on. "How do you go about setting policies?" I inquired.

Danny described a process that was essentially this:

Step 1: Danny decides which policy to work on next, setting priorities from among a list of potential policies that he generates as well as considering requests by others within the department.

Step 2: Danny drafts the policy, perhaps drawing on his peers as subject-matter experts.

Step 3: After a private briefing by Danny, the CIO approves the policy (in some cases with the input of a steering committee representing the business units).

Step 4: Danny enforces compliance.

Danny's Violation of the Golden Rule

I looked around the room at Danny's peers, and then asked one final question. "Danny, you said you are responsible for all policies, even those that affect only a single line of business. I just have one more question. Who here is accountable for the safe, reliable, efficient operation of the network?"

Without hesitation, Danny pointed to Rob, the head of the network operations group.

And now we see the crux of the problem: How can Rob be held accountable for the quality of service of his network, while Danny is deciding policies that dictate how Rob does business!?

This is a violation of the "Golden Rule" of organizational design: never separate accountability from authority.

Rob, with accountability but without concomitant authority, wasn't empowered to run his business his way; yet he was still held accountable for results. A cynic might say that he was set up as a victim and a scapegoat.

On the other hand, even if Danny accepted Rob's input on the policy, Danny's power to write the policy (and his de facto power to get it approved) gave him authority over Rob's business. With authority but no accountability, Danny could easily become a tyrant. His peers feared exactly this.

Compounding this problem, the managers didn't have the authority to establish the policies they needed to run their businesses. Danny became a bottleneck; he could only work on a few policies at a time. Policies suggested by others sat at the bottom of the list while Danny chose his priorities.

For example, Allie is responsible for intranet services. Her clients have been asking for an enterprise instant messaging service, but she has delayed deployment for two years awaiting an enterprise-wide policy regarding its use. Her proposed policy is still in the hopper awaiting Danny's consideration.

The need for policy was not in question. This IT department had grown in size and complexity over the years, and now it was time for it to grow in maturity. It needed to improve its consistency, safety, reliability, efficiencies, resource controls, and business focus.

Nobody denied the need for policies. But the way Danny implemented them demoralized the staff and threatened the performance of the entire IT organization.

Who Should Decide Policy?

The problem centers on who has the power to decide policy.

The Golden Rule of organizational design answers this question clearly and unequivocally.

If Rob is to be held accountable for the quality of service of his network, then Rob -- and only Rob -- should be empowered to decide policies on its operation and its use.

In general, policies should be decided by the individual or team who's accountable for the business constrained by the policy.

Some policies apply to the entire enterprise. Examples include security policies such as the design and refresh requirements for passwords, and the kinds of things employees may use the corporate internet for.

Policies that affect the entire enterprise should be decided by a consensus of the leaders of the enterprise. As difficult as that may be to achieve, it's the only way to ensure that the policy reflects everybody's input and by far the best means of gaining enterprise-wide compliance.

Some policies apply to the entire IT department. For example, a policy might state that if you wish to do business with IT, you must be funded either by an established portfolio-management process or show up with cash in hand.

Policies that affect the entire department should be decided by the head of the department (the CIO), ideally with the consensus of his/her leadership team.

Some policies apply to a specific line of business within the department. For example, the network operations group may establish a policy which says that if you don't meet certain safety requirements, you cannot connect to the backbone network inside the corporate firewall.

One could even use the word "policy" to describe the operating procedures within a group, such as how problems are handled in a call center and which design tools and methods are used to engineer applications.

Policies that affect a single group (like the example of network operations) should be decided by the leader of that group.

Policies that affect a number of groups within a department should be decided by a consensus of the leaders of those affected groups.

The Role of a Policy Group

Consider those policies that are department-wide, and hence should be decided by the CIO (hopefully with his/her leadership team's involvement). Would Danny's process work for these?

Even here, Danny made a serious mistake. He declared himself the "prime contractor" for policy development, and considered the subject-matter experts his "subcontractors." That is, Danny felt that he was accountable for the delivery of policies, and others were there to help him do so.

This was upside down. Giving Danny the monopoly on writing policy put him in the position of selling other people's expertise (in the form of the content of policies). To be fair to Danny, he shouldn't be accountable for the quality of ideas that are outside his domain of expertise.

Furthermore, policy is just one way to package subject-matter expertise. It's similar to documentation, research papers, even designs and technology solutions. It makes no sense to take this one product of other's expertise away from everyone else.

Everybody should be responsible for creating policies that are needed to run their businesses within the business. A policy group is there to help others do so, not to do it for them (or to them).

An effective policy group "sells" the following products and services to its peers:

Policy process facilitation: It can help an organization's leadership team accumulate, prioritize, and come to consensus on department-wide policies, and it can facilitate enterprise-wide consensus on enterprise policies. In this role, the policy group is strictly a process facilitator, not an author, sponsor, or decision maker.

Policy editing and advice: It can help subject-matter experts craft well-worded policies, providing expertise in how to define and phrase an effective policy. This expertise can help everyone write policies that are practical and effective without being bureaucratic, inflexible, overly disempowering, or expensive to administer.

Policy library: It can maintain a repository of policies, communicate their availability, and help people access and interpret existing policies.

Note that a policy group should not be responsible for the content of the policies, nor have any authority over that content. Golden rule!

And very importantly, a policy group must never be involved in auditing compliance. This would be a conflict of interests. No one can both serve others (policy facilitation) and stand in judgment of others (audit). To do so would undermine the teamwork between the policy group and its peers.

Policy as Conscious Risk

Policies are inherently risky. They reduce people's choices, and can make an organization less flexible, more bureaucratic, less creative, and disempowered.

But in many cases, policies are necessary. A well-chosen and well-written policy does more good than harm by establishing a consistent, meticulous process or necessary constraints which help leaders run an efficient, customer-focused, safe, and reliable business.

The key to an effective approach is to make everyone accountable for policies within their respective businesses, and to provide them with the help of a policy faciliation function (not a "czar") that serves its peers rather than attempting to control them.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....