Playbook: Difference between revisions

From The Jolly Contrarian
Jump to navigation Jump to search
No edit summary
No edit summary
Tags: Mobile edit Mobile web edit
Line 20: Line 20:


===Playbooks, design and user experience===
===Playbooks, design and user experience===
If we take it as a given that a playbook methodology of using set instructions to delegate administrative tasks to unskilled personnel, is fit for purpose only within the bounds of 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. For example:


For example, Risk Control Department ''A'' has stipulated a starting position ''X'', but  has recognised that if a Client B does not agree to ''X'', a satisfactory compromise may be found at ''Y''. The playbook accordingly “empowers” the negotiator to offer that compromise. Only if Client B should also not agree to ''Y'' will there be an [[escalation]], back to Risk Control Department ''A'' who may sanction a further derogation from standard terms to ''Z''. There may then follow an extended firefight between senior risk personnel representing either organisation — albeit conducted through their uncomprehending negotiation personnel in Bratislava — which will culminate at final agreement at position ''Z'''.
:Risk Control Department ''A'' has stipulated starting position ''X'', but  has recognised that if a 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, there will then follow an extended firefight between risk personnel representing either organisation — albeit conducted through their uncomprehending negotiation personnel in Bratislava — 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 client base and improve our systems and controls over the previous process, whereby the onboarding team just made it up as they went along.
By codifying this process, so the argument goes, not only may we engage materially cheaper negotiation personnel, but we effectively triage our client base and improve our systems and controls over the previous process, whereby the onboarding team just made it up as they went along.
Line 28: Line 28:
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: Risk Control Department A is stipulating position ''X'' where in reality it will accept position ''Z'' or even ''Z'''. The playbook, and all those wonderful systems and controls, in play only for the the portion of the negotiation between ''X'' and ''Y'', being a position a mile behind enemy lines.
But look at this from above: only positions X through Z are in anyway codified. The key decision has been made by Risk personnel essentially making it up as they go along. The playbook hasn’t helped. Rather it has convoluted the ''easy'' part of the negotiation.


