A Lovable Problem

A Lovable Problem
A carefully balanced, decentralized sculpture. Alexander Calder, "Triple Gong" (Calder Foundation, New York)

An advice I really like goes like this: "as part of doing great work, fall in love with a problem, not a solution."

This post represents a first stab at describing the problem I'm working on.

The tradeoff

There has always been a tradeoff between convenience and responsibility.

More responsibility means being more involved in something. Being more involved in something means less time to do other things, hence it is inconvenient. This has been true in many dimensions of life. It depends a lot on the individual case, but these are true generally speaking:

  • Banks are convenient. Taking responsibility over managing your own savings is inconvenient.
  • Cars are convenient tools. You can take more responsibility over your travel habits by using a bus or trains. But this responsibility is less convenient because you need to be on time at the bus stop or at the train station.
  • A warm meal from a restaurant is highly convenient. The responsibility over your eating habits can be very time-consuming because it can comprise growing plants, feeding animals, cooking the meal yourself, and washing the dishes.

Creating value

Technologies enable us to take higher levels of responsibility given a fixed envelope of convenience. Technologies cannot do this by default. People have to work hard to make it happen, and this is what creating value means to me. Specifically, creating value through a technology means to sculpt the usability, performance, efficiency of that technology so that a person using it does not sacrifice convenience, and instead can take more responsibility over their life.

With time, humans and human organizations can take more and more responsibility because they have more and more powerful tools (i.e., technology).
With time, humans and human organizations can take more and more responsibility because they have more and more powerful tools (i.e., technology).

The fire, the wheel, airplanes, semiconductors, the internet, mobile phones are great examples of technologies invented throughout time that push the boundary of how much responsibility an individual (or an organization of individuals) can take. Technologies, however, do not cancel the tradeoff between convenience and responsibility. They just mitigate it to some degree. This is because the amount of responsibilities you can assume for yourself are infinite, so given a limited lifespan and limited attention of a human, the tradeoff will never disappear.


Like any technology, web3 enables a higher capacity to exercise control and take ownership of certain areas of life. Web3 drives down the costs (i.e., makes it more convenient) for individuals to exercise responsibility. Primarily, it enables more responsibility over the economic dimensions of life, for example transacting over borders, speculating, trading, savings.

Some organizations in this space call web3 a technology to "increase economic freedom in the world". I really like that. I see freedom and responsibility as two sides of the same coin. I prefer responsibility as a guiding concept, however, because it's something one can take, whereas freedom is usually something offered.

There is another angle I want to consider. Web3 technologies are sometimes called "tools for decentralization." This angle complements the responsibility / convenience equation. I consider decentralization the property of allowing someone to participate (i.e., take responsibility) in the operation of a service or product.

So decentralized participation is a specific instance of the principle of responsibility that a technology enables, in this case Web3 technology.

From this angle, the problem I'm working on is that of making participation convenient.

And I can refine the problem further. I can consider the kind of users I'm fixing problems for: I work at the infrastructure level. Consumer-facing products are about individuals; in contrast, infrastructure is that part of a software stack that is providing value to entire teams, units, businesses. Simply call them organizations.

So the next refinement on the problem is that of making participation convenient for organizations in their infrastructure use-cases. Using decentralized infrastructure by definition means participating as part of such infrastructure.

To avoid a confusing word salad, let's chart the different concepts I mentioned so far:

Responsibility /-> Decentralization /-> Participation /-> Using

I like that the cascade of concepts is becoming less and less abstract as we go from left to right. Very promising. Now let's tie it all together.

It is very convenient today for an organization to use centralized (third party) infrastructure providers. The tasks of the infrastructure for example could be data sharing, storage, streaming, ordering, monitoring, filtering, transportation, general operations or administration, among others.

In many situations, there is no benefit for an organization to gain responsibility over the infrastructure that handles the tasks above. Doing so might add liability or additional burden that is not contributing to their core value proposition. Even if participating in their infrastructure was equally convenient as paying a third party for that infrastructure, doing so has no benefit.

But in other situations, it is sub-optimal for an organization to fully offload their infrastructure to a third party. Or doing so puts that organization at a disadvantage with their competition. This is because responsibility over their infrastructure is part of the value proposition. In such situations, the inconvenience of decentralized infrastructure is an essential obstacle for that organization to overcome – and a good problem to solve.

To conclude, there is a large gap between the convenience of using centralized versus using decentralized infrastructure. It should be equally easy to use a centralized infrastructure as it is to use a decentralized one. At a more abstract level, I want to allow organizations to carry more responsibility – without a loss of convenience – over their own infrastructure. This is the problem I'm working on.