Once upon a time, I was a professional corporate bureaucrat. Part of my job was to define policies that would directly affect thousands of people, and indirectly affect thousands more. Early in that job I learned that our company didn’t offer much guidance about writing policies. Sure, we had clear policies about the format in which we would publish policies, but no guidance about other key elements of policies, such as how to define policies, how to maintain them, and how to encourage adoption. Lacking that guidance, I created my own.

Basic Principles

• Make your policy effective
• Encourage people to adopt your policy
• Help people find policies that affect them
• Help people determine which “policies” are legitimate
• Help people understand what they are being asked to do
• Help yourself maintain your policies

Make your policy effective

1. To make your policy effective,
   identify the policy’s beneficiaries, the people who benefit from the policy.
2. To make your policy effective,
   identify the business benefit that the policy creates its beneficiaries.
3. To make your policy effective,
   construct a cause and effect model that shows how compliance creates the business benefit.
4. To determine whether your policy is effective,
   measure compliance.
5. To determine whether your policy is effective,
   measure the business effect that the policy is intended to create.
6. To determine whether your policy is effective,
   correlate the measured compliance with the measured business effect.

Encourage people to adopt your policy

1. To encourage people to adopt your policy,
   describe the policy’s beneficiaries.
2. To encourage people to adopt your policy,
   describe the business benefit that the policy creates its beneficiaries.
3. To encourage people to adopt your policy,
   describe the cause and effect model that shows how compliance creates the business benefit.

Help people find policies that affect them

1. To help people become aware of relevant policies,
   link to each policy from web pages related to the policy’s scope and purpose.
2. To help people find the policies they need,
   publish each policy where people are likely to look for it.
3. To help people find related policy information,
   list all related policies, and only related policies, in the Related Policies section.
4. To help people determine whether a policy applies to them,
   clearly describe the scope of the policy by identifying who must comply, and, if appropriate, under what conditions.
5. To help people determine whether a policy applies to them,
   put all scope information, and only scope information, in the Scope section. Put other information, such as guidance, background information, or procedures, in a separate section or a separate document.
6. To help people determine which policies apply to them, when writing scope statements, use the “one-name-one-meaning” principle: each time you refer to the same set of people, use the same name; each time you use the same name, make sure it refers to the same set of people.

Help people determine which “policies” are legitimate

1. To help people determine whether a policy is legitimate,
   identify the person who approved the policy, and identify the date on which the policy was approved.
2. To help people understand whether a policy is in effect,
   indicate each policy statement’s approval status or revision status. Examples of status include approved, draft, and pending approval.
3. To help people understand the importance of a policy,
   put the word “Policy” in the title of the policy. Similarly, when creating titles for other kinds of admonitions, such as guidelines, standards, and procedures, include a word that identifies the type of admonition. This helps the reader distinguish among the types of admonitions, and give the appropriate significance to each.
4. To help people understand whether a policy is legitimate,
   keep the policy current.
5. To keep a policy current,
   periodically review the policy to determine
   • Is the policy’s purpose still relevant to the organization?
   • Are the policy’s compliance criteria necessary and sufficient to achieve the policy’s purpose?
   • Are the names used in policy (e.g., organizations, roles, technologies) still current?
   • Are the related policies and documents referenced by the policy still current?
   • Are there other policies that overlap or conflict with this one?
6. To help people find current policies,
   periodically remove old drafts and unapproved policy candidates from publication.

Help people understand what they are being asked to do

1. To help people understand what they are being asked to do,
   put all compliance criteria, and only compliance criteria, in the Policy section. Put other information, such as guidance, background information, or procedures, in a separate section or a separate document.
2. To help people understand the relationships among policies,
   list all related policies, and only related policies, in the Related Policies section.
3. To help people find information related to a policy, when referring to policies, events, practices, or other information defined elsewhere, give full citations. A full citation includes enough information to guide the user to easily find the referenced information.
4. To help people access information related to a policy,
   give citations in a form that readers can use. Some readers will read the policy on-line. Others will want printed copies of the policy. Use hyperlinks to help on-line readers. For people reading printed copies, give full citation information in the body of the policy statement, in a way that is readable on the printed copy.
