![\"shared](\"https://notionparallax.co.uk/assets/shared-understanding.png\")
![\"shared](\"https://notionparallax.co.uk/assets/shared-understanding-human-comp.png\")
Lots of tasks are too big for one person to do. Most orgs use some kind of hierarchical model to get these kinds of big jobs done. This means concentrating power and responsibility in the hands of one person who then breaks the job up into tasks. They then assign those tasks to someone else to do.\n\nSaying _someone else_ is a lazy way of saying _entity with the capacity to get the task done_. That might be a future version of themselves, or another person, or a donkey or a computer. All that matters is that there are two entities that are capable of developing a shared understanding. Once that understanding is in place the other entity can go off and do the task.\n\nIf we explore that in a few ways:\n\n- Alice and Bob discuss how to achieve the goal of drinking a cup of tea. Alice delegates tea making to Bob. Bob makes the cup of tea and brings it back to Alice.\n- Charlie wants to do some arithmetic. He punches some numbers into a spreadsheet and gets an answer back.\n- Daisy works at a nuclear plant. The control computer spots an irregularity and sends Daisy off to look at it. Daisy brings a report back to the computer.\n- The _edit_ function in a word processor calls the _format_ function. It then returns some formatted results.![\"comp](\"https://notionparallax.co.uk/assets/comp-masters.png\")
\n\n![\"org](\"https://notionparallax.co.uk/assets/org-tree.png\")
None of these are perfect examples, but they give you the idea of one agent getting another agent to do something for them. Usually this is more like a chain, where one person delegates down the chain to get things done[^1].\n\nProgramming a computer is just delegating to it using a tightly controlled set of commands. In human-human interaction we use empathy to substitute for precision. Computers are short on empathy, but good at precision and attention to detail.\n\nComputers will do whatever you ask them to do, but only what you ask them to do. They are very fault prone. If you ask them to do something and you haven't given them an explicit instruction for what to do if it goes wrong, they'll stop. If you have managed to program them to do your bidding they'll continue to do that flawlessly for as long as you like!\n\nPeople are incredibly fault tolerant. They can find all kinds of ingenious ways to complete their tasks in the face of adversity. The problem is that they lack precision, so getting to a shared understanding is difficult.[^2]\n\nAll kinds of delegation need some kind of shared understanding. A computer does this by having libraries of functions and people do it by having common life experiences. If two humans have a common language they can communicate commands incredibly tersely. A great example of this is ER staff communicating a patient's state and what they need to do next. This common language takes a long time to develop and it is like learning the commands in a programming language. If people don’t share an explicit set of commands then the ambiguity is a problem but not an insurmountable one. It just needs the two people to negotiate more[^3].\n\n\nIf we can agree on most of that then maybe we can agree that **delegation is analogous to programming**.\n\nA more difficult task might be convincing you that thinking this way is a useful mental tool. My reasoning goes like this:\n\n1. Most tasks can be decomposed and then delegated, often recursively.\n1. Eventually some part of that task will be automatable.\n\nThis isn't very complicated. The useful part comes when you think about a _frontier of automation_. As technology gets more sophisticated that frontier keeps moving closer to the initial delegator.\n\nOnce you have the idea of a frontier of automation you can blur it a bit. There are things that you:\n\n- can do and a future version of yourself will do them\n- can do, but it'd be better if someone else did them\n- can't do so someone else needs to do them\n\nThe second two are prime for delegation. Using the mental tools developed by programmers you can think about how to best get things done.\n\n[^1]: realistically it's _much_ more complicated once you need to interact with customers etc. Triggers come from all over the place, but they can probably be abstracted away with subsystems. The more important question is if that's a good idea. This is just one way of thinking, a wrong model if you like.\n\n[^2]: Dave thinks that the precision problem is too great. This might as well be a problem of kind not degree as compilers can't handle the ambiguity. I'm more optimistic and think that we'll develop a way that we'll be able to do natural language programming soon.\n\n[^3]: a lot of the problems I see in life come from people not developing enough shared understanding. I've just started reading about this a bit in User Story Mapping by Jeff Patton.\n",
"content_html": "I think that delegation to another person is analogous to programming a computer. I want to explain why I think this, and how thinking like this can be useful.
\n\nProgramming as a discipline has developed loads of ways of making code better. That might mean more efficient, easier to understand, easier to maintain etc. The general term for this tidy up process is refactoring. If you think of delegation as a function call to a human then you can refactor the way you do things to make them better.
\n\nLots of tasks are too big for one person to do. Most orgs use some kind of hierarchical model to get these kinds of big jobs done. This means concentrating power and responsibility in the hands of one person who then breaks the job up into tasks. They then assign those tasks to someone else to do.
Saying someone else is a lazy way of saying entity with the capacity to get the task done. That might be a future version of themselves, or another person, or a donkey or a computer. All that matters is that there are two entities that are capable of developing a shared understanding. Once that understanding is in place the other entity can go off and do the task.
\n\nIf we explore that in a few ways:
\n\nNone of these are perfect examples, but they give you the idea of one agent getting another agent to do something for them. Usually this is more like a chain, where one person delegates down the chain to get things done1.
Programming a computer is just delegating to it using a tightly controlled set of commands. In human-human interaction we use empathy to substitute for precision. Computers are short on empathy, but good at precision and attention to detail.
\n\nComputers will do whatever you ask them to do, but only what you ask them to do. They are very fault prone. If you ask them to do something and you haven’t given them an explicit instruction for what to do if it goes wrong, they’ll stop. If you have managed to program them to do your bidding they’ll continue to do that flawlessly for as long as you like!
\n\nPeople are incredibly fault tolerant. They can find all kinds of ingenious ways to complete their tasks in the face of adversity. The problem is that they lack precision, so getting to a shared understanding is difficult.2
\n\nAll kinds of delegation need some kind of shared understanding. A computer does this by having libraries of functions and people do it by having common life experiences. If two humans have a common language they can communicate commands incredibly tersely. A great example of this is ER staff communicating a patient’s state and what they need to do next. This common language takes a long time to develop and it is like learning the commands in a programming language. If people don’t share an explicit set of commands then the ambiguity is a problem but not an insurmountable one. It just needs the two people to negotiate more3.
\n\nIf we can agree on most of that then maybe we can agree that delegation is analogous to programming.
\n\nA more difficult task might be convincing you that thinking this way is a useful mental tool. My reasoning goes like this:
\n\nThis isn’t very complicated. The useful part comes when you think about a frontier of automation. As technology gets more sophisticated that frontier keeps moving closer to the initial delegator.
\n\nOnce you have the idea of a frontier of automation you can blur it a bit. There are things that you:
\n\nThe second two are prime for delegation. Using the mental tools developed by programmers you can think about how to best get things done.
\n\nrealistically it’s much more complicated once you need to interact with customers etc. Triggers come from all over the place, but they can probably be abstracted away with subsystems. The more important question is if that’s a good idea. This is just one way of thinking, a wrong model if you like. ↩
\nDave thinks that the precision problem is too great. This might as well be a problem of kind not degree as compilers can’t handle the ambiguity. I’m more optimistic and think that we’ll develop a way that we’ll be able to do natural language programming soon. ↩
\na lot of the problems I see in life come from people not developing enough shared understanding. I’ve just started reading about this a bit in User Story Mapping by Jeff Patton. ↩
\n