It’s not about the bike: Difference between revisions
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
(8 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
{{A|design|[[File:pie.png|450px|thumb|center|The actual problem, yesterday.]] | {{A|design|[[File:pie.png|450px|thumb|center|The actual problem, yesterday.]] | ||
}}Having been traumatised by compulsory inter-house cross-countries in his youth — best ever placing: sixth-last — the [[JC]] has always ''loathed'' races of any kind, resented those who are good at them, and | }}Having been traumatised by compulsory inter-house cross-countries in his youth — best ever placing: sixth-last — the [[JC]] has always ''loathed'' races of any kind, resented those who are good at them, and wallowed in any ''schadenfreude'' going should the foot-race winners of the world come unstuck. | ||
Look, exercise is important, but it is something one should do alone, anonymously, under cover of darkness if possible, and in disguise if not. | |||
So when the question arises ''how should one improve athletic performance'' the [[JC]] is, well — the sixth-last person in the world you should ask. | |||
But he has a fondness for metaphors<ref>And pies.</ref> and he spies a good ’un here. For the same principles that would apply to elite performance, were he to care a fig for it, assuredly apply to any other kind of process optimisation, and he cares quite a few figs about that. | |||
You will lose | So, to co-opt Lance Armstrong’s words, but with a twist: | ||
{{Quote|''It’s not about the bike. It’s about the '''pies'''.''}} | |||
If you want to go faster, there are two ways to do it: drop twenty grand on after-market kevlar fork upgrades, graphene spokes and go-faster stripes — or just ''lay off the pies''. | |||
=== The pie-significance of legal design === | |||
What has this to do with legal [[design]]? | |||
Well, your legal process is, like the JC, an opinionated windbag who complains a lot, does no-one any good and can’t run for toffee. That is why you are trying to fix it. Throwing fancy tech at it a''s a first step'' would be like the [[JC]] dropping thirty grand on a Pinarello ''Dogma'' and some Day-Glo spandex. No-one wants to see that. | |||
So, get in shape first. ''Then'' figure out if you need a new bike.Time for another home made [[Latin]] [[maxim]], readers: ''[[primum comede minus]]'': “[[First, cut out the pies]].” | |||
You will lose twenty kilos and ''save'' money — on pies, right? — ''and your current gear will work a lot better''. Get in shape first. ''Then'' figure out if you need a new bike. | |||
===Getting new kit is fun...=== | |||
And here our old friend the [[agency paradox]] rears its head, and the selfish motivations it imbues in those in the sedimentary layer above yours: ''all incentives will be skewed in favour of fancy new kit, however dumb an idea it may be''. | |||
To the management layer, innovating, for the sake of it, is where it is at. | |||
[[CEO|Hank]], the [[CEO]], has told all his directs they ''have'' to innovate. There’s a five-year plan — it may even be officially ''called'' a “five-year plan,” such is the lack of irony in the modern executive suite — to convert a third of the workforce into [[Chatbot|chat bots]] or gig-working [[School-leaver from Bucharest|Bratislavan school-leavers]] by 2026. | |||
So [[General counsel|Chip]], the [[GC]], is screaming at whoever is in [[Chauvinist language|his]] line of sight to ''do'' something — ''anything'' — to, like, ''digitise'' and while, as usual, there’s no money to do anything, by a stroke of otherworldly provenance, there ''is'' a ring-fenced, bottomless fund for projects that can be badged as “[[innovation]]”. | |||
Before you can say “[[blockchain]],” Chip will be all over it. To hell with the business case; ''make it happen''. | |||
=== ... but dieting sucks === | |||
So good luck pointing out that it would be better to fix your broken processes first before splashing out on the Pinarello. | |||
And even if you do, and carry the day, putting legal processes on a cabbage-and-water diet is ''hard''. | |||
The thing about broken processes is that they break over time, in unfathomable, illogical, unpredictable, hard-to-fix ways. They become progressively ''more'' broken over the aeons, as barnacles cluster, rust does not sleep, and critical knowledge is gradually lost to posterity. | |||
A team in Southampton will be mindlessly following some routine they inherited from legal in 1995, even though it became obsolete in 2004, and no-one thought to stop them. Your precedents, such as they are, will be all over the shop and shot through with contradictions, outrages and gnomic textual formulations that no-one understands, no-one can recall the provenance of, but everyone is terrified of removing. Where’s the upside, to a risk controller, in removing text? | |||
Untangling ''that'' skein will require someone with a lot of expertise, patience, time, energy and a strange fascination for assimilating anachronistic minutiae for the simple pleasure of obliterating them. | |||
We [[legal eagle]]<nowiki/>s are odd, but not many of us are ''that'' odd. And the management layer won’t have a clue about any of this. So no-one will be bothered.But we ''need'' to be bothered. Order in a skip and hire a chainsaw for the weekend. This is going to be fun. | |||
===If you can automate it, it can’t be important=== | |||
A great misconception about digitisation — even successful digitisation — is that, once complete, it will deliver enduring value that will accrue in perpetuity to the bottom line. This has a logic that only a management consultant could love. | |||
It does not. It ''cannot''. Anything you automate is, necessarily, low value. If it was hard, you wouldn’t be able to automate it. Whatever value it currently has it has ''because'' you ''haven’t'' automated it. If you do automate it that value will go away. ''You make something low value by the action of automating it''. | |||
When the whole team got BlackBerrys back in 2004, did you notice the massive difference in productivity? For, like, a week, right? Automating ''might'' yield a short-term productivity bump, but you’ll rapidly bank it and, anyway, if ''you'' can automate a process, so can anyone else. | |||
And then there are the downstream costs. Not just the [[Rent-seeking|rent extracted]] by the vendors, the internal bureaucratic overhead in maintaining, auditing, approving and renewing the software, training legal users, updating the content — the knock-on pain of solving a problem which wasn’t, actually, that you needed Kevlar forks in the first place, but that ''you needed to get in shape''. | |||
===[[System accident]]s=== | ===[[System accident]]s=== | ||
And this is not to mention the problem of figuring out what to do if there’s a [[system accident]]. | And this is not to mention the problem of figuring out what to do if there’s a [[system accident]]. | ||
[[Technology]] helps you in the | [[Technology]] helps you in the business as usual, when you are tilling fields, your fences are sound, your boundaries known, the range of outcomes understood, catered for and all is well in the world. Technology ''won’t'' help you when a [[black swan]] arrives and starts dive-bombing your conservatory. | ||
When you hit DEFCON 1, your best outcome is that your tech ''doesn’t get in the way''. | |||
{{quote|“In the control room there were three audible alarms sounding, and many of the 1,600 lights (on-off lights and rectangular displays with some code numbers and letters on them) were on or blinking. The operators did not turn off the main audible alarm because it would cancel some of the annunciator lights. The computer was beginning to run far behind schedule; in fact it took some hours before its message that something might be wrong with the PORV finally got its chance to be printed. Radiation alarms were coming on. The control room was filling with experts; later in the day there were about forty people there. The phones were ringing constantly, demanding information the operators did not have. Two hours and twenty minutes after the start of the accident, a new shift came on.” <ref>{{br|Normal Accidents}} p. 28.</ref>}} | For technology not to get in the way in a crisis, it must not make a complicated situation ''more'' complicated. At the least, it should be positively designed to ''not'' make diagnostics and resolution harder in an emergency. If you have divided your labour correctly, your technology will handle the routine stuff; your [[Subject matter expert|subject matter experts]] the exceptions — exactly the scenarios where technology, checklists and prepared [[risk taxonomies]] have nothing to say. | ||
{{Author|Charles Perrow}}’s account of the control-room at Three Mile Island as, without warning, reactant coolant pumps began cavitating, thumping and shaking, is instructive: {{quote|“In the control room there were three audible alarms sounding, and many of the 1,600 lights (on-off lights and rectangular displays with some code numbers and letters on them) were on or blinking. The operators did not turn off the main audible alarm because it would cancel some of the annunciator lights. The computer was beginning to run far behind schedule; in fact it took some hours before its message that something might be wrong with the PORV finally got its chance to be printed. Radiation alarms were coming on. The control room was filling with experts; later in the day there were about forty people there. The phones were ringing constantly, demanding information the operators did not have. Two hours and twenty minutes after the start of the accident, a new shift came on.” <ref>{{br|Normal Accidents}} p. 28.</ref>}} | |||
When the system seems on the brink of catastrophe and the most articulate question you can form about the situation is ''what the fuck is going on?'' you do ''not'' want to be unplugging, decoding, or working around non-functional safety mechanisms. | When the system seems on the brink of catastrophe and the most articulate question you can form about the situation is ''what the fuck is going on?'' you do ''not'' want to be unplugging, decoding, or working around non-functional safety mechanisms. | ||
So, fundamental system design principle: [[first, cut out the pies]]. | |||
All other things being equal, the optimum amount of technology to have in a given situation is ''none''. | |||
{{Sa}} | {{Sa}} | ||
* [[Reciprocity]] | |||
*[[Why is reg tech so disappointing?]] | *[[Why is reg tech so disappointing?]] | ||
*[[First, cut out the pies]] | *[[First, cut out the pies]] | ||
*[[Seven wastes of negotiation]] | *[[Seven wastes of negotiation]] | ||
{{ref}} | {{ref}} | ||
<references /> |
Latest revision as of 17:18, 27 March 2021
The design of organisations and products
|
Having been traumatised by compulsory inter-house cross-countries in his youth — best ever placing: sixth-last — the JC has always loathed races of any kind, resented those who are good at them, and wallowed in any schadenfreude going should the foot-race winners of the world come unstuck.
Look, exercise is important, but it is something one should do alone, anonymously, under cover of darkness if possible, and in disguise if not.
So when the question arises how should one improve athletic performance the JC is, well — the sixth-last person in the world you should ask.
But he has a fondness for metaphors[1] and he spies a good ’un here. For the same principles that would apply to elite performance, were he to care a fig for it, assuredly apply to any other kind of process optimisation, and he cares quite a few figs about that.
So, to co-opt Lance Armstrong’s words, but with a twist:
It’s not about the bike. It’s about the pies.
If you want to go faster, there are two ways to do it: drop twenty grand on after-market kevlar fork upgrades, graphene spokes and go-faster stripes — or just lay off the pies.
The pie-significance of legal design
What has this to do with legal design?
Well, your legal process is, like the JC, an opinionated windbag who complains a lot, does no-one any good and can’t run for toffee. That is why you are trying to fix it. Throwing fancy tech at it as a first step would be like the JC dropping thirty grand on a Pinarello Dogma and some Day-Glo spandex. No-one wants to see that.
So, get in shape first. Then figure out if you need a new bike.Time for another home made Latin maxim, readers: primum comede minus: “First, cut out the pies.”
You will lose twenty kilos and save money — on pies, right? — and your current gear will work a lot better. Get in shape first. Then figure out if you need a new bike.
Getting new kit is fun...
And here our old friend the agency paradox rears its head, and the selfish motivations it imbues in those in the sedimentary layer above yours: all incentives will be skewed in favour of fancy new kit, however dumb an idea it may be.
To the management layer, innovating, for the sake of it, is where it is at.
Hank, the CEO, has told all his directs they have to innovate. There’s a five-year plan — it may even be officially called a “five-year plan,” such is the lack of irony in the modern executive suite — to convert a third of the workforce into chat bots or gig-working Bratislavan school-leavers by 2026.
So Chip, the GC, is screaming at whoever is in his line of sight to do something — anything — to, like, digitise and while, as usual, there’s no money to do anything, by a stroke of otherworldly provenance, there is a ring-fenced, bottomless fund for projects that can be badged as “innovation”.
Before you can say “blockchain,” Chip will be all over it. To hell with the business case; make it happen.
... but dieting sucks
So good luck pointing out that it would be better to fix your broken processes first before splashing out on the Pinarello.
And even if you do, and carry the day, putting legal processes on a cabbage-and-water diet is hard.
The thing about broken processes is that they break over time, in unfathomable, illogical, unpredictable, hard-to-fix ways. They become progressively more broken over the aeons, as barnacles cluster, rust does not sleep, and critical knowledge is gradually lost to posterity.
A team in Southampton will be mindlessly following some routine they inherited from legal in 1995, even though it became obsolete in 2004, and no-one thought to stop them. Your precedents, such as they are, will be all over the shop and shot through with contradictions, outrages and gnomic textual formulations that no-one understands, no-one can recall the provenance of, but everyone is terrified of removing. Where’s the upside, to a risk controller, in removing text?
Untangling that skein will require someone with a lot of expertise, patience, time, energy and a strange fascination for assimilating anachronistic minutiae for the simple pleasure of obliterating them.
We legal eagles are odd, but not many of us are that odd. And the management layer won’t have a clue about any of this. So no-one will be bothered.But we need to be bothered. Order in a skip and hire a chainsaw for the weekend. This is going to be fun.
If you can automate it, it can’t be important
A great misconception about digitisation — even successful digitisation — is that, once complete, it will deliver enduring value that will accrue in perpetuity to the bottom line. This has a logic that only a management consultant could love.
It does not. It cannot. Anything you automate is, necessarily, low value. If it was hard, you wouldn’t be able to automate it. Whatever value it currently has it has because you haven’t automated it. If you do automate it that value will go away. You make something low value by the action of automating it.
When the whole team got BlackBerrys back in 2004, did you notice the massive difference in productivity? For, like, a week, right? Automating might yield a short-term productivity bump, but you’ll rapidly bank it and, anyway, if you can automate a process, so can anyone else.
And then there are the downstream costs. Not just the rent extracted by the vendors, the internal bureaucratic overhead in maintaining, auditing, approving and renewing the software, training legal users, updating the content — the knock-on pain of solving a problem which wasn’t, actually, that you needed Kevlar forks in the first place, but that you needed to get in shape.
System accidents
And this is not to mention the problem of figuring out what to do if there’s a system accident.
Technology helps you in the business as usual, when you are tilling fields, your fences are sound, your boundaries known, the range of outcomes understood, catered for and all is well in the world. Technology won’t help you when a black swan arrives and starts dive-bombing your conservatory.
When you hit DEFCON 1, your best outcome is that your tech doesn’t get in the way.
For technology not to get in the way in a crisis, it must not make a complicated situation more complicated. At the least, it should be positively designed to not make diagnostics and resolution harder in an emergency. If you have divided your labour correctly, your technology will handle the routine stuff; your subject matter experts the exceptions — exactly the scenarios where technology, checklists and prepared risk taxonomies have nothing to say.
Charles Perrow’s account of the control-room at Three Mile Island as, without warning, reactant coolant pumps began cavitating, thumping and shaking, is instructive:
“In the control room there were three audible alarms sounding, and many of the 1,600 lights (on-off lights and rectangular displays with some code numbers and letters on them) were on or blinking. The operators did not turn off the main audible alarm because it would cancel some of the annunciator lights. The computer was beginning to run far behind schedule; in fact it took some hours before its message that something might be wrong with the PORV finally got its chance to be printed. Radiation alarms were coming on. The control room was filling with experts; later in the day there were about forty people there. The phones were ringing constantly, demanding information the operators did not have. Two hours and twenty minutes after the start of the accident, a new shift came on.” [2]
When the system seems on the brink of catastrophe and the most articulate question you can form about the situation is what the fuck is going on? you do not want to be unplugging, decoding, or working around non-functional safety mechanisms.
So, fundamental system design principle: first, cut out the pies.
All other things being equal, the optimum amount of technology to have in a given situation is none.
See also
References
- ↑ And pies.
- ↑ Normal Accidents p. 28.