It’s not about the bike
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.
|
The design of organisations and products
|
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.
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. (If it already moves like Usain Bolt, why are you fiddling with it?)
In that case, throwing fancy tech at it would be like the JC dropping thirty grand on a Pinarello Dogma and some Day-Glo spandex.
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.
Dieting sucks but 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 your head. 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” — to convert a third of the workforce into 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.
Good luck pointing out that it would be better to fix your processes first.
And even if you do make that case, and it carries the day, putting 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 Ops 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.
Getting to grips with that job will require someone with unlimited expertise, patience, time, energy and fascination learning anachronistic minutiae for the simple pleasure of then erasing them.
We legal eagles are odd, but not many of us are that odd. No wonder no-one can 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 it will delivers enduring value that will accrue in perpetuity to the bottom line. But it does not. It cannot. 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.