Cooperative networks and rules
What comes to mind when you think of rules? It could be a school prefect “booking” you for breaking a school rule, or a teacher explaining classroom rules at the start of a daily lesson. Rules might make us shudder.
However, when individuals come together to form something (villages, cooperatives, companies), or do something together (play a boardgame or a football) there are rules. Rules provide a valuable framework within which cooperative networks can operate. They achieve three broad functions.
A) Set out the expectations and responsibilities of members
B) Establish what good is
C) Define decision-making and dispute resolution
In the absence of rules, cooperative networks are ineffective. I’ll use two “Case Studies” (a company and a payment network) to explain why rules are needed.
Case Study 1: A company
Using the framework mentioned earlier —
A) Set out the expectations and responsibilities of members
- Job descriptions as a start: At the most basic, this is a job description for each employee. As companies get bigger, it could be definitions of roles and responsibilities between teams. For leadership, it’s figuring out where the company is growing and which teams need to be staffed, and what their responsibilities will be.
- Even small teams need to set expectations upfront: How “set in stone” expectations and responsibilities are depends on the stage of the companies. Often, larger companies have more rigid structures. But even in small and scrappy teams, team members need to know who’s doing what and responsible for what.
B) Establish what good is
- Good in the form of north star metrics and team metrics: It also involves setting north star metrics for the company, defining whats good — eg what’s a good document, what’s “good” product quality, what’s good engineering practices, observability etc. Making sure that metrics don’t contradict eg over optimizing for vanity metrics that compromise the business.
- Setting vision, cultural and communication norms: Some companies put it as “leadership or operating principles” as to how teams operate at their best (Amazon, Stripe).
C) Define decision-making and dispute resolution
- Final decision makers: Who makes decisions? I suspect this is where things are ill defined, leading to chaos and inefficiencies. But the ideal is that it is clear in a company who makes the decision. When a company is small, this could be the CEO. As it gets to 50, 100 employees, could be the CTO. It’s not always easy to figure out who makes the decision, but it will broadly fall into teams (business or product led — a related article here on finding the decision maker)
- Decision makers also arbitrate disagreements: another role for decision makers is to arbitrate when teams have differing views on what the best solution is going forward. In a best case scenario — it’s two robustly backed, well intentioned views, brought to a decision maker to own the decision, and teams disagreeing and committing to it after.
Rules — explicitly stated or informally practised or in every company, large or small
Case Study 2: A payment network
Rules for a payment network — note that these are not LAWS set by governments, but rather rules set by networks.
A) Set out the expectations and responsibilities of members
Multi party networks need multi party buy in for adoption: In a payment network, there are multiple parties participating — consumers, merchants, payment providers, banks, or the payment method (eg could be a card network, digital wallet), regulators etc. All have them have to be bought in for a network to gain traction, especially the buyer (consumer) and sellers (merchants).
Example of network responsibilities — commercial, fraud management, technical management, consumer and merchant engagement — which party does what specifically in these areas. Here are some examples of decisions that need to be made by members.
- Commercial: What should the cost of a transaction be? How are the fees split between parties? Should fees differ by industry?
- Fraud management: Who/what industries are excluded from participating from the network? Who monitor transactions? Who decides when there’s a dispute?
- Technical management: Who’s responsible for uptime, system maintenance, improving the network?
- Consumer and merchant engagement: Who should consumers reach out to if there are issues? Who answers to the regulator on consumer protections? Who works with merchants?
B) Establish what good is
Within the responsibilities stated above, rules help to define what’s good and acceptable standards within each.
- Commercial: What’s a “fair” split of the fees? Cue the interchange team at Visa/Mastercard.
- Fraud management: What a good dispute resolution process? Whats an ideal dispute rate?
- Technical management: What’s good uptime, good transaction speeds?
- Consumer and merchant engagement: What are the ideal/good practices for consumer protection? What’s a good merchant protection against nefarious consumers?
C) Define decision-making and dispute resolution
In (A) and (B), I gave examples of many questions that one has to answer to make a payment network operate successfully. Ultimately, there is also a question of who makes the decision as to what are the rules, who gets to enforce them and how?
Finally, it alarms me when people over simplify the the ease of network growth e.g., payment networks don’t grow and gain traction because a payment method becomes accepted at 10 locations! I hope that this post post demonstrated that creating a payments network is much more complex than throwing resources at the wall. More on that another time.
I end with a quote from Electronic Value Exchange pg 209
There is one important implication of this lesson that should be briefly mentioned here: payment systems are not neutral conduits through which value flows. Rather, value flows according to a mark, which represents certain rules that govern not only how the value is exchanged, but also who pays for the service, who pays for fraud, how disputes are resolved, and who gets to alter and interpret the rules. In most cases, those rules will favor one group over another, and occasionally may be designed to restrict access.
