Playbook: Difference between revisions
Jump to navigation
Jump to search
Amwelladmin (talk | contribs) No edit summary Tags: Mobile edit Mobile web edit |
Amwelladmin (talk | contribs) No edit summary |
||
Line 3: | Line 3: | ||
}}{{d|{{PAGENAME}}|/ˈpleɪbʊk/|n}} | }}{{d|{{PAGENAME}}|/ˈpleɪbʊk/|n}} | ||
A comprehensive set of guidelines, policies, rules and fall-backs for the [[legal]] and [[credit]] terms of a {{t|contract}} that you can hand to the itinerant [[school-leaver from Bucharest]] to whom you have off-shored your [[master agreement]] {{t|negotiation}}s | A comprehensive set of guidelines, policies, rules and fall-backs for the [[legal]] and [[credit]] terms of a {{t|contract}} that you can hand to the itinerant [[school-leaver from Bucharest]] to whom you have off-shored your [[master agreement]] {{t|negotiation}}s. | ||
She will need it because without it, she won’t have the first clue about the [[Subject matter expert|ISDA]] [[negotiation]]s, and will need to consult it to decide what do to should the counterparty object, as it certainly will, to the preposterous terms her [[risk controller|risk]] team has insisted go in the first draft of the {{t|contract}}. | |||
Playbooks derive from a couple of mistaken beliefs: one, that a valuable business process can be “solved” and run as an [[algorithm]],<ref>This is a bad idea. See {{author|Roger Martin}}’s {{br|The Design of Business: Why Design Thinking is the Next Competitive Advantage}}.</ref> and two, that, having been solved so that it no longer needs an expensive expert, it makes sense to have an ''in''expensive ''in''expert do it, rather than a machine. | |||
In most cases, using a machine is ''also'' a bad idea — just less bad than using a human.<ref>Assumption two in fact falsifies assumption one. If it really is mechanistic, there is no reason to have a costly, capricious human “helping to manage” — i.e., ''interfering in'' the process.</ref> | |||
=== Playbooks as “business as usual” === | |||
Playbooks can handle “business as usual”: they map out the known world: tilled, tended, fenced, arable land upon whose fertile soil one will find no conundrums, mysteries or perplexities. Boundaries have been drawn, tolerances set, parameters fixed, risks codified and processes fully understood. | |||
Playbooks maximise efficiency when operating within a fully understood environment. They are inhabited exclusively by [[known known]]s. They are like assembly instructions for an Ikea bookshelf, with the exception that Ikea bookshelves tend not to answer back. | |||
As far as they go, playbooks speak to the belief that ''the main [[risk]] lies in not following the rules'': they are of a piece with the [[doctrine of precedent]]: when you run out of road, you must appeal to a higher authority. | |||
So no [[playbook]] will ever say, “if the counterparty will not agree, do what you think is best.” All will say, “any deviations must be approved by [[litigation]] and at least one [[Credit]] officer of at least C3 rank.” | |||
Thus you [[escalation|escalate]] to a [[control function]], the idea being that the [[control function]] will further develop playbook to deal with each new situation, the same way the [[common law]] courts do — ''[[stare decisis]]'' — and will feed its decision down into the playbook of established [[process]].<ref>This rarely happens in practice. [[Control function]]s make ''[[ad hoc]]'' exceptions to the process, do not build them into the playbook as standard rules, meaning that the [[playbook]] has a natural sogginess (and therefore inefficiency).</ref> In practice, this does not happen because no-one has any time or patience for playbooks. | |||
===Playbooks, design and user experience=== | ===Playbooks, design and user experience=== | ||
Bearing in mind a playbook uses fixed instructions to delegate administrative tasks to unskilled personnel, it only works within normal operating conditions. | Bearing in mind a playbook uses fixed instructions to delegate administrative tasks to unskilled personnel, it only works within normal operating conditions. As long as clients are predictable, and compliant, all will be well. | ||
: | For example: | ||
By codifying this process, so the argument goes, not only may we engage materially cheaper negotiation personnel, but we effectively triage our | :Risk Control Department A has stipulated starting position ''X'', but allows that if Client B does not agree to ''X'', a satisfactory compromise may be found at ''Y''. | ||
:The playbook accordingly “empowers” the negotiator to offer ''Y'' without resorting to A for permission. Only if Client B should not agree to ''Y'' will there be an [[escalation]], back to Risk Control Department A who may sanction a further derogation from ''X'' to ''Z''. | |||
:Should Client A not accept ''Z'' either, there will then follow an extended firefight between risk personnel representing either organisation — albeit conducted through their uncomprehending negotiation personnel in Bucharest — which will culminate at final agreement at position ''Z'''. | |||
By codifying this process, so the argument goes, not only may we engage materially cheaper negotiation personnel, but we effectively triage our clients and improve our systems and controls over the previous process, whereby the onboarding team just made it up as they went along. | |||
We have certainly added to our systems and controls; no doubt about that. | We have certainly added to our systems and controls; no doubt about that. | ||
But look at this from above: only positions X through Z are in | But look at this from above: only positions ''X'' through ''Z'' are in codified. Risk personnel still had to improvise to make the key decision, ''Z'''. The playbook, and all those wonderful systems and controls, were in play only for a portion of the negotiation between ''X'' and ''Y'', being a position a mile behind what turned out to be the front line. | ||
No doubt this will generate copious [[management information and statistics]] with which middle management can regale their superiors with Gantt charts, [[dashboard]]s and [[traffic lights]] about the negotiation process. But all these gears are involved, and all all the systems is running over the uninteresting part of the process. | |||
At a cost: gathering all this data occupies working days and takes time: negotiation for ''all'' clients takes longer, and now the portfolio will be distributed over a range of points between ''X'' and ''Z'', making practical control portfolio more difficult. | |||
The client will not enjoy the negotiation process any more than you will, if you are presenting your client with its first experience of your organisation as the image of impersonal bureaucracy. With respect for our friends in Romania, your new clients would prefer to be hand-held by a salesperson in London than a school leaver in a call centre in Bucharest.<ref>Granted, in this day and age, your client is almost certainly housing its negotiation probability out of a call centre in Bucharest, too. </ref> | |||
=== Form and substance === | |||
Negotiation snags are either ''formal'' or ''substantive''. | |||
Formal hitches arise when clients (or their negotiation teams, which will also have been outsourced to Bucharest) don’t ''understand'' your terms and therefore challenge them. | |||
Substantive hitches arise when clients ''do'' understand your terms find your legal terms fundamentally unreasonable. | |||
Both scenarios are likely; often at once: it’s likely people in your ''own'' organisation won’t understand your documents, so it is a bit rich expecting your clients to.<ref>Best example is the [[hypothetical broker dealer]] valuation terms in a [[synthetic equity swap]]. </ref> | Both scenarios are likely; often at once: it’s likely people in your ''own'' organisation won’t understand your documents, so it is a bit rich expecting your clients to.<ref>Best example is the [[hypothetical broker dealer]] valuation terms in a [[synthetic equity swap]]. </ref> | ||
The answer to both lies in product [[design]] and | The answer to both lies not in playbooks and organisational heft, but in improving product [[design]] and [[user experience]]. ''Making your documents better''. | ||
===Simplify=== | ===Simplify=== | ||
For | For confusing and often-misunderstood terms, the answer is straightforward, but difficult: ''simplify'' them. This is usually not just a matter of language, but logical structure — though simplifying language often illuminates convoluted logical structures too. | ||
And, while financial markets drafting is famously dreadful, emerging technologies can help: run your templates through a GPT-3 engine and ask it to simplify them. It | And, while financial markets drafting is famously dreadful, emerging technologies can help: run your templates through a GPT-3 engine and ask it to simplify them. It won’t be perfect and will make errors, but ''it is free''. Checking for errors and running quality control is what ''you'' are for. It will break the back of an otherwise impossible job. | ||
===Remove false floors=== | ===Remove false floors=== | ||
Line 66: | Line 76: | ||
Why deliberately aggravate your clients just for the opportunity to [[performative]]ly climb down at the first objection? How does that create a better impression (off-market, disorganised, weak) than presenting a clear, coherent and fair document in the first place? | Why deliberately aggravate your clients just for the opportunity to [[performative]]ly climb down at the first objection? How does that create a better impression (off-market, disorganised, weak) than presenting a clear, coherent and fair document in the first place? | ||
===[[Legaltech]] as enabler of sloppy thinking=== | ===[[Legaltech]] as enabler of sloppy thinking=== | ||
And here is where the great promise to legaltech stumbles. It offers the capacity to do clerical jobs faster. It opens the door to infinite variability, optionality, within your standard forms. Tech can now | And here is where the great promise to legaltech stumbles. It offers the capacity to do clerical jobs faster. It opens the door to infinite variability, optionality, within your standard forms. Tech can now accommodate any complications in your standard forms that you can be bothered dreaming up. | ||
''You do not want compllination | ''You do not want compllination'' | ||
{{sa}} | {{sa}} | ||
*[[Process]] | *[[Process]] | ||
Line 78: | Line 88: | ||
{{ref}} | {{ref}} | ||
<references /> |