It’s not about the bike: Difference between revisions

From The Jolly Contrarian
Jump to navigation Jump to search
← Older edit
VisualWikitext
No edit summary
No edit summary
 
(3 intermediate revisions by the same user not shown)
Line 4: Line 4:
Look, exercise is important, but it is something one should do alone, anonymously, under cover of darkness if possible, and in disguise if not.  
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.
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.


All the same it is galling to co-opt Lance Armstrong’s words, of all people’s, but here goes, with a JC twist:
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.
 
So, to co-opt Lance Armstrong’s words, but with a twist:


{{Quote|''It’s not about the bike. It’s about the '''pies'''.''}}
{{Quote|''It’s not about the bike. It’s about the '''pies'''.''}}


If you want to go drop some weight and go faster, there are two ways to do it: drop twenty grand on upgrading to kevlar forks, graphene spokes and go-faster stripes — or you could ''lay off 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''.  


Now what has this got to do with legal [[design]]? Well, if your legal process is anything like the JC, it will be an opinionated windbag who complains a lot, does no-one any good and can’t run for toffee. Am I right? If it is already Usain Bolt, what exactly are you doing fiddling with it?
=== The pie-significance of legal design ===
What has this to do with legal [[design]]?  


Right; if so then throwing voguish tech at it would be like the [[JC]] splashing out on day-glo spandex and a fifty grand bike instead of a pair of sneakers.  
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.


Time for another down-home JC-branded [[Latin]] [[maxim]], readers: ''[[primum comede minus]]'': “[[First, cut out the pies]].”  You will lose ten kilos and ''save'' money — on pies, right? — ''and your current gear will work a lot better''.
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]].”   


===Dieting sucks but getting new kit is fun===
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.
Let’s not forget our old friend the [[agency paradox]], and the selfish motivations it imbues in those who occupy the sedimentary layer above your head.


Innovating is where it is at. And the CEO has told all his directs they ''have'' to innovate. This is your [[GC]] we’re talking about. For {{sex|him}}, ''Tippex{{tm}}'' still counts as a kind of outré, remember. And there’s probably a five-year plan — and it’s probably even officially ''called'' a “five-year plan” — to convert a third of the workforce into gig-working [[School-leaver from Bucharest|Bratislavan school-leavers]] by 2026. So management is screaming to ''do'' something — ''anything'' — but there’s no money to do anything except, by a stroke of otherworldly provenance, there ''is'' a ring-fenced, bottomless fund for projects that can be badged as braggable [[innovation]]. Before you can say “[[blockchain]]” the [[GC]] will be all over it. To hell with the business case, ''make it happen''.
===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.


Secondly, putting legal contracts on a cabbage-and-water diet is ''hard''. Your precedents, if you have any, 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 fearful of removing. Gutting processes, stripping out indemnities, doing without [[NAV trigger]]s takes a courage others will regard as cavalier, and a preparedness to tell other control functions they are swinging the lead. That is a fight that most people in a hierarchy know better than to enlist for.
===If you can automate it, it can’t be important===
===If you can automate it, it can’t be important===
Anything you automate is, necessarily, low value: because you ''make it'' low value ''by automating it''.  
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''.  


Automating might give you 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 software vendor, 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, but that ''you needed to go on a diet and 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 [[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 the conservatory. Your best outcome is that when you hit defcon one, your tech ''doesn’t get in the way''.
[[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 an existential crisis, it must be make a complicated ''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]]s the exceptions — exactly the scenarios where technology, checklists and prepared [[risk taxonomies]] have nothing to say. Charles Perrow’s account of the control deck at Three Mile Island as, without warning, reactant coolant pumps began cavitating, thumping and shaking, is instructive:
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.


{{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>}}
{{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.
Line 41: Line 71:
So, fundamental system design principle: [[first, cut out the pies]].  
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''. Tech necessarily adds complication, cost and confusion. Therefore your first question is: how will technology improve the situation. Ask not just in terms of reduced ''cost'' but reduced ''waste''.
All other things being equal, the optimum amount of technology to have in a given situation is ''none''.  
{{Sa}}


* [[Reciprocity]]


{{Sa}}
*[[Why is reg tech so disappointing?]]
*[[Why is reg tech so disappointing?]]
*[[First, cut out the pies]]
*[[First, cut out the pies]]

Latest revision as of 17:18, 27 March 2021

The design of organisations and products
The actual problem, yesterday.
Index: Click ᐅ to expand:
Design
Tell me more
Sign up for our newsletter — or just get in touch: for ½ a weekly 🍺 you get to consult JC. Ask about it here.

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

  1. ↑ And pies.
  2. ↑ Normal Accidents p. 28.
Retrieved from "https://jollycontrarian.com/index.php?title=It’s_not_about_the_bike&oldid=55481"