No doubt middle management will regale any [[Steerco]] or [[Opco]] that will listen about the magnificent [[management information and statistics]] it has about the negotiation process. But all these gears are involved, and all all the systems is running over a part of the process that presents zero risk to the organisation. 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.
By creating the playbook Risk Control Department A is stipulating position ''X'' where in reality it will accept position ''Z'' or even ''Z'''. The playbook, and all those wonderful systems and controls, in play only for a portion of the negotiation between ''X'' and ''Y'', being a position a mile behind the front line.


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 the greatest respect for our friends in the Slovak Republic, your new clients would prefer to be hand-held by a salesperson and in London than a school leaver in a call centre in Bratislava.<ref>Granted, in this day and age, your client is almost certainly housing its negotiation probability out of Acorn centre in Bratislava too. </Ref>
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.  


What to do?  Negotiation difficulties will generally fall into two camps: 1, the client (or its negotiation team, which also has been outsourced to Bratislava) won’t ''understand'' your document and will therefore insist on changing it. 2, it will find your legal terms fundamentally unreasonable.
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.


Both scenarios are likely; often at once: it’s highly 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 [https://jollycontrarian.com/index.php%3Ftitle=Hypothetical_broker_dealer hypothetical broker dealer] valuation terms in a [https://jollycontrarian.com/index.php%3Ftitle=Synthetic_equity_swap synthetic equity swap].  </ref> The answer to both lies in product [[design]] and consideration of [[user experience]].
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 the Slovak Republic, your new clients would prefer to be hand-held by a salesperson in London than a school leaver in a call centre in Bratislava.<ref>Granted, in this day and age, your client is almost certainly housing its negotiation probability out of a call centre in Bratislava, too. </Ref>


For the confusing and misunderstood x, the answer is straightforward, but difficult: ''simplify'' them. This is a matter of not just language, but logical structure, though by simplifying language often convoluted logical structures become easier to see and therefore easier to fix. And while capital markets drafting is famously dreadful, there is emerging technologies that may help.  
What to do?  Negotiation snags are either formal or substantive. Formal hitches arise when clients (or their negotiation teams, which will also have been outsourced to Bratislava) won’t ''understand'' your terms and will therefore challenge them. Substantive hitches arise when clients find your legal terms fundamentally unreasonable.


Run your templates through a GPT-3 engine and ask it to simplify them. It almost certainly won’t be perfect and almost certainly will make errors, but ''it is free''. Checking for errors and running quality control is what ''you'' are there for. It will break the back of an otherwise impossible job.
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 consideration of [[user experience]].


===Simplify===
For the confusing and 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 lwon’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===
If you know you will settle at ''at least'' Z, then what are you doing starting at X? Other than a clibj of glasses in the risk team for a job well done, what have you achieved?
Yes, these are marginally preferable risk control terms, but if they are ''meaningfully'' better, then ''you should not be prepared to go as far as Z''.
Identify walk away points and stick with them.





Revision as of 12:51, 2 January 2023

Negotiation Anatomy™


File:Lear.jpg
A playbook yesterday.
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.

Playbook
/ˈpleɪbʊk/ (n.)

A comprehensive set of guidelines, policies, rules and fall-backs for the legal and credit terms of a contract that you can hand to the itinerant school-leaver from Bucharest to whom you have off-shored your master agreement negotiations. She will need it because, being an itinerant school-leaver from Bucharest, she won’t have the first clue about the ISDA negotiations, and will need to consult it to decide what do to should her counterparty object, as it certainly will, to any of the preposterous terms her risk team has insisted go in the first draft of the contract.

Playbooks derive from a couple of mistaken beliefs: One, that a valuable business can be “solved” and run as an algorithm, not a heuristic;[1] and two, that, having been solved, it is a sensible allocation of resources to have a cheap, uninformed human being run that process rather than a machine — which is in turn also a bad idea, just a less bad one than using a human.[2]

In Thomas Kuhn’s argot[3] playbooks deal with situations of “normal science”: They map out the discovered world. They contain no mysteries or conundrums. They represent tilled, tended, bounded, fenced, arable land. Boundaries have been set, tolerances limited, parameters fixed, risks codified and processes fully understood.

Playbooks are algorithms for the meatware: they maximise efficiency when operating within a fully understood environment. They are inhabited exclusively by known knowns. No playbook will ever say, “if the counterparty will not agree this, make a judgment about what you think is best.” All will say, “any deviations from this requirement must be approved by Litigation and at least one Credit officer of at least C3 rank.”

As far as they go, playbooks speak to the belief that, as normal science, the only material risk lies in not complying with established rules: they are of a piece with the doctrine of precedent: when you run out of road, you must appeal to a higher authority. This you do escalating 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 it will become part of the corpus and be fed back down into the playbook of established processes.[4]

A playbook operates entirely inside the organisation’s real risk tolerance boundaries. This is a good thing from a risk monitoring perspective, and is inevitable as a matter of organisational psychology — if in doubt, stick it in, as Casanova used to say — but it all comes at the cost of efficiency.

In theory the control function will in turn have its own playbook, and the “court of first instance” is as bound by that as the baseline process is by the basic playbook. There is an algorithm, a recipe, and the main ill that comes about is by not following it. Hence the existence of an internal audit function.

And are we even going to talk about the fact that the big shock risks that hit the systems are never ones that have previously been recognised, analysed and subjected to constant monitoring? Black swans gonna be black swans, yo.

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. For example:

Risk Control Department A has stipulated starting position X, but has recognised that if a 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, there will then follow an extended firefight between risk personnel representing either organisation — albeit conducted through their uncomprehending negotiation personnel in Bratislava — 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 client base 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.

But look at this from above: only positions X through Z are in anyway codified. The key decision has been made by Risk personnel essentially making it up as they go along. The playbook hasn’t helped. Rather it has convoluted the easy part of the negotiation.

By creating the playbook Risk Control Department A is stipulating position X where in reality it will accept position Z or even Z'. The playbook, and all those wonderful systems and controls, in play only for a portion of the negotiation between X and Y, being a position a mile behind the front line.

No doubt this will generate copious management information and statistics with which middle management can regale their superiors with Gantt charts, dashboards 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 the Slovak Republic, your new clients would prefer to be hand-held by a salesperson in London than a school leaver in a call centre in Bratislava.[5]

What to do? Negotiation snags are either formal or substantive. Formal hitches arise when clients (or their negotiation teams, which will also have been outsourced to Bratislava) won’t understand your terms and will therefore challenge them. Substantive hitches arise when clients 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.[6]

The answer to both lies in product design and consideration of user experience.

Simplify

For the confusing and 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 lwon’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

If you know you will settle at at least Z, then what are you doing starting at X? Other than a clibj of glasses in the risk team for a job well done, what have you achieved?

Yes, these are marginally preferable risk control terms, but if they are meaningfully better, then you should not be prepared to go as far as Z.

Identify walk away points and stick with them.



See also

References

  1. This is a bad idea. See Roger Martin’s The Design of Business: Why Design Thinking is the Next Competitive Advantage.
  2. 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.
  3. The Structure of Scientific Revolutions. Brilliant book. Read it.
  4. This rarely happens in practice. Control functions 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).
  5. Granted, in this day and age, your client is almost certainly housing its negotiation probability out of a call centre in Bratislava, too.
  6. Best example is the hypothetical broker dealer valuation terms in a synthetic equity swap.