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.
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.