In the previous part I’ve explored briefly why censorship resistance in organizations is important. Here I’ll walk through fundamental internal problems with centralized organizations and show how organizations learned to grow in highly uncertain environment.
Wikipedia defines organization as following
An organization or organisation is an entity comprising multiple people, such as an institution or an association, that has a collective goal and is linked to an external environment
https://en.wikipedia.org/wiki/Organization
Here I will use organization to reference a set of people and relations between then created or grown up around a particular goal in a real world.
People create organizations for thousands of years. More, the whole history of our civilization is a history of organizations.
Due to limitations of communication technologies most of organisations were centralized: they had a person or a cohort of persons collecting information from bottom-up and feeding instructions back to the bottom. This type of organization was more likely to survive for the history, because it allowed different people to specialize: those who were at the top of the information pyramid could specialize in analysis and making decisions, those, at the bottom, in collecting basic info and executing orders, and those between them — in transmitting information and orders, summarizing info, and making sure that the instructions were executed properly.
Organizations of other forms either failed the competition, or morphed into one or several centralized ones.
The reasons of such evolution were described in famous “The Nature of the Firm” by Ronald Coase and culminated in the form of classic US Corporation, like GM under Alfred Sloan management, as described by Peter Druker in “Concept of the Corporation”.
Centralized organizations are great.
Until they aren’t.
Centralized orgs prone to problems:
In other words, it might be relatively easy to create a successful corporation. Yet it’s close to impossible to keep it successful beyond a certain size and this becomes more and more obvious as the pace of change grows.
Those roadblocks could be summarized in two problems: The Principal-Agent problem and Hayek’s Local Knowledge problem:
The Principal Agent Problem occurs when one person (the agent) is allowed to make decisions on behalf of another person (the principal). In this situation, there are issues of moral hazard and conflicts of interest. See more at https://www.intelligenteconomist.com/principal-agent-problem/
Hayek’s Local Knowledge problem is related to the fact, that in the real world, information is dispersed, incomplete, and frequently contradictory. (https://blog.elidourado.com/the-use-of-knowledge-in-society-cd908cbfef8a)
On the other hand, Naval Ravikant tweeted recently
Scaling a company via code and contracts instead of via people mitigates the Principal-Agent problem.
Scaling via community-generated code and content mitigates Hayek’s Local Knowledge problem.
Let’s use this tweet as a hint. But first, some background.
Since late 50s more and more innovation happens outside of classic corporations, but in startups. Now this practice is so widely accepted, so people “by default” consider that innovation happens just in startups.
What’s a startup anyway?
A startup is an organization formed to search for a repeatable and scalable business model.
Steve Blank https://steveblank.com/2010/01/25/whats-a-startup-first-principles/
In other words, startups are extremely unstable because of non-proved business model. This makes them more connected to the reality and less susceptible to the plagues of BigCorp.
But here’s another issue: successful startup, by its own nature, has to grow to an established corporation, triggering two problems, mentioned above. And unsuccessful startups die.
And frequently they die because they develop the solution for the problem that nobody has.
Meet Lean Startup:
Lean startup is a methodology for developing businesses and products, which aims to shorten product development cycles by adopting a combination of business-hypothesis-driven experimentation, iterative product releases, and validated learning. The central hypothesis of the lean startup methodology is that if startup companies invest their time into iteratively building products or services to meet the needs of early customers, they can reduce the market risks and sidestep the need for large amounts of initial project funding and expensive product launches and failures.
Wikipedia https://en.wikipedia.org/wiki/Lean_startup
In particular, concepts of Actionable metrics, Innovation Accounting, and Build-Measure-Learn cycle allow to focus organization of what’s actually important, instead of internal politics around vanity metrics.
Yet, it’s still hard to create a culture of experimentation and continuous learning beyond certain size. This is because of the accepted style of running business: org leaders set goals, management splits them into specifications or requirements documents, assign budgets and deadlines, and push them to implementation teams. Little left for an information feedback loop, and even when it’s created, it requires energy to keep it alive and objective.
But when goals are changed from objectives, specifying a solution required, to Business Problem Statements, asking a question to be answered, things may change.
A business problem statement is made up of three parts:
- The original goals for the product/service/system.
- The problem the business has identified that requires some attention and the impact that this issue is having on the business, along with any data, insight, and other corroboration.
- A specific request for improvement stated as a change in customer behavior (not as a set of features)
https://medium.com/@leanstartup/framing-the-work-to-encourage-experimentation-2b9c38cf23ec
The lengthy quote below describes why BPS are important:
Three components of the problem statement articulated in the template — the original intent for the product, the problem we’ve observed, and how we’ll measure success. Note that there is no room in the template for specific feature requests and this is intentional. The Business Problem Statement is a question, not an answer. A problem, not a solution. Teams should create hypotheses about what the best solutions might be for this problem and then use build/measure/learn loops to discover which ideas work and which ones don’t.
When work is framed this way, teams don’t have a set of features to build and ship. In fact, they have no idea which combination of product, service, features, design, copy, and code will achieve the stated outcomes. They have to discover these answers. The only way to do that is to experiment. It’s incredibly risky for a team to simply choose a direction and spend the entirety of their project’s timeline in that one direction without validating that this is the direction that will yield the desired change in customer behavior.
Teams brainstorm their best ideas and begin to run experiments, build MVPs, and collect qualitative and quantitative feedback on these early ideas. Over time, the better ideas emerge and the team can continue to build/measure/learn their way to a great solution. Since teams are being asked to solve problems rather than ship features, they are not under pressure to hit specific deadlines. Of course, we encourage teams to discover solutions by shipping code, and in doing so, hope that it won’t be long before great, evidence-driven solutions make it into customers’ hands.
Finally, note that the Build-Measure-Learn loop in the process of answering a BPS is similar to a “master loop” in a startup itself. This is great, because it allows to treat team, working on the BPS, as a lean startup organization itself.
Also it removes the requirement to have the entire startup team collocated. Or even having a single team working on any particular BPS: it’s common to accept that there should be several startups approaching any particular market, why not treat BPS as a market and have several teams to compete for better solution?
Of course, that idea requires to find a way to properly compensate teams, both compensating for unsuccessful effort and rewarding the winners.
Gladly, market mechanics can help with this, as I will show in the following chapters. In usual corporate setup it’s either difficult or suboptimal to run such markets, but here come cryptocurrencies.
