- Location
- Somewhere over the rainbow
Excellent.A bunch of people said:
This post is divided into two sections: a summarization of my reading of Building State Capability, and a proposed implementation plan in Marked for Death.
The book I consulted for this post is Building State Capability, which is a book published by Harvard's Center for International Development. Link to a free pdf version source here.
One line summary: A book on develomental economics that says policy doesn't mean shit if not implemented, so here's an approach for reformists in developing nations to implement lasting reforms.
One paragraph summary: Copying the doctrines and solutions of modern, developed countries is at minimum mostly neutral, and at worst actively harmful with the goal of developing nations. Instead of trying to adopt modern solutions, target solving problems and/or improving the situation, and break said problem down into multiple problems. Then, iteratively find solutions to resolve the smaller problems with the goal of improving the situation. Continually experiment and iterate with solutions to subproblems, checking them off and occassionally reassessing progress towards an improvement in the situation. Make sure to secure a wide range of authorization from a wide range of authorizers. Scale for long-term gains.
Longer form, chapter by chapter summaries as I deem relevant:
This first chapter lays out that for all the money that went to developing nations since WWII, the capability of developing nations to actually deliver on policy promises is actually kinda abysmal; for one pithy example, in the 159 nations whose post offices promise to return misaddressed letters within 90 days, even in the highest quartile by income only about 60% of letters in an experiment were actually returned to sender.
In other words, billions of dollars has been spent and all sorts of policy has been passed - but states lack the capability to implement those policies, so those brilliant policies from developed nations just sit there.
In other words, billions of dollars has been spent and all sorts of policy has been passed - but states lack the capability to implement those policies, so those brilliant policies from developed nations just sit there.
A huge part of the problem is that one solution that ends up locking itself in is "isomorphic mimicry" - "looks like" substitutes for "does". One example: Passing a labor law is counted as success, not, you know, actually enforcing that labor law to make life better for workers. The reason for doing this: the organization/nation/project ends up looking legitimate without needing to go through all the trouble of actually being legitimate.
In ratsphere terms: The map ain't the territory, but pretending the map is gives you money, so organizations get stuck in it.
This is a capital P Problem because what ends up happening is that internal and external pressures to "look like a functioning state" eventually oppose efforts to "be a functional state".
This failure state tends to show up in organizations where the surrounding ecosystem is closed to novelty - aka an organization does not accept new solutions and cannot be easily replaced - and whether said novelty is evaluated by how closely it conforms to the agenda or raw functionality. If both are true, it sets up a situation where conforming to a set image of success is prioritized over actually succeeding, setting up a continuous failure-state.
The way this failure state becomes a trap is when you try to move from measuring success by how closely the organization conforms to the right forms to how well you actually function. Because "success" everywhere else has been measured by theoretical compliance to the forms, and reforms push to measure success by actual compliance, most reforms to systems that got caught in the "solution" of isomorphic mimicry end up looking like huge failures because everyone else is lying their asses off. Worse, reforms are risky, and in a situation where the organization is locked into ismorphic mimicry the focus is on risk aversion - no way to get punished for doing things just like how everyone else does it, lots of ways to get punished for failing to succeed on a risky endeavor. Thus, adopting isomorphic mimicry to look like a functional organization ends up stopping efforts to actually become a functional organization.
In ratsphere terms: The map ain't the territory, but pretending the map is gives you money, so organizations get stuck in it.
This is a capital P Problem because what ends up happening is that internal and external pressures to "look like a functioning state" eventually oppose efforts to "be a functional state".
This failure state tends to show up in organizations where the surrounding ecosystem is closed to novelty - aka an organization does not accept new solutions and cannot be easily replaced - and whether said novelty is evaluated by how closely it conforms to the agenda or raw functionality. If both are true, it sets up a situation where conforming to a set image of success is prioritized over actually succeeding, setting up a continuous failure-state.
The way this failure state becomes a trap is when you try to move from measuring success by how closely the organization conforms to the right forms to how well you actually function. Because "success" everywhere else has been measured by theoretical compliance to the forms, and reforms push to measure success by actual compliance, most reforms to systems that got caught in the "solution" of isomorphic mimicry end up looking like huge failures because everyone else is lying their asses off. Worse, reforms are risky, and in a situation where the organization is locked into ismorphic mimicry the focus is on risk aversion - no way to get punished for doing things just like how everyone else does it, lots of ways to get punished for failing to succeed on a risky endeavor. Thus, adopting isomorphic mimicry to look like a functional organization ends up stopping efforts to actually become a functional organization.
The fundamental problem is that organizations must be assigned achievable goals - it doesn't matter how good the policy looks, if the organization is incapable of applying it due to internal or external stress, the result will be that the policy will not be accomplished, and in fact the stresses involved can completely destroy an organization's capability to accomplish even the smallest of goals. When you have the ultimate form of this problem - asking too much of too little too often - premature load bearing ends up obliterating the legitimacy and capacity for reforms.
What happens in scenarios where too much was asked of too little is a decoupling between de jure and de facto - that is to say, the formal policy gets completely disconnected from the practical results, and the organization ends up devolving into a giant rent-collecting exercise. The typical example is tariff rates: developing countries can raise tariffs as high as they want on paper, but in practice, the tariff rate will be a little decoupled at the beginning, keep going upwards at a decreasing rate, and then at about 60% no matter how much the formal tariff rate is it simply won't be collected. At that point, the importers are willing to pay enough that the border officials stop caring about the official tariff rate. The state loses the ability to compel importers to pay tariffs, and, well, shit, now the state is not getting revenue and the customs officials are so corrupt and flush with cash that they're willing to resist the state's efforts to reform their sector.
That's why emphasizing robustness - that is to say, an organization's ability to endure stresses that internal or external actors put on the organization - is super important. Doesn't matter how impressive the organization could theoretically perform without stress on the system, the organization exists in a world with stress, and a collapsed organization makes fixing the problem later much harder.
What happens in scenarios where too much was asked of too little is a decoupling between de jure and de facto - that is to say, the formal policy gets completely disconnected from the practical results, and the organization ends up devolving into a giant rent-collecting exercise. The typical example is tariff rates: developing countries can raise tariffs as high as they want on paper, but in practice, the tariff rate will be a little decoupled at the beginning, keep going upwards at a decreasing rate, and then at about 60% no matter how much the formal tariff rate is it simply won't be collected. At that point, the importers are willing to pay enough that the border officials stop caring about the official tariff rate. The state loses the ability to compel importers to pay tariffs, and, well, shit, now the state is not getting revenue and the customs officials are so corrupt and flush with cash that they're willing to resist the state's efforts to reform their sector.
That's why emphasizing robustness - that is to say, an organization's ability to endure stresses that internal or external actors put on the organization - is super important. Doesn't matter how impressive the organization could theoretically perform without stress on the system, the organization exists in a world with stress, and a collapsed organization makes fixing the problem later much harder.
So, that said, what the heck is capability to implement policy? Well, first you have to answer what "a successful implementation of policy" even is. For example, consider college-age drinking.
Building State Capability breaks it down into four parts: "a formula that maps from facts to actions, processes for determining the policy-relevant facts, a set of objectives, and a causal model."
Processes - the processes for determining administratively relevant facts for the policy - e.g. what's their age?
Formula - function that maps from known facts to actions - e.g. if they're less than 21, don't sell to them.
Objectives - what's this policy supposed to do? - e.g. the goal is to restrict drinkers to the "fully developed adults that know what they're getting into"
Causal Model - how do the actions in the formula lead to accomplishing the objective(s)? - e.g. by restricting sales to 21 and up, college students with not fully developed brains will not drink, thus accomplishing the objective.
Putting together a capability to implement policy this way highlights two distinct ways a policy could fail to accomplish its objectives:
1) The causal model is wrong - policy formula outputs fail to result in accomplishing the objective. Scared Straight is a rather famous example of this, where the formula of "introduce children to felons" was supposed to scare children off of being criminals - and kind of did the literal exact opposite.
2) The policy formula is just not implemented - front-line agents and leaders simply do not implement the formula. The example the book gives is a study of the India's driver's license tests, where in theory you're supposed to take a test that shows that you can drive on the road safely but in practice everyone hires a tout to get them through the test, even if they should've failed.
Back to organizational capability for policy implementation. The way the book defines it as is the ability for an organization to equip their agents with the capacity (technical training), resources, and motivation to take actions that promote the organization's stated objectives. Organizations with strong capability can get their trained agents the resources and motivation necessary to successfully accomplish or exceed the organization's objectives; organizations with weak capability cannot get their agents the resources or motivation in order to accomplish their goals.
Note that this definition is distinct from just "the ability to carry out the policy formula" - the focus is on accomplishing the objective, not implementing a given solution. Remember, one of the big traps is that an organization will adopt a solution that looks like it solves a problem, instead of implementing something that actually solves the problem. Thus, the focus on capability must remain on whether an organization's policy and implementation can actually accomplish its objectives.
The book then lays out five kinds of capability to keep track of:
Ideal capability: all agents within the organization always take the best possible action overall and therefore always accomplishes the best achievable policy outcome for the organization as a whole. This assumption also assumes complete and perfect information. This is obviously completely impossible to achieve, but the goal is to approximate this sort of capability at the high end.
Policy-compliant capability: all agents within the organization follow the policy exactly and without deviations. This can be close to ideal capability, but only in situations where agents don't need to use their discretion; if agents do need to use discretion, there is a substantial gap between policy-compliant capability and ideal capability.
Actual capability: the capability of the organization in practice, where agents make their own decisions. In high capability organizations, actual capability can exceed policy-compliant capability; see any case where projections were exceeded or something ran ahead of schedule. In low capability organizations, well...
Zero capability: The result of having absolutely no organization at all. Actual capability can be this low - but it can actually go even lower.
Negative capability: Agents within the organization levy additional obligations on their subjects with no corresponding benefits, making the people the organization is supposed to serve absolutely worse off. (under these conditions, communities actively seek to become anarchic to avoid any sort of "governance", and this actually happened to some extent in Southeast Asia, according to The Art of Not Being Governed, by James Scott.)
...
(I will take this moment to ask readers to recall that podunk village that decided the Swamp of Death was a habitable area - perhaps the existence of that village suggests that Hidden Villages are, from the perspective of civilians, negative capability.)
...
Note that individual training (in book terms, technical capacity) is not the same thing as organization capacity; the easiest example is absenteeism, where the policy is not carried out, but it's pretty obvious that lack of training is not the problem.
There are generally two consequences for having weak capability to implement policy:
1) Administrative facts become complete fiction - for example, auditors being hired by companies to report pollution levels reporting the same level of pollution - just below the legal limit - regardless of whether the companies were way over or way under the cap.
2) Changing policy has completely unpredictable results - extremely similar attempts to increase attendance can either succeed, fail because everyone is manipulating the data, or fail successfully because the change increased attendance, dissatisfaction, and thus led to better outcomes because the patients just stopped going to this shitty clinics. Which of the situations the policy change will result in is basically totally unpredictable.
In summary: organizational capability is defined as the ability to achieve organizational objectives, not the ability to follow a formula.
Building State Capability breaks it down into four parts: "a formula that maps from facts to actions, processes for determining the policy-relevant facts, a set of objectives, and a causal model."
Processes - the processes for determining administratively relevant facts for the policy - e.g. what's their age?
Formula - function that maps from known facts to actions - e.g. if they're less than 21, don't sell to them.
Objectives - what's this policy supposed to do? - e.g. the goal is to restrict drinkers to the "fully developed adults that know what they're getting into"
Causal Model - how do the actions in the formula lead to accomplishing the objective(s)? - e.g. by restricting sales to 21 and up, college students with not fully developed brains will not drink, thus accomplishing the objective.
Putting together a capability to implement policy this way highlights two distinct ways a policy could fail to accomplish its objectives:
1) The causal model is wrong - policy formula outputs fail to result in accomplishing the objective. Scared Straight is a rather famous example of this, where the formula of "introduce children to felons" was supposed to scare children off of being criminals - and kind of did the literal exact opposite.
2) The policy formula is just not implemented - front-line agents and leaders simply do not implement the formula. The example the book gives is a study of the India's driver's license tests, where in theory you're supposed to take a test that shows that you can drive on the road safely but in practice everyone hires a tout to get them through the test, even if they should've failed.
I note that our clan requires all adults to take tests showing their capability to read and write before relaxing mandatory schooling. In other words, there is a test that prevents people from doing something they want, namely being able to have classtime free, and we don't know if it's actually being implemented. There seems to be a bit of a relevant comparison here.
Back to organizational capability for policy implementation. The way the book defines it as is the ability for an organization to equip their agents with the capacity (technical training), resources, and motivation to take actions that promote the organization's stated objectives. Organizations with strong capability can get their trained agents the resources and motivation necessary to successfully accomplish or exceed the organization's objectives; organizations with weak capability cannot get their agents the resources or motivation in order to accomplish their goals.
Note that this definition is distinct from just "the ability to carry out the policy formula" - the focus is on accomplishing the objective, not implementing a given solution. Remember, one of the big traps is that an organization will adopt a solution that looks like it solves a problem, instead of implementing something that actually solves the problem. Thus, the focus on capability must remain on whether an organization's policy and implementation can actually accomplish its objectives.
The book then lays out five kinds of capability to keep track of:
Ideal capability: all agents within the organization always take the best possible action overall and therefore always accomplishes the best achievable policy outcome for the organization as a whole. This assumption also assumes complete and perfect information. This is obviously completely impossible to achieve, but the goal is to approximate this sort of capability at the high end.
Policy-compliant capability: all agents within the organization follow the policy exactly and without deviations. This can be close to ideal capability, but only in situations where agents don't need to use their discretion; if agents do need to use discretion, there is a substantial gap between policy-compliant capability and ideal capability.
Actual capability: the capability of the organization in practice, where agents make their own decisions. In high capability organizations, actual capability can exceed policy-compliant capability; see any case where projections were exceeded or something ran ahead of schedule. In low capability organizations, well...
Zero capability: The result of having absolutely no organization at all. Actual capability can be this low - but it can actually go even lower.
Negative capability: Agents within the organization levy additional obligations on their subjects with no corresponding benefits, making the people the organization is supposed to serve absolutely worse off. (under these conditions, communities actively seek to become anarchic to avoid any sort of "governance", and this actually happened to some extent in Southeast Asia, according to The Art of Not Being Governed, by James Scott.)
...
(I will take this moment to ask readers to recall that podunk village that decided the Swamp of Death was a habitable area - perhaps the existence of that village suggests that Hidden Villages are, from the perspective of civilians, negative capability.)
...
Note that individual training (in book terms, technical capacity) is not the same thing as organization capacity; the easiest example is absenteeism, where the policy is not carried out, but it's pretty obvious that lack of training is not the problem.
There are generally two consequences for having weak capability to implement policy:
1) Administrative facts become complete fiction - for example, auditors being hired by companies to report pollution levels reporting the same level of pollution - just below the legal limit - regardless of whether the companies were way over or way under the cap.
2) Changing policy has completely unpredictable results - extremely similar attempts to increase attendance can either succeed, fail because everyone is manipulating the data, or fail successfully because the change increased attendance, dissatisfaction, and thus led to better outcomes because the patients just stopped going to this shitty clinics. Which of the situations the policy change will result in is basically totally unpredictable.
In summary: organizational capability is defined as the ability to achieve organizational objectives, not the ability to follow a formula.
The thing is, accomplishing different objectives have very different requirements from the state's capability. Delivering mail is a very different challenge from teaching most or all of our citizens, for example.
Building State Capability breaks down tasks into five types based on answers to four types of questions:
(note: the authors are from Boston, so they used wicked hard to stand in for [extreme intensifier] hard)
The big ways these tasks differ is in determining the shape of the organization needed to effectively deliver on these tasks. For example, some of you can probably name off of the top of your head a bunch of shipping companies (logistics task), but I challenge you to name off the top of your head a private-sector organization for dentists (implementation-intensive service delivery).
The other huge way these tasks differ is in how accountability has to work in them. This book largely talks about state delivery/public-sector organizations, but I note that as a clan we're going to be doing largely the same thing.
To explain that, however, first we need to break down accountability. Accountability in general has two parts: formal accountability, and informal accountability.
However, the only situation where formal accountability is mostly sufficient is the logistics problem, where information about success can be answered relatively easily ("did the mail get delivered?") by any actor - in other words, in any case that requires actors to use local discretion, informal accountability becomes extremely important. (this is leaving aside the fact that even in logistical situations like "do the teachers show up to teach" informal accountability is still super important)
Informal accountability is basically all about whether the agents can justify themselves to themselves and the people they respect. Each agent has an account - a story they tell about their actions that justifies whatever actions they took. The moment the account of people within in organization significantly diverges from the formal accountability, we find that the formal accountability gets rewritten until the administrative facts are complete bullshit. In other words, you have to get your agents to believe that part of being a good person is accomplishing the goals of your organization.
Policy conclusion: we need to be delivering Uplift speeches more often
(Note that this is actually a huge advantage for many of the nations; Leaf has the Will of Fire, Cloud has their religion, and Sand has the fact that they're fucking idiots who settled in the middle of a desert which makes everyone necessary.)
I reiterate: if your organization requires any task that requires anybody to exercise local discretion, you need informal accountability, and thus you need a mission statement.
One final note: this book classifies the task of making organizations more capable as wicked hard. I am inclined to agree with them.
Building State Capability breaks down tasks into five types based on answers to four types of questions:
| Does the task involve lots of agents taking actions? | Does the task require agents to exercise local discretion? | Does the task require agents to provide a service or impose obligations? | Does the task use known technology? | Examples | |
| Policymaking/Elite groups | No | Yes | Either/or | Either/or | Central banks, top tier hospitals, space programs |
| Logistics | Yes | No | Either/or | Yes | Post offices, vaccination groups |
| Implementation-intensive service delivery | Yes | Yes | Service | Yes | Running hospitals, teaching students |
| Implementation-intensive imposition of obligations | Yes | Yes | Obligation | Yes | Enforcing regulations, collecting taxes |
| Wicked hard | Yes | Yes | Either/or | No | Preventative health, equity financing for startups |
(note: the authors are from Boston, so they used wicked hard to stand in for [extreme intensifier] hard)
The big ways these tasks differ is in determining the shape of the organization needed to effectively deliver on these tasks. For example, some of you can probably name off of the top of your head a bunch of shipping companies (logistics task), but I challenge you to name off the top of your head a private-sector organization for dentists (implementation-intensive service delivery).
The other huge way these tasks differ is in how accountability has to work in them. This book largely talks about state delivery/public-sector organizations, but I note that as a clan we're going to be doing largely the same thing.
To explain that, however, first we need to break down accountability. Accountability in general has two parts: formal accountability, and informal accountability.
Formal accoutability in organizations has four primary components:
Delegation - a specification of wants from principals to agents
Finance/Support - flow of resources from principals to agents
Information - information provided upon execution of actions from agents to principals (note, will be incomplete)
Motivation - Intrinsic and extrinsic motivation of agents, which can be changed by the actions of the principals.
Within public-sector organizations, moreover, there are generally four sets of principal-agent relationships:
Politics - Citizens, as principals, hold politicians, as agents, accountable for how sovereign power is used. Note that this is still applicable in MfD; most famously, as the Merchant Council, but also in a bunch of other ways.
Compact - The executive power of the state, as principals, induce public-sector organizations, as agents, to provide specific functions to the populace.
Management - the top management of public-sector organizations, as principals, induce the front-line workers, as agents, to provide functions to the people.
Client Power - Citizens, again as principals, act directly on front-line providers, as agents, to be accountable for delivery.
As accountability is a huge part of organizational capability, weak organizations typically have weak or incoherent accountability relationships within their organization. While this mostly expresses itself in the Management-Frontline relationship, you can get these sort of incoherent relationships elsewhere; bad orders in the Compact layer, impossible demands on the political layer, etc.
There are four typical ways that formal accountability in state organizations becomes incoherent:
Mismatch between delegated tasks and resources - The resources assigned by the principal are (usually grossly) insufficient for the agent to realistically complete their assigned tasks. When this happens, failure is inevitable. This can happen at any of the four levels.
Mismatch of delegation and information - The tasks the principal assigns are oriented towards accomplishing organizational objectives, but the information the principal wants is about process compliance and input usage, not whether the outputs actually accomplished the tasks. This situation tends to result in the task not being accomplished, because looking like the task is being done is considered as having the task done. This situation typically happens on the Compact and Management levels.
Mismatch between delegation and motivation - The assigned tasks are oriented to accomplish objectives, but the principal does not give either motivation or autonomy for the agent to succeed at their tasks; failure and success are recorded the same way. This primarily shows up in the Compact or Management levels.
Mismatch in objectives across actors - Even if the accountability relationships are strong, actors within the system might have different objectives across the system; for example, while management might be successfully carrying out their job to induce competence in their organization, this might conflict with the politicians in the political level giving cushy jobs to their political supporters.
Delegation - a specification of wants from principals to agents
Finance/Support - flow of resources from principals to agents
Information - information provided upon execution of actions from agents to principals (note, will be incomplete)
Motivation - Intrinsic and extrinsic motivation of agents, which can be changed by the actions of the principals.
Within public-sector organizations, moreover, there are generally four sets of principal-agent relationships:
Politics - Citizens, as principals, hold politicians, as agents, accountable for how sovereign power is used. Note that this is still applicable in MfD; most famously, as the Merchant Council, but also in a bunch of other ways.
Compact - The executive power of the state, as principals, induce public-sector organizations, as agents, to provide specific functions to the populace.
Management - the top management of public-sector organizations, as principals, induce the front-line workers, as agents, to provide functions to the people.
Client Power - Citizens, again as principals, act directly on front-line providers, as agents, to be accountable for delivery.
As accountability is a huge part of organizational capability, weak organizations typically have weak or incoherent accountability relationships within their organization. While this mostly expresses itself in the Management-Frontline relationship, you can get these sort of incoherent relationships elsewhere; bad orders in the Compact layer, impossible demands on the political layer, etc.
There are four typical ways that formal accountability in state organizations becomes incoherent:
Mismatch between delegated tasks and resources - The resources assigned by the principal are (usually grossly) insufficient for the agent to realistically complete their assigned tasks. When this happens, failure is inevitable. This can happen at any of the four levels.
Mismatch of delegation and information - The tasks the principal assigns are oriented towards accomplishing organizational objectives, but the information the principal wants is about process compliance and input usage, not whether the outputs actually accomplished the tasks. This situation tends to result in the task not being accomplished, because looking like the task is being done is considered as having the task done. This situation typically happens on the Compact and Management levels.
Mismatch between delegation and motivation - The assigned tasks are oriented to accomplish objectives, but the principal does not give either motivation or autonomy for the agent to succeed at their tasks; failure and success are recorded the same way. This primarily shows up in the Compact or Management levels.
Mismatch in objectives across actors - Even if the accountability relationships are strong, actors within the system might have different objectives across the system; for example, while management might be successfully carrying out their job to induce competence in their organization, this might conflict with the politicians in the political level giving cushy jobs to their political supporters.
However, the only situation where formal accountability is mostly sufficient is the logistics problem, where information about success can be answered relatively easily ("did the mail get delivered?") by any actor - in other words, in any case that requires actors to use local discretion, informal accountability becomes extremely important. (this is leaving aside the fact that even in logistical situations like "do the teachers show up to teach" informal accountability is still super important)
Informal accountability is basically all about whether the agents can justify themselves to themselves and the people they respect. Each agent has an account - a story they tell about their actions that justifies whatever actions they took. The moment the account of people within in organization significantly diverges from the formal accountability, we find that the formal accountability gets rewritten until the administrative facts are complete bullshit. In other words, you have to get your agents to believe that part of being a good person is accomplishing the goals of your organization.
Policy conclusion: we need to be delivering Uplift speeches more often
(Note that this is actually a huge advantage for many of the nations; Leaf has the Will of Fire, Cloud has their religion, and Sand has the fact that they're fucking idiots who settled in the middle of a desert which makes everyone necessary.)
I reiterate: if your organization requires any task that requires anybody to exercise local discretion, you need informal accountability, and thus you need a mission statement.
One final note: this book classifies the task of making organizations more capable as wicked hard. I am inclined to agree with them.
This chapter largely builds around highlighting the general approach they'll spend the next five chapters explaining. The driving metaphor is the difference between going from St. Louis to the West Coast in 1804 vs 2015. In 2015, it's a relatively simple process of grabbing a GPS, a car, some money, and hitting the gas. In 1804, it's a wicked hard problem.
It's the difference between a problem where you know the map closely corresponds to the territory, and a problem where you know the map doesn't correspond to the territory.
By and large, Building State Capability highlights that the solution to an 1804 expedition to Go West would involve a pressing desire to solve a problem (not knowing the full extent of the continent), continuous experimental iterations where teams act, check, review lessons, and then take another step (continuously checking whether the teams are in fact headed in a western direction, drawing maps and reviewing them), multiple people authorizing the project, its risks, and handing the team carte blanche to experiment, and several teams with diverse talents in order to handle all challenges, expected and not.
So then what the heck is Problem-Driven Iterative Adaption?
Problem-Driven Iterative Adaption is a process-driven strategy to implement tasks. Specifically, there are four parts to focus on:
1) Focus on specific problems in local contexts as nominated by local actors.
2) Foster ongoing, active experimental iterations with new ideas, harvesting lessons from each iteration to turn ideas into solutions to the problem(s).
3) Establish a broad authorizing environment for decisionmaking that encourages experimentation and positive deviation.
4) Engage broad sets of agents to ensure that reforms are viable, legitimate, and relevant.
It's the difference between a problem where you know the map closely corresponds to the territory, and a problem where you know the map doesn't correspond to the territory.
By and large, Building State Capability highlights that the solution to an 1804 expedition to Go West would involve a pressing desire to solve a problem (not knowing the full extent of the continent), continuous experimental iterations where teams act, check, review lessons, and then take another step (continuously checking whether the teams are in fact headed in a western direction, drawing maps and reviewing them), multiple people authorizing the project, its risks, and handing the team carte blanche to experiment, and several teams with diverse talents in order to handle all challenges, expected and not.
So then what the heck is Problem-Driven Iterative Adaption?
Problem-Driven Iterative Adaption is a process-driven strategy to implement tasks. Specifically, there are four parts to focus on:
1) Focus on specific problems in local contexts as nominated by local actors.
2) Foster ongoing, active experimental iterations with new ideas, harvesting lessons from each iteration to turn ideas into solutions to the problem(s).
3) Establish a broad authorizing environment for decisionmaking that encourages experimentation and positive deviation.
4) Engage broad sets of agents to ensure that reforms are viable, legitimate, and relevant.
Most of the most successful developmental programs focused relentlessly in on a specific problem. Attempts to implement solutions in search of a problem usually fail. However, not all problems are good for this sake; in fact, one common problem is to define problems as lack of a solution, which is counterproductive.
The key traits of a good problem, by contrast, are:
1) The problem cannot be ignored and matters to key change agents.
2) The problem can be broken down into easily addressed causal elements.
3) The problem allows real, sequenced, and strategic responses.
Naturally, this means that constructing problems is a very important part of the process. You have to turn things that people complain about but accept - what Kingdon, and this book will call "conditions" - into "problems" that key change agents have to want to resolve. You do this by raising the visibility of weaknesses through focusing events - crises, statistical indicators, feedback, and storytelling.
A key part of the problem construction step is to get to the point where you and your reformists can answer key questions:
1) What is the problem?
2) Why does it matter?
3) For whom does it matter?
4) Who needs to care more?
-4a) How do we get them to care more?
5) What will the world be like when the problem is solved?
Answers to the question should be informed by evidence, but of course we probably don't have the bandwidth to implement it on this side of the screen.
Here's two examples of problem construction, going from a solution-based approach to a problem-based approach:
PROBLEM: We need a modern sanitation system.
Why does it matter? Because we have a lot of shit around which makes disease more likely and makes it less pleasant to live here.
PROBLEM: We need to implement an internal taxation system.
Why does it matter? Because we need money to do things.
Why does it matter? Because if we cannot earn money we cannot pay for things like free housing or food or school.
By redefining the problem this way, we get a real performance deficiency that we can measure, that key agents cannot ignore, and that matter to said key agents. From there, we can answer a few more questions:
For whom does it matter? It matters to everyone living on our estate who'd like to benefit from these services.
Who needs to care more? People inside the community and the people who we'd need to fund the effort.
How do we get them to give it more attention? Cite miasma theory, raise attention, and can be provided to our civilians to support this measure.
Once you've constructed your problem, you then need to deconstruct your problem: taking your overall problem, and find component problems that flow into it so that instead of trying to tackle the whole problem at once you have a series of smaller problems that are much easier to resolve. (People who have the hobby of reading best practices manuals by corporations and organizations may note that this looks very familiar - Building State Capability freely admits that it stole the techniques from Toyota's work on production process theory).
One way to visualize this is a "fishbone diagram" or "Ishikawa diagram"; you draw the final problem at the right, draw a line from the left to the right, and then write in component problems as branches on the first line, and then write in sub-component problems as branches to the component problem branches, and at this point you should probably just google Ishikawa diagram.
By breaking a problem into these smaller components, and seeing how they all feed in, your team can create an initial plan of action to resolve a series of source problems and ensure that they stay fixed - or if they don't, that's another chance to look it over.
This process of constructing and deconstructing a problem helps the reform team visualize the problem better, and make it more possible to implement as a solution.
Moreover, this breakdown of the problem into smaller problems helps dictate in what order these problems must be solved. After all, in a situation where the organizations have low capability, let alone the larger problem, even the smaller problems are completely unsolvable. Hence, it is important to tackle the problems which even have the opportunity for a change to be made. Research indicates that there are three key factors which influence where there exists an opportunity for change. Those three factors are:
Sufficient Authority - There exists enough support to effect a specified reform or policy change.
Sufficient Acceptance - The affected population accepts the need for a specified change and implications of said change.
Sufficient Ability - There exists enough money, skills, agents, agent-time, and other such things to execute the specified change.
Wherever there is a gap, or lack in any of these categories, the opportunity for change shrinks dramatically. If even two categories are a stretch, the opportunity for change becomes nonexistent.
Therefore, it is imperative for reform teams to constantly keep close track how much of each key factors they have (yadda yadda it's qualititative and hard to know yadda yadda it's still really fucking important). Moreover, the plan of action for reforms must include seeking to shore up or increase the amount of each factor, so that reforms impossible at the beginning of the process become possible by the end of the process.
In conclusion: Define a problem with measurable performance characteristics, break it down into smaller problems, make a plan for solving the problems where you have an opportunity for change, and take actions to increase your opportunities to change the rest until step by step you resolve the entire problem.
The key traits of a good problem, by contrast, are:
1) The problem cannot be ignored and matters to key change agents.
2) The problem can be broken down into easily addressed causal elements.
3) The problem allows real, sequenced, and strategic responses.
Naturally, this means that constructing problems is a very important part of the process. You have to turn things that people complain about but accept - what Kingdon, and this book will call "conditions" - into "problems" that key change agents have to want to resolve. You do this by raising the visibility of weaknesses through focusing events - crises, statistical indicators, feedback, and storytelling.
A key part of the problem construction step is to get to the point where you and your reformists can answer key questions:
1) What is the problem?
2) Why does it matter?
3) For whom does it matter?
4) Who needs to care more?
-4a) How do we get them to care more?
5) What will the world be like when the problem is solved?
Answers to the question should be informed by evidence, but of course we probably don't have the bandwidth to implement it on this side of the screen.
Here's two examples of problem construction, going from a solution-based approach to a problem-based approach:
PROBLEM: We need a modern sanitation system.
Why does it matter? Because we have a lot of shit around which makes disease more likely and makes it less pleasant to live here.
PROBLEM: We need to implement an internal taxation system.
Why does it matter? Because we need money to do things.
Why does it matter? Because if we cannot earn money we cannot pay for things like free housing or food or school.
By redefining the problem this way, we get a real performance deficiency that we can measure, that key agents cannot ignore, and that matter to said key agents. From there, we can answer a few more questions:
For whom does it matter? It matters to everyone living on our estate who'd like to benefit from these services.
Who needs to care more? People inside the community and the people who we'd need to fund the effort.
How do we get them to give it more attention? Cite miasma theory, raise attention, and can be provided to our civilians to support this measure.
Once you've constructed your problem, you then need to deconstruct your problem: taking your overall problem, and find component problems that flow into it so that instead of trying to tackle the whole problem at once you have a series of smaller problems that are much easier to resolve. (People who have the hobby of reading best practices manuals by corporations and organizations may note that this looks very familiar - Building State Capability freely admits that it stole the techniques from Toyota's work on production process theory).
One way to visualize this is a "fishbone diagram" or "Ishikawa diagram"; you draw the final problem at the right, draw a line from the left to the right, and then write in component problems as branches on the first line, and then write in sub-component problems as branches to the component problem branches, and at this point you should probably just google Ishikawa diagram.
By breaking a problem into these smaller components, and seeing how they all feed in, your team can create an initial plan of action to resolve a series of source problems and ensure that they stay fixed - or if they don't, that's another chance to look it over.
This process of constructing and deconstructing a problem helps the reform team visualize the problem better, and make it more possible to implement as a solution.
Moreover, this breakdown of the problem into smaller problems helps dictate in what order these problems must be solved. After all, in a situation where the organizations have low capability, let alone the larger problem, even the smaller problems are completely unsolvable. Hence, it is important to tackle the problems which even have the opportunity for a change to be made. Research indicates that there are three key factors which influence where there exists an opportunity for change. Those three factors are:
Sufficient Authority - There exists enough support to effect a specified reform or policy change.
Sufficient Acceptance - The affected population accepts the need for a specified change and implications of said change.
Sufficient Ability - There exists enough money, skills, agents, agent-time, and other such things to execute the specified change.
Wherever there is a gap, or lack in any of these categories, the opportunity for change shrinks dramatically. If even two categories are a stretch, the opportunity for change becomes nonexistent.
Therefore, it is imperative for reform teams to constantly keep close track how much of each key factors they have (yadda yadda it's qualititative and hard to know yadda yadda it's still really fucking important). Moreover, the plan of action for reforms must include seeking to shore up or increase the amount of each factor, so that reforms impossible at the beginning of the process become possible by the end of the process.
In conclusion: Define a problem with measurable performance characteristics, break it down into smaller problems, make a plan for solving the problems where you have an opportunity for change, and take actions to increase your opportunities to change the rest until step by step you resolve the entire problem.
Thing is, now that you've taken a good problem and broken it down into a bunch of (hopefully temporarily) unsolvable problems, and some solutions, you need to implement those solutions. One way to do this is to steal a set of "best practices" from elsewhere (in our case, from our timeline and transplanting it into MfD's 12th century superhuman dominated landscape) and try to implement them. This runs into problems as mentioned above, most specifically in the "Looking like a state" tab, and more generally because those best practices are not adapted to local conditions or the organization's capabilities; on the three necessary factors for implementation, sufficient authority is maybe the only one that's really present.
The best solution, according to Building State Capability, emerges through active processes of iteration, experimentation, and learning - because the developmental pathway for a given context is not known, a critical part of implementing reforms must be continuously experimenting with solutions and correcting assumptions. Because the reform team knows that the map is not the territory - in fact, in MfD, the map straight up doesn't exist - the reform team needs to draw the map themselves, and continuously correct their map to better correspond to the territory.
The ideal process, then, has these characteristics:
1) Multiple solution ideas are identified and put into action.
2) Experimental and iterative steps allow real and locally legitimate solutions to emerge step by step.
3) Disciplined and experiental learning along with flexibility promotes adaption to local conditions.
In general, you have four options for where you can draw ideas from in solution ideation:
1) You can draw from current practice to figure out where the problems are - and also to improve on current practice to implement it
2) You can draw from latent practice, which is the set of potential ideas and government capabilities that are possible to implement with effort.
3) You can draw from the area of positive deviance, where a successful policy is implemented but is not the norm, find which deviation made it the successful strategy, and spread that deviation more widely until it becomes the norm.
4) You can draw from established "best practices" - most reform efforts go here and look for only one solution. More of them could be used.
Indeed, it's probably best to draw from a combination of these to fit the situation.
In terms of the actual execution of the experimental iterations, it generally involves a cycle of four steps:
Step 1: Identify action steps based on problem analysis, idea identification activities, and from talking with other members of reform teams. This is the planning phase, so the action steps should be highly detailed, with precise responsibilities, and critically, set start and stop times to determine whether the project is a success. (Short timeframes are recommended in the beginning of the process, to establish both a work-focused culture going forward and to build momentum off victories)
Step 2: Execute the action steps within the timeframe.
Step 3: Evaluate the result of the action step and answering the three questions of what was learned, achieved, and what comes next.
Step 4: Check in with superiors/peers about progress, lessons learned, and assessing whether the problem was solved. If the problem was solved, cycle is complete and all that remains is disseminating the solution. If not, go to step one, this time with the lessons learned from this cycle.
(if you think you've seen this before, your hobbies probably involve reading texts about quality control, project management, and other various sundry topics like product control, 'cause it's a shifted OODA loop or Deming Cycle or PDCA cycle)
((I'd tell you find better hobbies, but...)
I feel obligated to mention this again, since the book gives it its own section: learning about what does and doesn't work in real time is absolutely critical. This is distinct from randomized control trials and evaluations, in that the reform team will have neither the luxury of perfectly controlled conditions or hindsight - teams are fully expected to record what lessons they learned in the middle of taking an action and making improvements as they go. Moreover, teams are expected to not only record but implement said lessons with each step.
(The fact that it produces tons of paperwork that you can hand to superiors as a sign of progress is very much an intentional step.)
The best solution, according to Building State Capability, emerges through active processes of iteration, experimentation, and learning - because the developmental pathway for a given context is not known, a critical part of implementing reforms must be continuously experimenting with solutions and correcting assumptions. Because the reform team knows that the map is not the territory - in fact, in MfD, the map straight up doesn't exist - the reform team needs to draw the map themselves, and continuously correct their map to better correspond to the territory.
The ideal process, then, has these characteristics:
1) Multiple solution ideas are identified and put into action.
2) Experimental and iterative steps allow real and locally legitimate solutions to emerge step by step.
3) Disciplined and experiental learning along with flexibility promotes adaption to local conditions.
In general, you have four options for where you can draw ideas from in solution ideation:
1) You can draw from current practice to figure out where the problems are - and also to improve on current practice to implement it
2) You can draw from latent practice, which is the set of potential ideas and government capabilities that are possible to implement with effort.
3) You can draw from the area of positive deviance, where a successful policy is implemented but is not the norm, find which deviation made it the successful strategy, and spread that deviation more widely until it becomes the norm.
4) You can draw from established "best practices" - most reform efforts go here and look for only one solution. More of them could be used.
Indeed, it's probably best to draw from a combination of these to fit the situation.
In terms of the actual execution of the experimental iterations, it generally involves a cycle of four steps:
Step 1: Identify action steps based on problem analysis, idea identification activities, and from talking with other members of reform teams. This is the planning phase, so the action steps should be highly detailed, with precise responsibilities, and critically, set start and stop times to determine whether the project is a success. (Short timeframes are recommended in the beginning of the process, to establish both a work-focused culture going forward and to build momentum off victories)
Step 2: Execute the action steps within the timeframe.
Step 3: Evaluate the result of the action step and answering the three questions of what was learned, achieved, and what comes next.
Step 4: Check in with superiors/peers about progress, lessons learned, and assessing whether the problem was solved. If the problem was solved, cycle is complete and all that remains is disseminating the solution. If not, go to step one, this time with the lessons learned from this cycle.
(if you think you've seen this before, your hobbies probably involve reading texts about quality control, project management, and other various sundry topics like product control, 'cause it's a shifted OODA loop or Deming Cycle or PDCA cycle)
((I'd tell you find better hobbies, but...
)I feel obligated to mention this again, since the book gives it its own section: learning about what does and doesn't work in real time is absolutely critical. This is distinct from randomized control trials and evaluations, in that the reform team will have neither the luxury of perfectly controlled conditions or hindsight - teams are fully expected to record what lessons they learned in the middle of taking an action and making improvements as they go. Moreover, teams are expected to not only record but implement said lessons with each step.
(The fact that it produces tons of paperwork that you can hand to superiors as a sign of progress is very much an intentional step.)
The key insight this chapter: When coordinating reform efforts, assume that authority is multivariable and can be earned from a variety of sources within an authorization environment.
Longer explanation: Authority is a curious thing. There are formal authority networks, which are legible outside of the organization/network, and informal authority networks, which are not visible outside the organization. Furthermore, the question of who has authority over what is constantly in flux, to say nothing of the opinion of authorities themselves. On top of that, PDIA-type solutions are frequently harder to explain than "adopt this policy" solutions, making authorization in theory more difficult to obtain - you need to be able to explain that you expect to fail and that the authorizers will cover your failures, after all.
However, PDIA has a few things going for it. For one, it knows that the problem exists, as opposed to making a classic mistake where the reformists assume that one authorizer will back them to the hilt before discovering that the authorizer changed their minds. For two, the PDIA approach explicitly designs a strategy around negotiating that authorization from multiple people, to ensure multiple redundancy, instead of presenting it to one authorizer and hoping for the best.
So what is that strategy? It is a strategy that must successfully answer these three questions about the changing authorization environment:
1) What authority do we need to perform our actions?
2) Where can we find this authority?
3) How do we get the authority we need?
-3a) Once we have this authority, how do we grow it?
The first question is harder to answer than it sounds. After all, there is not just one kind of authority necessary to succeed with ventures like these: in order to implement this strategy, you need the authorization to authorize new needs as they arise, to allow the team to spend their time and energies on this effort, to be willing to expect and defend failures, and many others beside.
Therefore, reform teams should constantly check what authorizations they need, the assumptions underlying that list, and make sure to engage authorizers about their evolving needs.
Once you have that list of needs, you need to look for who has that authority. While the initial picture of authority is an idea of authority starting from on high and smoothly flowing down the org chart is common, it's also completely wrong. Actual authority tends to be all over the place and not fully encompassing.
Therefore, when seeking to navigate an authorizing environment, seek many authorizers that can fulfill some of your needs, so that all of your needs are covered by at least one authorizer. Make sure to also write down your assumptions, and to check and revise those set of assumptions as you find out more about your authorizing environment.
Once you have your list of people that you need to convince, you'll need to actually convince them. As convincing people is something I feel like we have something of a grasp on, I'll focus on the most important points that this book highlights.
1.) Treat all of your assumptions with a healthy amount of skepticism, and be prepared for lots of your assumptions to be wrong.
2.) You'll need a strategy to gain the authority for your solutions and the broader approach, and it needs to be an ongoing process of persuasion targeted towards your authorizers, with changes in the strategy implemented for each authorizer as appropriate. This is actually neglected surprisingly often in real world reform efforts.
3.) You don't need all of the authority to pull off the whole reform to begin. You just need enough to begin smaller reforms. As you go, by racking up successes those successes will reflect off of your authorizers and make your reform team more able to expand. Note that surprisingly, scale of successes doesn't matter as much as regularity - huge scale makes your authorizers look lucky, regularity makes your authorizers look like they're onto something with your team.
4.) You need to be constantly building a coalition of authorizers in order to make sure that your reform teams always have the authority they need to accomplish and scale their reforms.
Longer explanation: Authority is a curious thing. There are formal authority networks, which are legible outside of the organization/network, and informal authority networks, which are not visible outside the organization. Furthermore, the question of who has authority over what is constantly in flux, to say nothing of the opinion of authorities themselves. On top of that, PDIA-type solutions are frequently harder to explain than "adopt this policy" solutions, making authorization in theory more difficult to obtain - you need to be able to explain that you expect to fail and that the authorizers will cover your failures, after all.
However, PDIA has a few things going for it. For one, it knows that the problem exists, as opposed to making a classic mistake where the reformists assume that one authorizer will back them to the hilt before discovering that the authorizer changed their minds. For two, the PDIA approach explicitly designs a strategy around negotiating that authorization from multiple people, to ensure multiple redundancy, instead of presenting it to one authorizer and hoping for the best.
So what is that strategy? It is a strategy that must successfully answer these three questions about the changing authorization environment:
1) What authority do we need to perform our actions?
2) Where can we find this authority?
3) How do we get the authority we need?
-3a) Once we have this authority, how do we grow it?
The first question is harder to answer than it sounds. After all, there is not just one kind of authority necessary to succeed with ventures like these: in order to implement this strategy, you need the authorization to authorize new needs as they arise, to allow the team to spend their time and energies on this effort, to be willing to expect and defend failures, and many others beside.
Authorization for the time and effort of the reform team
Authorization for resources required for reforms
Authorization for decision-making rights
Authorization for entertaining new needs that occur in the process
Authorization for engaging other authorizers and giving up some degree of control
Authorization for tolerating and defending failures
etc.
Authorization for resources required for reforms
Authorization for decision-making rights
Authorization for entertaining new needs that occur in the process
Authorization for engaging other authorizers and giving up some degree of control
Authorization for tolerating and defending failures
etc.
Therefore, reform teams should constantly check what authorizations they need, the assumptions underlying that list, and make sure to engage authorizers about their evolving needs.
Once you have that list of needs, you need to look for who has that authority. While the initial picture of authority is an idea of authority starting from on high and smoothly flowing down the org chart is common, it's also completely wrong. Actual authority tends to be all over the place and not fully encompassing.
Therefore, when seeking to navigate an authorizing environment, seek many authorizers that can fulfill some of your needs, so that all of your needs are covered by at least one authorizer. Make sure to also write down your assumptions, and to check and revise those set of assumptions as you find out more about your authorizing environment.
Once you have your list of people that you need to convince, you'll need to actually convince them. As convincing people is something I feel like we have something of a grasp on, I'll focus on the most important points that this book highlights.
1.) Treat all of your assumptions with a healthy amount of skepticism, and be prepared for lots of your assumptions to be wrong.
2.) You'll need a strategy to gain the authority for your solutions and the broader approach, and it needs to be an ongoing process of persuasion targeted towards your authorizers, with changes in the strategy implemented for each authorizer as appropriate. This is actually neglected surprisingly often in real world reform efforts.
3.) You don't need all of the authority to pull off the whole reform to begin. You just need enough to begin smaller reforms. As you go, by racking up successes those successes will reflect off of your authorizers and make your reform team more able to expand. Note that surprisingly, scale of successes doesn't matter as much as regularity - huge scale makes your authorizers look lucky, regularity makes your authorizers look like they're onto something with your team.
4.) You need to be constantly building a coalition of authorizers in order to make sure that your reform teams always have the authority they need to accomplish and scale their reforms.
This final chapter focuses on expanding the scope of these reforms from a single team to across a state. There are three possibilities for scaling reforms that the book focuses on: no scaling, explosive but stagnating sustainability (an initial period of explosive spread of reforms, followed by a long period of stagnation or rollbacks), and dynamic sustainability (not only are the reforms implemented, they spread in four dimensions).
The first is undesirable because a lack of scaling results in unfixed gaps in capabiility, which remain until someone dedicates the time to reform it. The second is undesirable because the stagnation of progress is difficult to get out, and easily slides into the trap of "looking like a state".
Thus, PDIA considers the third case the most desirable case, because it is the one that results in steady long-term growth in capability across four dimensions: quantitative (more entities are affected), functional (more activities are performed), political (more support is attracted), and organizational (more resources are allocated to the project).
In order to accomplish this scaling, then, your groups need several types of people - several kinds of leaders to fulfill several needs.
The book gives us a table, and I see no reason to deviate from that.
Ideally, each of these roles should have multiple people available in order to ensure the reform truly succeeds. Furthermore, no one person should ever primarily provide more than three - that is a recipe to both strangle the reforms in their infancy and to leave no recourse if that person bites the dust.
This then leads to the question of how do you get all those people to act as leaders on the project. I hear you say "just order them to" - and while that's technically an approach, it's one of the four techniques, and the weakest one out of the batch because it fails to use the most awesome power of them all.
I speak, of course, of friendship. Otherwise known as delegation. Not godhood.That one should only take us about five to eight years.
The four techniques that the book highlights are:
1.) Leveraging approach, where a central agent initiates change by identifying projects and then building internal and external support and acceptance of said projects. The central agent (or agents) will then seek to identify people who can provide alternative ideas, and the central agent will then repackage those ideas as viable solutions.
2.) Convening approach, where different people with different strengths and resources are brought together to get bursts of output. Conveners and teams are hugely important mechanisms for this approach.
3.) Connecting approach, where distributed and distant groups can engage and help each other through the intermediary connectors.
4.) Accumulating approach, where successful ideas are disseminated throughout the larger group. This process is kinda largely random.
The first is undesirable because a lack of scaling results in unfixed gaps in capabiility, which remain until someone dedicates the time to reform it. The second is undesirable because the stagnation of progress is difficult to get out, and easily slides into the trap of "looking like a state".
Thus, PDIA considers the third case the most desirable case, because it is the one that results in steady long-term growth in capability across four dimensions: quantitative (more entities are affected), functional (more activities are performed), political (more support is attracted), and organizational (more resources are allocated to the project).
In order to accomplish this scaling, then, your groups need several types of people - several kinds of leaders to fulfill several needs.
The book gives us a table, and I see no reason to deviate from that.
| Function Set | Roles |
| Substantive contribution roles - leaders who provide ideas to make cahnge happen | 1. Constructing and communicating problems |
| SCR | 2. Generating ideas for reform |
| SCR | 3. Providing implementation review |
| Procedural contribution roles - leaders who help navigate organizational roles and systems | 4. Provide formal authority |
| PCR | 5. Motivate and inspire reform |
| PCR | 6. Empower other agents |
| PCR | 7. Provide financial support |
| Maintenance contribution roles - leaders who mobilize others into making change happen | 8. Conveners of small groups. |
| MCR | 9. Connectors to distributed agents. |
Ideally, each of these roles should have multiple people available in order to ensure the reform truly succeeds. Furthermore, no one person should ever primarily provide more than three - that is a recipe to both strangle the reforms in their infancy and to leave no recourse if that person bites the dust.
This then leads to the question of how do you get all those people to act as leaders on the project. I hear you say "just order them to" - and while that's technically an approach, it's one of the four techniques, and the weakest one out of the batch because it fails to use the most awesome power of them all.
I speak, of course, of friendship. Otherwise known as delegation. Not godhood.
The four techniques that the book highlights are:
1.) Leveraging approach, where a central agent initiates change by identifying projects and then building internal and external support and acceptance of said projects. The central agent (or agents) will then seek to identify people who can provide alternative ideas, and the central agent will then repackage those ideas as viable solutions.
2.) Convening approach, where different people with different strengths and resources are brought together to get bursts of output. Conveners and teams are hugely important mechanisms for this approach.
3.) Connecting approach, where distributed and distant groups can engage and help each other through the intermediary connectors.
4.) Accumulating approach, where successful ideas are disseminated throughout the larger group. This process is kinda largely random.
... okay so that book summarization ballooned way beyond what I was expecting it to. Nevertheless, here's the bits we could probably dump into a set of action plans centered around, I dunno, improving sanitation.
Action Plan One: Breaking Ground
- Sanitation
- Estate
- Give speeches on Uplift as a Goketsu Clan philosophy.
- Key thrust: This world may be a cold, dark, and unforgiving forest but we will give everything we have to clear a space for all of us, civilian and ninja alike to thrive.
- We are all necessary for this dream of a better world.
- The goal is to give the clan a mission statement, a reason that going above and beyond is important to internal narratives.
- Give speeches on Uplift as a Goketsu Clan philosophy.
- Team-building
- Call together a commission to study how to improve sanitation.
- Include local residents, medical experts, and us.
- Construct the problem, seeking to get each of the stakeholders (including us) to understand the answer to:
- Why does improving sanitation matter?
- For whom does improving sanitation matter to?
- Who needs to care?
- What will a place with better sanitation be like?
- What would be a measurable end-goal look (or smell) like?
- Deconstruct the problem into solvable root causes, creating a branching diagram.
- Based on which root problems are more solvable than others, create an initial, limited, and detailed plan of action.
- The plan should be limited to a week or less.
- Execute.
- Based on which root problems are more solvable than others, create an initial, limited, and detailed plan of action.
- Call together a commission to study how to improve sanitation.
- Estate
- Sanitation
- At the first iteration end time, meet with the team.
- Evaluate:
- What worked.
- What we learned re: implementation, assumptions, and the landscape for change.
- What our next steps are.
- Make sure to write down notes in the meeting to maintain institutional knowledge.
- Evaluate:
- Begin spreading the word about our efforts - and successes! - in reforming sanitation.
- Goals:
- Create network of people interested in our successes
- Create network of authorizers when we look to export the reforms
- Key constituencies:
- The Tower
- ISC
- Konoha General Hospital
- Clan members (not Clan Heads!)
- Civilian neighborhood leaders
- Goals:
- Create a new plan of action with a similarly limited timeframe, implementing recorded lessons.
- Execute.
- Continue process of iterating, learning from iterations, and spreading the word. (This plan segment can be one-lined repeatedly while background conditions cook.)
- At the first iteration end time, meet with the team.
- Sanitation
- Initial Expansion
- Take advantage of goodwill and interest generated by reporting successes of projects to new areas.
- Adopt a similar strategy:
- Assemble a team of local shareholders and experts.
- Construct and deconstruct the problem like in Groundbreaking.
- This time, however, make sure to emphasize being extra careful of overstepping authority, because momentum is absolutely critical to this project.
- Implement the short plan of action from constructing and deconstructing the problem.
- Evaluate what worked, lessons learned in this context, and what the next plan of action should be.
- Report these results both to current authorizers of the project and potential authorizers of the projects.
- Repeat this cycle of implementation, evaluation, and reporting. (Can be one-lined.)
- Initial Expansion
- Sanitation
- Continue to run sanitation improvement projects like in Breaking Ground, Spinning Up, and Scaling Up.
- Encourage members of successful reform efforts to lead their own projects (set up the same way) to reform sanitation.
- Ensure a sufficient supply of paper, ink, and literate people to take notes on all the learning being done.
- Consider expanding the project to other villages.
