My daughter Erin just caught her first fish.

Regular readers may recall that her dad spent years studying fish. Mine emitted electric impulses and lived in Africa. To catch them we dammed small streams, then shoveled the water through nets.

Erin caught hers with a salmon egg on a hook. It’s an entirely different experience. After we de-hooked the fish and returned it to the lake, I felt like we owed it an apology.

I might owe Managing in Manhattan an apology, too.

If you don’t recall, Manhattan wanted sample policies to use as a starting point for his own. In response, I suggested he avoid creating policies whenever possible.

In retrospect, I’m not sure if Manhattan wanted policies or procedures. Despite their linkage in the phrase “policies and procedures,” they’re entirely different concepts.

What’s the difference? The short version: Procedures are good, policies are bad.

The longer version: Policies define what behavior is and isn’t allowed. They exist to replace the good judgment of individuals with the better judgment of the institution. Static documents, they’re immune to context and nuance. As a result, they’re useful only for circumstances where context and nuance aren’t important. Reserve them for black-and-white situations.

For everything else, communicate principles. Doing so allows employees to be adults and managers to use discretion. Sure you’ll have difficulties in the gray areas, but that’s the nature of grayness.

Policies replace good judgment with inflexible edicts. Procedures, on the other hand, replace improvisation with step-by-step instructions. There are plenty of situations where step-by-step instructions are pretty helpful.

Consider the lowly tape backup. When you first install a new tape backup system, you need to do a fair amount of configuring and testing to make sure all data is recoverable. If you aren’t using an automated tape handling system, you also need to be able to locate and identify tapes when you need them.

If your operators follow your written procedure (not always a safe assumption) you ensure the utility of your backup system. If they don’t, it doesn’t matter how much you spent on the technology — it’s worthless.

“Procedure” is just another word for “process”. Well-defined, tested processes are important tools that help your employees succeed. Here are a few more tips:

1. Only write procedures for recurring situations or emergencies you can anticipate: You don’t need procedures for everything. For one-time occurrences or unanticipated exceptions, have this written procedure: “Use your best judgment and improvise.”

2. Keep them simple: State purpose, scope, and authorization, so each procedure is applied only in the right circumstances and by the right people. The rest is a numbered list of steps.

3. Don’t confuse procedures with tutorials: A procedure isn’t an instruction manual. And if you need an instruction manual you also need employee training. Provide it.

4. Test, adjust, test, adjust, and test again: Process designs are never right the first time, so don’t try: Get close tinker, and make sure each procedure works.

5. Make sure you can find the right one: Use your intranet. Burn some CD-ROMs for when the intranet is down. Keep hard-copy too.

Finally, keep them refreshed. Retire those that are irrelevant and reinvent any that are obsolete, because you need to periodically reinvent the wheel. If we didn’t, we’d all look like Fred Flintstone, driving cars that roll on logs.