Playbook: Difference between revisions
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
{{G}}{{A|negotiation|}} | {{G}}{{A|negotiation|}} | ||
A [[playbook]] is a comprehensive set of guidelines, policies, rules and | A [[playbook]] is 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 school-leaver in Bucharest to whom you have off-shored your [[master agreement]] {{t|negotiation}}s. She will need it because, being a school-leaver from Bucharest, she won’t have the first clue about the [[Subject matter expert|subject matter]] of the [[negotiation]], and will need to consult it to decide what do to should her counterparty object to any of the preposterous terms your [[risk controller|risk]] team has insisted go in the first draft of the {{t|contract}}, as it will certainly do, to all of them. | ||
[[Playbook]]s derive from a couple of mistaken beliefs: One, that a valuable business can be “solved” and run as an [[algorithm]], not a [[heuristic]];<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, it is a sensible allocation of resources to have a cheap and stupid human being run that process rather than a machine.<ref>Assumption two in fact falsifies assumption one. If it really is entirely mechanistic, there is absolutely no reason to have a human operating the process.</ref> | [[Playbook]]s derive from a couple of mistaken beliefs: One, that a valuable business can be “solved” and run as an [[algorithm]], not a [[heuristic]];<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, it is a sensible allocation of resources to have a cheap and stupid human being run that process rather than a machine.<ref>Assumption two in fact falsifies assumption one. If it really is entirely mechanistic, there is absolutely no reason to have a human operating the process.</ref> | ||
Revision as of 13:55, 30 August 2019
|
|
Negotiation Anatomy™
|
A playbook is 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 school-leaver in Bucharest to whom you have off-shored your master agreement negotiations. She will need it because, being a school-leaver from Bucharest, she won’t have the first clue about the subject matter of the negotiation, and will need to consult it to decide what do to should her counterparty object to any of the preposterous terms your risk team has insisted go in the first draft of the contract, as it will certainly do, to all of them.
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 and stupid human being run that process rather than a machine.[2]
In Thomas Kuhn’s conception of it[3] playbooks are 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. The inhabit the known knowns.
As far as they go playbooks speak to the belief that the only material risk lies in not complying with established rules: They are of a piece with the doctrine of precedent: when they run out of road, one must appeal to the help of a higher authority, by means of escalation to a control function, the idea being (in theory, if not in practice) that the control function will develop the algorithm to deal with the new situation — stare decisis — and it will become part of the corpus and be fed back down into the playbook of established process.[4] The algorithm operates set inside the organisation’s risk tolerance (this is a good thing from a risk monitoring perspective, but a bad one from an efficiency perspective, as escalation is a wasteful and costly exercise.
In theory the control function will 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. Two roles:
- (i) identifying the rule set, and
- (ii) seeking data as to compliance with it. It is a formal role only.
Note the behaviour that this encourages: following an if/then logic structure requires no understanding of the underlying subject of the process (you don’t need to know how an internal combustion engine works to drive a car), and indeed such comprehension risks challenge to or subversion of that process: subject matter expertise might incline one to take a view on a formal, non material issue. That might accelerates the particular item through the system, but at a cost to the integrity of the process.
Integrity of the process is everything in modern risk management dogma.
The other thing about subject matter experts is that they are expensive, also a cardinal sin in an industry where the highest calling is cost reduction. The ideal “process participant” costs nothing, follows instructions with perfect fidelity, doesn't break down or make errors, and certainly doesn't think or question the process: that is, it is a computer. In the same way a machine doesn't question its programme (it can't), a process participant escalates within the process, but doesn’t question it. the difference is that cantakerous human process participants can.
But therein the problem: if the process can be computerised, why hasn’t it been?
There is a paradox here, though, because to get the best outcome within the playbook parameters requires a degree of advocacy, inasmuch as the process participant is facing the outside world (beyond the playbook control) - you can best negotiate if you understand your subject material.
The portfolio risk engine ascribes the same value to any outcome as long as it conforms to the playbook. The principle measurement is cost (lack of) and then speed.
The theory is we operationalise a negotiation process. We divide into doers — process participants and thinkers “process designers”. Wherever there is a playbook, the demands of fidelity and economy require a deskilling and de-emphasis of subject matter expertise from the process participants.
The same does not hold for the process designers. BUT — and here's the thing: if we also operationalise the escalation process — and the dogma of internal audit and the bottom line imperative see to it that we do — we wind up with a series of nested playbooks stretching up and across the organisation, and the real expertise (internal audits) becomes expertise in the operational parameters of the different layers and abstractions of operational playbook: reconciling them, testing them for consistency and compatibility, while in the mean time subject matter expertise — of the actual substantive content of the operation — has leaked out of the whole system.
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.
See also
References
- ↑ This is a bad idea. See Roger Martin’s The Design of Business: Why Design Thinking is the Next Competitive Advantage.
- ↑ Assumption two in fact falsifies assumption one. If it really is entirely mechanistic, there is absolutely no reason to have a human operating the process.
- ↑ The Structure of Scientific Revolutions. It's a brilliant book. Read it.
- ↑ This is rarely what 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).