It’s not about the bike
|
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.
All the same it is galling to co-opt Lance Armstrong’s words, of all people’s, but here goes, with a JC twist:
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.
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?
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.
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.
Dieting sucks but getting new kit is fun
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 him, Tippex™ 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 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.
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 triggers 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
Anything you automate is, necessarily, low value: because you make it low value by automating it.
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 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 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 the conservatory. Your best outcome is that when you hit defcon one, 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 experts 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:
“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. 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.
See also
References
- ↑ And pies.
- ↑ Normal Accidents p. 28.