5. To help people understand a policy,
   use the “one-word-one-concept” principle: each time you refer to the same concept, use the same word; each time you use the same word, make sure it refers to the same concept.

Help yourself maintain your policies

1. To make a policy maintainable, when assigning responsibilities, use role names; do not use the names of individual people. Refer readers to an external source (maintained separately from the policy) that identifies which people currently fill each role.
2. To make a policy maintainable, when requiring the use of technologies, require the most general technology that will achieve the policy’s purpose.
3. To make a policy maintainable,
   
   refer to related documents; do not copy text into the policy from other documents.

I’ve been thinking about a number of “flows” within organizations — the flow of authority, the flow of value, and the flow of communication — and how they interact. I have a few ideas and a lot of questions today. No answers.

The flow of authority is defined by the organization’s formal hierarchy. Authority is the organization’s permission to allocate its resources. People higher in the hierarchy have greater authority. That is, they have permission to allocate more resources.

The flow of value is the circulatory system of the organization. The organization functions by arranging the flow of value within and across its boundaries. Across the organization’s boundaries, products and services flow out to customers; and money flows in. Profits flow out to investors; investment capital flows in. Money flows out to suppliers; materials and tools and services flow in. As long as each flow creates value for each person who participates in the flow, the organization sustains itself.

Within the organization, value flows from group to group. Each group acts as internal investors, customers, and suppliers for others. As long as each flow creates value for each group, the organization thrives.

Here are some questions I’m pondering: How do these flows relate to each other? How do they interact? What are the effects of different ways of relating and interacting? What kinds of interactions lead to a healthy organization? What kinds lead to organizational illness and death?

Communication flows along both kinds of channels. It flows up and down the hierarchy, and it flows through the networks of internal and external investors and customers and suppliers. It flows from one channel to the other, allowing the flow of value and the flow of authority to inform each other.

What happens when communication flows less readily along each path? One kind of blockage is when communication flows more readily within a group, but not across the group’s boundaries to related groups. This is the familiar stovepipe or silo problem.

What other kinds of communication blockage are there? Are there organizations, for example, in which the people in each group communicate readily with their internal customers and suppliers, but not up and down the authority hierarchy? What do those organizations look like?

What other kinds of flow are there? How do they relate to the flows of value, authority, and communication, and to each other? What are the characteristic symptoms of blockage in each flow?

I suspect that thinking about flows can help us identify ways to increase an organization’s health.

Laurent Bossavit’s recent blog entry about stability got me thinking, as his incipient thoughts always do.

What makes stability an issue? Under what conditions would we pay any attention at all to stability? When we care about something that may be threatened by a force acting on it. If we care about a thing, and there are no forces acting to change it, we don’t need to worry about stability. And there’s little point maintaining the stability of something we don’t care about. Stability is an issue only when we care about something that is threatened.

How can we maintain stability? I can think of three general strategies: adapt, isolate, and absorb.

The first strategy is to
adapt the thing you want to stabilize, to modify it so that it now benefits from the forces that previously threatened it. For example, when the United States experienced oil crises in 1973 and 1979, U. S. automobile manufacturers began making smaller, lighter cars with more fuel efficient engines. And when Japanese companies began to export inexpensive, high quality cars to the United States, U. S. manufacturers began to sell foreign-made automobiles under American companies’ brand names.

The second strategy is to
isolate the thing, to separate it from the forces that threaten it. For example, the paint on your car separates the metal from the wind, rain, and salt that can corrode it.

The third strategy is to
absorb the threatening forces, to convert them into a form that is either less harmful or more useful. Then either incorporate the new form or dissipate it. Absorbing is a combination of adapting and isolating. You adapt to the environment so as to better convert or direct the threatening force. And you direct or convert the force so as to separate it from the thing you are trying to stabilize. For example, the shock absorbers and the tires on your car absorb mechanical motion. They convert mechanical motion into heat, a more readily disposable form, then dissipate the heat. For another example, your automobile insurance converts sudden, large expenses that could threaten your financial stability into smaller, more predictable expenses.

