> How can an organization complete the most goals in the least amount of time, eking out enough surplus to keep the crank turning? Thin rules may be quicker to infer results from than thick rules, though they are likely to be wrong in unsatisfying ways. Which region may work best for this goal? How should rules be designed and optimized for speed?
These questions focus too much on speed. Rules aren't a technology for going as fast as possible, they're for going as fast as necessary to make good decisions. Speed helps adapt to a changing environment, but only up to a point. And goals are usually not a checklist to be weighed by the bushel. Instead I prefer the framing of decision trees rooted in a single goal that you hit or hit not. There is no partial credit.
That's a good point, rules aren't a technology for going fast. Greater velocity comes *despite* the rules as opposed to because of them. However, I think what we'll find is there are crippling rules that make quick decisions/goals/pivots etc. impossible to hit and there are other rules that maybe don't impact velocity as negatively. These questions were purely framed to contrast longevity with speed.
Okay, hopefully this isn't too contrived but an easy one is around getting workplace reimbursements. An example of a thin rule is, every transaction <$75 is auto-approved. This can be really fast *but* let's say someone spends $80 on something, typically this can result in a long back and forth till we find someone to do the actual approval.
On the other hand, if the rule is say, every transaction needs to be approved by Alice in accounting, then that's a thick rule, because Alice is going to use her judgement. In this case, while it could be slower per transaction, there is a decent chance that Alice is better placed to approve quickly an $80 transaction and also even flag $50 transactions that shouldn't go through.
A lot of choosing which rule makes sense depends on the alignment of the people in question (which is the other axis of the 2x2).
Ah, I see. I misunderstood what you mean by "velocity'. You're thinking about the rate of decisions, while I'm thinking of the rate at which an org is adapting to its environment. Example velocity metrics: employee count or revenue. In your example above, your reimbursement rules might affect employee retention or the effectiveness of your salesforce and therefore your revenue.
In my mind the trade-off between longevity and velocity was: you might choose to grow revenue more slowly to ensure the growth is sustainable. (For example.)
Can you now illustrate your notion of "longevity" with an example? Do you mean something like, "reimbursements continue to be granted even when Alice is on vacation"? I was thinking more along the lines of the lifetime of the org as a whole.
Yes exactly, reimbursements continue even when key personnel are gone. The whole org is more resilient and can survive lean periods.
I think the disconnect here is that to me, the larger organization-level questions are answered by smaller, bottoms-up phenomena. I wouldn't consider revenue a function of velocity. It's more a trailing indicator of many different aspects (market conditions, social dynamics, team competence). The rate of decisions is something that *can* be controlled for and is definitely an input but it's more closely related to velocity.
Similarly, longevity is not meant to be an opposite of velocity (it's just a correlate - in the analogy to animals).
Oh I just noticed that velocity is in fact one of the three dimensions you started out with. I'd forgotten that by the time I got to the end of the post.
Stepping back a bit, what are the failure modes if you choose poor rules? The urgent question is how to keep the org chugging along, but this seems well-understood. The less urgent but important question to me is how to keep the bureaucratic creep from ossifying the org over time. This seems like the open problem to me. Payment reimbursements in isolation won't be a big deal, but single rules like that are easy to add and hard to delete.
Your taxonomy is a useful lens to address this open problem, but I'm inclined to reorganize it slightly. Alignment is a symptom of the problem (bureaucratic creep can itself reduce alignment; defecting becomes more tempting as cooperation becomes more difficult), thickness is the spectrum of solutions, and velocity is an essential metric you want to satisfice but not optimize.
I like to think about rules in OODA terms. The current set of rules is the observe-decide-act System 1. As we add rules we periodically need to re-orient, refactor, delete some rules. Orgs are bad at this System-2 metagame in my experience, that's what kills them.
> How can an organization complete the most goals in the least amount of time, eking out enough surplus to keep the crank turning? Thin rules may be quicker to infer results from than thick rules, though they are likely to be wrong in unsatisfying ways. Which region may work best for this goal? How should rules be designed and optimized for speed?
These questions focus too much on speed. Rules aren't a technology for going as fast as possible, they're for going as fast as necessary to make good decisions. Speed helps adapt to a changing environment, but only up to a point. And goals are usually not a checklist to be weighed by the bushel. Instead I prefer the framing of decision trees rooted in a single goal that you hit or hit not. There is no partial credit.
That's a good point, rules aren't a technology for going fast. Greater velocity comes *despite* the rules as opposed to because of them. However, I think what we'll find is there are crippling rules that make quick decisions/goals/pivots etc. impossible to hit and there are other rules that maybe don't impact velocity as negatively. These questions were purely framed to contrast longevity with speed.
Perhaps I need some examples. After this exchange I'm starting to think I don't understand your point as well as I thought.
Okay, hopefully this isn't too contrived but an easy one is around getting workplace reimbursements. An example of a thin rule is, every transaction <$75 is auto-approved. This can be really fast *but* let's say someone spends $80 on something, typically this can result in a long back and forth till we find someone to do the actual approval.
On the other hand, if the rule is say, every transaction needs to be approved by Alice in accounting, then that's a thick rule, because Alice is going to use her judgement. In this case, while it could be slower per transaction, there is a decent chance that Alice is better placed to approve quickly an $80 transaction and also even flag $50 transactions that shouldn't go through.
A lot of choosing which rule makes sense depends on the alignment of the people in question (which is the other axis of the 2x2).
Ah, I see. I misunderstood what you mean by "velocity'. You're thinking about the rate of decisions, while I'm thinking of the rate at which an org is adapting to its environment. Example velocity metrics: employee count or revenue. In your example above, your reimbursement rules might affect employee retention or the effectiveness of your salesforce and therefore your revenue.
In my mind the trade-off between longevity and velocity was: you might choose to grow revenue more slowly to ensure the growth is sustainable. (For example.)
Can you now illustrate your notion of "longevity" with an example? Do you mean something like, "reimbursements continue to be granted even when Alice is on vacation"? I was thinking more along the lines of the lifetime of the org as a whole.
Yes exactly, reimbursements continue even when key personnel are gone. The whole org is more resilient and can survive lean periods.
I think the disconnect here is that to me, the larger organization-level questions are answered by smaller, bottoms-up phenomena. I wouldn't consider revenue a function of velocity. It's more a trailing indicator of many different aspects (market conditions, social dynamics, team competence). The rate of decisions is something that *can* be controlled for and is definitely an input but it's more closely related to velocity.
Similarly, longevity is not meant to be an opposite of velocity (it's just a correlate - in the analogy to animals).
Oh I just noticed that velocity is in fact one of the three dimensions you started out with. I'd forgotten that by the time I got to the end of the post.
Stepping back a bit, what are the failure modes if you choose poor rules? The urgent question is how to keep the org chugging along, but this seems well-understood. The less urgent but important question to me is how to keep the bureaucratic creep from ossifying the org over time. This seems like the open problem to me. Payment reimbursements in isolation won't be a big deal, but single rules like that are easy to add and hard to delete.
Your taxonomy is a useful lens to address this open problem, but I'm inclined to reorganize it slightly. Alignment is a symptom of the problem (bureaucratic creep can itself reduce alignment; defecting becomes more tempting as cooperation becomes more difficult), thickness is the spectrum of solutions, and velocity is an essential metric you want to satisfice but not optimize.
I like to think about rules in OODA terms. The current set of rules is the observe-decide-act System 1. As we add rules we periodically need to re-orient, refactor, delete some rules. Orgs are bad at this System-2 metagame in my experience, that's what kills them.