> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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.
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.
> Think about this way: why do startups start young, idealistic and innovative only to eventually grow more and more corporate and litigious in nature?
I submit that people scale poorly.
Sure, Gall's Law[1], but note an empirical military truth: people in quantity do not accomplish tasks without a loss of individuality and a heavy authoritarian structure.
The U.S. military is also hugely expensive and wildly inefficient. Why are SpecOps teams all? Less is more.
Attempts to externalize and codify successes within corporate policies are worthwhile, but have a half-life associated with them as people turn over and contexts shift.
In summary, all human organizations tend toward the Tower of Babel. Lack of scalabilty is intrinsic. We can stop wondering.
Great article. It's rare that anyone considers the old age and death of a policy (actually, "death" would be a good outcome, but that happens too rarely).
She's right that the later bureaucrats just cite phrases from the policy as if they were Holy Writ. It becomes literally like a religion, where the ultimate appeal is always to some sacred ancient text, and then they argue about what the ancient text means now.
So I like the idea of adding to the soon-to-be-ancient text words to the effect that "here's how you'll know this is becoming obsolete."
Like the previous discussion on safety regulations and societal boundaries, I feel as if tribal knowledge and heuristics are the best approach. This gives training, loyalty, good management, mentorship, experience, and personal judgment extra weight.
Not a popular stance, these days. Everyone wants to figure out how to have vast, transient, armies of disloyal, inexperienced –and, possibly, even incompetent– mercenaries, developing their product. No one wants to filter for the types of employees that can operate in an environment without guardrails and strict rules. They are expensive, and often require a very different management style, from the norm. I used to manage just such a team.
"Any proposal must be viewed as follows. Do not pay overly much attention to the benefits that might be delivered were the law in question to be properly enforced, rather one needs to consider the harm done by the improper enforcement of this particular piece of legislation, whatever it might be."
Whenever someone suggests introducing process that could lead to just as much harm as good, I remind them that we should prefer to hire smart people, and trust that they are smart enough to recognise when they've made a mistake so they can, if not outright fix it, at least ask for help in fixing it.
Sometimes an ounce of prevention beats a pound of cure. Often an ounce of prevention turned into process becomes several pounds of prevention and the cure is easier.
Smart people also don’t want to be spending their time assessing the risks of unknown situations. E.g. something I came upon recently when someone asked if they could work remotely from abroad for a while. Sure, from a technical contribution perspective it made sense to approve straight away. But if there was no policy and process I would never think to inquire about the tax implications with the relevant team. You don’t only count pounds and ounces but also who has to lift them. I don’t like smart engineers having to learn tax legislation, and at least some processes act more like interfaces between teams rather than stupid controls within a team. When it’s about the latter I am all with you as long as you add responsible team members next to the smart condition.
That's pretty much what I mean by “an heuristic approach”: "Always consider fiduciary obligations. Here's where to find..." etc. In the WTF, there are likely to be specific directions and policies, but having a "navigator" for these policies ("A) Which nation is the employee in? B) Which office will be directing their work?, etc.) is a good idea.
I love it. It reminds me of a story.
My friend who joined the Big Search Company as tech lead was asked to report progress in four places.
He thought it was ridiculous.
So instead, he didn't report at all.
He got two questions why is he not reporting?
So for year's he was reporting in just two places instead of four.
Two others were unused/unnecessary. However, still done by all other tech leads.
Not necessarily (in general)! It could be that those other two locations are part of the eyes for someone in management. This report not adding a status update could represent 10% of 25% of the stuff they're tracking on a regular basis. Do you notice if some small percentage of all the things you're tracking stops reporting? Or does it fall through the cracks? I'm betting the people tracking that work in the other two locations would notice if everyone stopped reporting.
Should they notice the reporting drop off? Yeah. But we're only human and must rely on process and the cooperation of other humans for everything to work efficiently.
(In no way am I saying someone should have to report in four places. They should fix their process so they're reporting in one place and anyone who need eyes on those people can check there.)
Push vs pull solves it neatly; the idea of requiring subordinates manually / proactively to push status updates to various management nodes seems kind of absurd.
Well sure; basic communication skills are prerequisite (and assumed). I was talking about GP's ref to formal processes that required frequently pushing updates to 4 different upstream management nodes, which I maintain is doing it wrong.
"It’s because early stage companies tend to hire people who prioritize the company’s well being and mature companies tend to hire people who prioritize their personal gain"
This has not been my experience at all. The people I know involved in start ups are seeking adventure and personal wealth. The people who stay with the company are focused refining what they have to be the best thing it can be.
Mine too. Maybe this is different for the especially early stages (sub-20 people) where people congregate around that shared mission. But for mid-to-late-stage startups, I find more bureaucracy propagators and responsibility shunners than BigCorps
I like the systemic thinking done here. This is much too rare in all kinds of policy decisions and certainly good advice for programmers, who should probably also think more about how in a distant future their software could potentially become a menacing legacy zombie that haunts precisely those people who care — and how to make it easy for them to deal with this.
My only criticism of that article is that it seems to assume that policies and processes have good intent to begin with or that they solved a real problem.
During my time in the corporate world, I'd say most policies and processes are the exact opposite. They're invented to try and formalize human behaviors and interactions, either because the people inventing them are deficient in social skills and anything that makes other humans more predictable is preferrable to them or because they just generally fear uncertainty and don't trust people to have good judgement in unique situations.
What an excellent piece! I loved the specific example of how to arm the future policy killer:
We can argue all day about what “adapt to modern architectures and frameworks for IT resource utilization” means, but it’s harder to argue about a statement like “it takes longer than two months to patch a system”.
>why do startups start young, idealistic and innovative only to eventually grow more and more corporate and litigious in nature? It’s because early stage companies tend to hire people who prioritize the company’s well being and mature companies tend to hire people who prioritize their personal gain.
An alternative hypothesis is that, as organizations grow, their focus shifts from innovation to maintenance. It's a counterargument to the obscession with innovation.
"I think in paying more attention to maintenance and maintainers , it’s really signaling a shift in values away from glittery new things, consumer culture and those sorts of things, and toward work, towards labor, towards maybe even sacrifice in the form of taxes or effort to sustain society, and to pay a little bit more respect to the people whose jobs do that. They’re not superstars, they’re just grinding it out from day to day."[1]
But does that explain the transition from "innovation" to "bureaucracy"? If that claim was the case, I don't see why there couldn't be organizations that are both innovative and process-driven.
No, size explains it. You cannot be large without bureaucracy - bureaucracy means there are experts to do everything better than you can yourself. Sure small companies you can do things yourself, but you are often not the best person possible to do it - just that you are the only person.
Innovation happens at large companies as well. However not always in the same way.
I agree with the overall sentiment but perhaps disagree with the idea that bureaucracy is the result of specialization. I tend to think bureaucracy grows as a side effect of network effects. As the number of nodes in a corporate network grows, the interaction depth grows exponentially and processes help manage all those interactions. If there's a high level of specialization, but minimal interaction, there's still no need for a bureaucracy. In theory, you could have a large organization with so many silo'd departments that don't interact, there'd be no need for bureaucracy.
I suspect software enabled policy will be more explicit - i hope
so for example, we count the number of errors logged in our central logging system, and we count the number of releases made per day, both of which are stored in the central metrics database. so we monitor our ecosystem, we store metrics in the ecosystem, and then we can write policy such as "if number of errors per day per release exceeds this ratio, introduce a bug day"
ok - bad example but the overall system seems a good idea
I know meta commentary is not welcome, but this page leaves my head scratching. Based on the other comments this sounds to be a worthy and insightful read but when I click on it all I see is a single paragraph (using an ipad safari, no extensions or adblocker) It ends at “There’s no trick to designing process…”, no button to read more, no call to subscribe, or pay a paywall. Are we seeing the same page?
That is what I get when I disable Javascript. With JS enabled, I got a flash of just the first paragraph and after a second the rest is loaded and displayed. Not exactly ideal, that's true.
Still, I prefer not to nitpick over design and code choices when the focus of a link is the content. It's not like our discussion here of the technology will do anything. It only distracts from the discussion of the content. If an author shows up it's different, then it may make sense to tell them. Otherwise, my position is to just let it slide.
If discussion forums such as this had multiple levels and replies about the content, "fun" replies, and discussions about unrelated aspects could be separated, then sure, but if it's all mixed I think it's better to leave it be and concentrate on that main point.
Especially since the article is interesting and makes good points, like this one.
>So when I write policy, I always include a few internal facing failure signals and a few external facing failure signals because I know that five, ten years from now someone is going to think this policy I’ve worked so hard on eff-ing sucks. And they’re probably going to be right! Many of the problems I was worried about probably don’t exist anymore. There are likely some new problems I could never have guessed would come up.
What are the failure signals for a vaccination policy?
Wow, what a great piece of advice. It seems so obvious and simple in retrospect and yet I never thought about something like this.