Note that each strategy for maintaining stability requires change. In order to keep the important thing stable, we must be willing to change something else, something that is less important. When you buy automobile insurance, you give up something less important, your available funds, in order to maintain something more important, your overall financial stability.

Here’s a question that now intrigues me: How do we decide which strategy or combination of strategies to employ to keep some precious thing stable? Do we adapt to changes when we can, and isolate ourselves only from forces to which we cannot adapt? Or are there some forces that we will try first to isolate ourselves from, and adapt only if isolation fails? What about the nature or value of the thing we’re trying to keep stable? How does that influence our choice of strategy?

One more question: Are there other common strategies for maintaining stability that are not accounted for by adapting, isolating. or absorbing?

Before you try to measure something as complex as people’s performance, make sure you can make simple measurements reliably. Length, for example. The length of the coast of Maine.

How long is the coast of Maine? If you draw a straight line from one end of the coast to the other and measure the length of the line, it’s about 220 miles. That’s one measurement.

Now measure a different way. Take a string that’s ten miles long. Hold one end of it at the southern end of the coast. Stretch the string straight and find where the other end of the string touches the coast. Continue measuring these ten-mile lengths and add them up. The length of the coast is maybe 400 miles.

Next, use a one-mile string, then 1000 feet, then 100 feet. The shorter the string, the longer the coast.

If you use a very short string, say one foot, it is difficult to decide even where the coast is, or whether “coast” means anything at all. Where does the land end and the ocean begin? How do you measure around the mouth of the Penobscot River? What about all of those islands? Do you measure around those or not? And when you measure at such a small scale, the coast is moving as you measure it. Should you measure at high tide or at low tide?

As you measure at still smaller scales, say the width of an oxygen molecule, “coast” becomes even less meaningful. At a small enough scale, the “coast” is discontinuous. At that point, even if “coast” meant something, the notion of “length” may no longer apply.

Many sources claim that the coast of Maine is more than 3000 miles long. What does that mean? The number is nearly meaningless if you don’t know how it was measured.

The length of the coast of Maine depends almost entirely on how you measure it. Why would measuring people be any different?

Once upon a time, I worked in the IT department of a large company, leading a cross-organizational process development team to define, promote, and support a standard software development process to be used by most IT projects. Like many organizations’ standard development processes, ours was large — it defined about 30 roles, 40 deliverables, and 50 activities organized into seven phases. In trying to make the process comprehensive, we had made it cumbersome.

Project teams complained that the process got in the way, and slowed the projects down. Every few months, one process development team member or another would bring those complaints to our monthly meetings. The first four times this happened, we tried to address the complaints by reviewing the standard process to determine which activities we could remove. Whenever someone recommended an activity that we could remove, someone else immediately explained why we could not safely remove it. We never removed a single activity.

The fifth time someone raised the project teams’ complaints, I decided to try a new approach, an experiment: Rather than starting with our comprehensive process and whittling it down to size, why not work in the other direction?

So I offered a proposal. “I propose that we adopt The Null Process, a brand new process that I’ve invented. The Null Process has no deliverables, no activities, no phases, and no roles. It isn’t possible to define a less burdensome process. The Null Process completely resolves the project teams’ complaints.”

“Now…” I said, “What would keep us from adopting The Null Process? What’s missing? What do we absolutely need that The Null Process lacks?”

My experiment flopped. After a few minutes of silence, someone said, “We absolutely need everything that’s in our standard process. The Null Process lacks all of it.” The rest of the team quickly agreed.

I wasn’t able to make The Null Process work that day. Still, I’m fond of it, and hold out hope that I can use it in the future. The idea of starting from The Null Process and adding only what’s necessary is, I think, a fine one. But I failed to establish a context for the conversation about what’s missing. Next time, before asking “what’s missing,” I’ll ask the team to do some stakeholder analysis. Who are we intending to serve with this process? What needs do we intend to serve for those people? Then we can evaluate how well The Null Process serves those stakeholders, and add only those process elements that are necessary to serve their needs.

