General systems unit: Difference between revisions
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
(13 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
{{a| | {{a|gsv|{{image|Magrathea|png|}}}} | ||
=== | ===[[GSV questionnaire]]=== | ||
==The general systems unit== | |||
*A resource for optimising legal and ''human'' processes and systems. | |||
*In scope: design, language, legal, psychology, client experience, technology | |||
What it ''isn’t'' | |||
*A plain-English drafting service | |||
*A legal technology platform | |||
==Metaproblems== | |||
How to get people to engage. How to get people be step outside their paradigm and rethink something they might not think is broken. | |||
==Purpose== | |||
*What is the ''[[purpose]]'' of the legal department? Wider: what is the purpose of any part of the [[federation]]? | *What is the ''[[purpose]]'' of the legal department? Wider: what is the purpose of any part of the [[federation]]? | ||
==The “client”== | |||
The Client may not be who you think it is. | |||
*What is the problem: distinguish between problems and symptoms. Inanimate objects — like documents, and templates — are rarely problems: they are ''symptoms'' of problems. Formal structures are rarely problems (or even all that relevant). Problems arise in interactions For example: a crappy document | ==='''''What'' is a “client”?'''=== | ||
Someone who gives you things to do. | |||
'''Business clients''': Clients may be imposed by business imperative to sell stuff — in which case your internal client is the internal representation of the client to whom the firm is selling something — Sales — or the internal representative of the firm in that transaction with the client — Trading. | |||
'''Infrastructural clients''': Client relationships are also imposed by the formal infrastructure of the firm. Here you may be “service provider” to another “client”, or you may be “client” to another “service provider”. | |||
==='''''Who'' is your client?''' === | |||
The “business” — front office; sales and trading; the revenue generators are not your only client. In fact, it is barely a client at all. It would rather it ''didn’t'' give legal anything to do, since legal only slows it down: “Sure, do whatever you must do, but just be quick about it and don’t upset my client”. More important client [[stakeholder]]s : | |||
*Line management. | |||
*Other horizontal siloes who hold a stake in your work product: credit, tax, compliance etc: here you need their consent to carry on your task for someone else (usually the business). | |||
*Other horizontal siloes whose work product you hold a stake in: [[operations]], [[chief operating office]]. Here, ''they'' need ''your'' consent to carry on ''their'' function. | |||
'''Who, ''within'' your client, is your client'''? | |||
Are you getting calls from contractors in Hyderabad? Rather than throttling legal demand by charging for it, why not do that structurally, but limiting who — what grade — is allowed to seek it? | |||
==The “product”== | |||
The product may not be what you think it is. The product is the task to be achieved; the problem to be solved. | |||
'''Where are you going''': Thought experiment, to separate the essence of the product from its [[substrate]]: imagine all today’s limitations and technological, conceptual constraints no longer apply. Imagine you are an undefined point in the future where logistical problems have been ''solved'': you know, when there are flying cars, teleportation, we live in a virtual matrix and the analogue world has been conclusively proved to be an optical illusion. | |||
You don’t need paper, you don’t need email, you don’t need humans — this is a thought experiment, remember: The [[AI]] embedded in the General Systems Vehicle ''Just Because You’re Paranoid Doesn’t Mean No-one’s Following You'' can automatically configure agreements by itself. | |||
Now: in that scenario, what would your process look like then? What, in other words, is its [[Platonic form|Platonic essence]], that cannot be reduced by optimising [[Legal services delivery|legal service delivery]]? That is your product. Once you know that, then, considering everything you know now, and all [[adjacent possibilities]], and recognising the infinite number of useful things you don’t know, that if you did know, might send you in a different direction, what practical step can you take ''today'' that would lead in the direction that today looks like the optimal one? | |||
What wasteful processes or componentry can you remove? | |||
What new processes can you instill that will make the machine run better? | |||
Tomorrow, having taken that step, ask yourself that question again, afresh, based on the information and the [[adjacent possibilities]] open to you tomorrow. | |||
Rinse, repeat. This is [[iteration]]; this is super-forecasting: continually cleansing, reconsidering and rebasing, based on currently understood state of affairs. | |||
What do we have available to us to imagine that future: | |||
'''Where did you come from''': How did your process/problem get to where it was? Did it spring, fully formed, from the brow of the superbrain, or is it the result of a long, iterating, series of feedback loops: i.e., a malfunctioning system? If it is, you can’t fix the problem without fixing the system. | |||
=== ''Tools'' and ''expertise''. === | |||
Do not confuse tools and expertise. Tools ''facilitate'' expertise. They ''amplify'' expertise. They cannot replace it. | |||
=== Expertise === | |||
==== Lawyers ==== | |||
A [[lawyer]] is not the product. What do lawyers want, and how do lawyers function best? Autonomy, mastery, purpose. | |||
How do your tools deliver Access to knowledge. | |||
==== Knowledge ==== | |||
=== Tools === | |||
==== Documents ==== | |||
We call it work product but a legal ''document'' is not the product. It is evidence of the product. Likewise, a bad document is not the problem. It is a ''symptom'' of the problem. | |||
==== Technology ==== | |||
[[Technology]] is not the product. It is a tool for solving the problem, or delivering the product. Technology cannot replace expertise | |||
==The problem== | |||
*What is the problem: distinguish between problems and symptoms. Inanimate objects — like documents, and templates — are rarely problems: they are ''symptoms'' of problems. Formal structures are rarely problems (or even all that relevant). Problems arise in interactions For example: a crappy document | |||
*Is what we focus on really the problem? | *Is what we focus on really the problem? | ||
=== | ===Tools=== | ||
*[[Problem solving module]] | |||
*[[Process analysis module]] | |||
*[[Escalation threshold]] | |||
{{Sa}} |
Latest revision as of 14:33, 3 January 2023
|
GSV questionnaire
The general systems unit
- A resource for optimising legal and human processes and systems.
- In scope: design, language, legal, psychology, client experience, technology
What it isn’t
- A plain-English drafting service
- A legal technology platform
Metaproblems
How to get people to engage. How to get people be step outside their paradigm and rethink something they might not think is broken.
Purpose
- What is the purpose of the legal department? Wider: what is the purpose of any part of the federation?
The “client”
The Client may not be who you think it is.
What is a “client”?
Someone who gives you things to do.
Business clients: Clients may be imposed by business imperative to sell stuff — in which case your internal client is the internal representation of the client to whom the firm is selling something — Sales — or the internal representative of the firm in that transaction with the client — Trading.
Infrastructural clients: Client relationships are also imposed by the formal infrastructure of the firm. Here you may be “service provider” to another “client”, or you may be “client” to another “service provider”.
Who is your client?
The “business” — front office; sales and trading; the revenue generators are not your only client. In fact, it is barely a client at all. It would rather it didn’t give legal anything to do, since legal only slows it down: “Sure, do whatever you must do, but just be quick about it and don’t upset my client”. More important client stakeholders :
- Line management.
- Other horizontal siloes who hold a stake in your work product: credit, tax, compliance etc: here you need their consent to carry on your task for someone else (usually the business).
- Other horizontal siloes whose work product you hold a stake in: operations, chief operating office. Here, they need your consent to carry on their function.
Who, within your client, is your client?
Are you getting calls from contractors in Hyderabad? Rather than throttling legal demand by charging for it, why not do that structurally, but limiting who — what grade — is allowed to seek it?
The “product”
The product may not be what you think it is. The product is the task to be achieved; the problem to be solved.
Where are you going: Thought experiment, to separate the essence of the product from its substrate: imagine all today’s limitations and technological, conceptual constraints no longer apply. Imagine you are an undefined point in the future where logistical problems have been solved: you know, when there are flying cars, teleportation, we live in a virtual matrix and the analogue world has been conclusively proved to be an optical illusion.
You don’t need paper, you don’t need email, you don’t need humans — this is a thought experiment, remember: The AI embedded in the General Systems Vehicle Just Because You’re Paranoid Doesn’t Mean No-one’s Following You can automatically configure agreements by itself.
Now: in that scenario, what would your process look like then? What, in other words, is its Platonic essence, that cannot be reduced by optimising legal service delivery? That is your product. Once you know that, then, considering everything you know now, and all adjacent possibilities, and recognising the infinite number of useful things you don’t know, that if you did know, might send you in a different direction, what practical step can you take today that would lead in the direction that today looks like the optimal one?
What wasteful processes or componentry can you remove?
What new processes can you instill that will make the machine run better?
Tomorrow, having taken that step, ask yourself that question again, afresh, based on the information and the adjacent possibilities open to you tomorrow.
Rinse, repeat. This is iteration; this is super-forecasting: continually cleansing, reconsidering and rebasing, based on currently understood state of affairs.
What do we have available to us to imagine that future:
Where did you come from: How did your process/problem get to where it was? Did it spring, fully formed, from the brow of the superbrain, or is it the result of a long, iterating, series of feedback loops: i.e., a malfunctioning system? If it is, you can’t fix the problem without fixing the system.
Tools and expertise.
Do not confuse tools and expertise. Tools facilitate expertise. They amplify expertise. They cannot replace it.
Expertise
Lawyers
A lawyer is not the product. What do lawyers want, and how do lawyers function best? Autonomy, mastery, purpose.
How do your tools deliver Access to knowledge.
Knowledge
Tools
Documents
We call it work product but a legal document is not the product. It is evidence of the product. Likewise, a bad document is not the problem. It is a symptom of the problem.
Technology
Technology is not the product. It is a tool for solving the problem, or delivering the product. Technology cannot replace expertise
The problem
- What is the problem: distinguish between problems and symptoms. Inanimate objects — like documents, and templates — are rarely problems: they are symptoms of problems. Formal structures are rarely problems (or even all that relevant). Problems arise in interactions For example: a crappy document
- Is what we focus on really the problem?