[cntainer]

> Every policy or process doc I write now has a section called “Reasons to Revisit.” It is essentially a reverse success criteria. Rather than a short list of things I would expect to see if the policy was successful

Wow, what a great piece of advice. It seems so obvious and simple in retrospect and yet I never thought about something like this.

[tempodox]

This seems to be very much in line with one of the things to do when writing software: Whatever you're building, think about what would disrupt/break it and deal with it somehow.

[kqr]

Right. Or when you're introducing code to work around a known problem. Add a comment stating that it is a workaround, what problem it works around, when the problem is expected to be fixed, and, critically, how the reader can verify whether the problem exists anymore or not.

Make it easy to find out when it can be removed, in other words.

[cntainer]

I've been doing something similar when coding.

On one long-term project we even had special comments with an expiry date attached. Every time the build was running a script would scan all comments and print to output those comments that were expired to make sure someone revists them. And you could either remove, keep and extend expiry or modify that code, depending on context.

I guess it never crossed my mind I could do the same when creating company policies and processes.

[jdsleppy]

I've even written a unit test that fails after a certain date with a descriptive message for this purpose. It's maybe more familiar to developers and already has tooling around it.

[unfocussed_mike]

As well as FIXME:, maybe REMOVEME:

[unfocussed_mike]

Or just thinking about what the burdens of success are. Especially when you know early success is not actually going to bring in the funds to pay for them.

[unfocussed_mike]

I have a bit of a tendency to lay out even the simplest technical suggestion in the following pattern:

- summary of issue/opportunity

- things we know are true

- things we think are true

- things we should do

- what if we were wrong in the second part?

- what are the admin/technical negatives of success?

- when do we need to look at that

Nobody reads all the way to the bottom, but the process of writing it out makes sure that I think about it, and it also helps dig up potential Metcalfe's Law impacts on resources, combinational explosions etc.

[thaumasiotes]

The problem with this advice is that process development is evolutionary. The purpose for which the process was instituted can end up being unrelated to the reasons that the process is beneficial.

That's why traditions develop.

[cntainer]

Actually I think the advice is spot on if you want to continuously evolve your processes.

Every time you revisit a process you can keep it, kill it or amend it. It sounds pretty evolutionary to me.

What I liked is that adding some fail indicators as part of the policy actually gives ammunition to the people that want to change the policy for the better against people that are abusing the current form of the policy.

[romeoblade]

Our company has a process in place that any process or policy gets reviewed either six months or one year, depending on the subject matter. A tech council reviews each, updates, appends, or archives it.

If it's updated, it's sent out to all employees. Some require a digital signature (i.e., a process for handling customer data) to make sure it's read and understood.

Each review has a commenting period (4 weeks) for techs to ask questions or voice their opinion on the changes before it's approved.

It's helped keep the important documentation current, helped the processes evolve and allows the people that actually use the process to have input on the matter.

[kragen]

One would hope that all of your policies are archived; otherwise, how will anyone determine in the future whether a past action was in accordance with the policy when that becomes a question in a lawsuit?

Perhaps by "archive" you mean something like "delete", in which case I would like to strongly encourage you to not use "archive" to mean that, because it's the opposite of the standard meaning of "archive".

[jensensbutton]

That doesn't make the advice problematic. The section is called "reasons to _revisit_" not reasons to kill. If you revisit and find that the policy is still beneficial then keep it.

[kqr]

This is one of the reasons I would like to learn more anthropology. It's a really powerful skill to observe how humans interact and then speculate creatively about what forgotten (or never fully understood) purposes the interactions fulfill.

[nonrandomstring]

Seems more in line with an Aristotelean ideal of policy. Today the word has changed to mean a fixed set of codes, a machine by which to make decisions.

[cgio]

Good advice but the reality I usually experience is one where processes and policies go to die in a folder on a “portal” that no one even has access to anymore. Good processes become embedded in tools and follow the lifecycle of their host.

[cntainer]

The processes that just go and die somewhere were probably not good processes from the beginning, else they wouldn't be abandoned

I liked the advice because it actually applies to good processes that become embedded in the everyday work.

The point of the article being in how to prepare for the cases when a good policy becomes broken or is abused over time.