Consider replacing each of your processes with The Null Process. I offer it to you royalty free! Adopt a more complex process only if you can identify stakeholders and needs that The Null Process does not satisfy.

Experiment: Establish clear goals for each of your processes. Ask Who will this process serve? and What needs will this process serve for those people?

Experiment: Justify each element of your processes — each role, each activity, each deliverable — by asking Who does this element serve? and What needs does this element serve for those people?

Until recently, I thought I understood what bureaucracy means: Filling out six forms in triplicate to order a ballpoint pen, waiting three weeks for your pen request forms to work their way up and back down four levels of hierarchy for management signoffs, then waiting four more weeks for the pen to arrive, only to receive a #2 pencil with a dried eraser. Now I understand that excessive paperwork, signoffs, and delays are not the definition of bureaucracy. They are the symptoms of bureaucracy.

I had been working for several years in a staff group whose purpose was to help a large IT organization define processes, standards, and policies. Then the IT group reorganized, and my staff group was now headed by a Vice President who had a strong command-and-control style. Our job was now to define processes, standards, and policies to which the rest of the IT group would adhere. Though we would engage the IT group in our work, ultimately we would enforce the standards by measuring compliance and by controlling bonuses and pay — and even continued employment — based on adherence.

Around that time, I began reading Peter Block’s life-changing book
Stewardship
. Block strongly advocates a vision of staff groups in which “the task of staff is to serve the people who serve customers and touch the product.”

As I read Stewardship, I grew increasingly uneasy. The idea of bureaucracy began to creep into my thoughts. “Bureaucracy… bureau?cracy… rule by bureau… a bureau is a staff group… so bureaucracy is… rule by… staff group. Bureaucracy is rule by staff group!
”

Gack! I’m a bureaucrat!

By that time, I’d fallen in love with Block’s ideas on Stewardship. Staff groups serve the people who serve the customers and touch the product. Not the other way around. I could no longer commit to the role my VP had asked me to play. Over the next few months, I worked to renegotiate my role, to find my customers and serve them. I was unable to make that work in a way that satisfied both me and the VP. I decided to leave the company. Meanwhile, the company decided to lay off a large number of employees, including me.

So I’ve returned to consulting, the work at which I’ve felt most energized, the work at which I’ve been able to see my customers and my contribution most clearly. When I am consulting, whether as an internal consultant or external, I’m part of a staff group, serving customers face-to-face. I’m Dale Emery, former bureaucrat.

Whom do you serve?

Steve Peterson, of Artemis International Solutions Corporation, spoke about portfolio management at last night’s Sacramento Valley PMI meeting.

Steve reported that, at a recent meeting of state CIOs, the CIOs cited alignment and accountability as their most pressing concerns.

That triggered a few thoughts for me. First, if you want alignment,
you will have to prioritize. In my experience, the biggest threat to alignment is that everything is top priority. The people who are doing the work can’t do everything at once. So when you make everything top priority, people work to their own priorities. If you’re lucky, their priorities will match what you most want. How lucky are you?

Treating everything as top priority also causes another problem, perhaps more important than the first. Even if the people doing the work prioritize the work in a way that benefits you, they don’t know it. People want to know that their work is valuable—and valued. In other words, people want to be aligned. If you don’t express your priorities clearly, how will people know what you value? How will they know whether they are aligned?

The CIOs’ second biggest concern is accountability. That triggered another thought, that initially went like this. “If you want accountability, you will have to call people to account. I’m typically skeptical of managers’ claims that their people are not accountable. If you are tempted to make such a claim, consider first examining whether and how you are asking them to account for themselves.”

But something nagged at me. Something about that advice didn’t feel right. There’s something deeper going on here, and the something deeper is… alignment. I’ve been on a number of highly aligned teams. On every one of those teams, people accounted to each other—and, more importantly, to themselves—all the time.

I’m tentatively concluding that alignment breeds accountability. If that’s true, then if you want accountability,
focus on alignment. Alignment and accountability rest on clear priorities.

What are your priorities?