5 ms·

> 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 t

> 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.

nonrandomstring 5y ago
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.
tempodox 5y ago
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.
- unfocussed_mike 5y ago
  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.
- kqr 5y ago
  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 5y ago
    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 5y ago
      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 5y ago
    As well as FIXME:, maybe REMOVEME:
thaumasiotes 5y ago
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.
- kqr 5y ago
  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.
- jensensbutton 5y ago
  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.
- cntainer 5y ago
  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 5y ago
    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.
cgio 5y ago
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 5y ago
  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.
unfocussed_mike 5y ago
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.

nonrandomstring 5y ago

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.

tempodox 5y ago

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.

unfocussed_mike 5y ago
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.
kqr 5y ago
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 5y ago
  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 5y ago
    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 5y ago
  As well as FIXME:, maybe REMOVEME:

thaumasiotes 5y ago

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.

kqr 5y ago
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.
jensensbutton 5y ago
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.
cntainer 5y ago
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 5y ago
  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.

cgio 5y ago

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 5y ago
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.

unfocussed_mike 5y ago

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.