Morning Pages: 3
Wednesday, 30 August 2017

Journal: 12

Okay, today I want to talk about my creative frustrations. What are they?

There’s the resource frustration. Capital limits the operational and engineering resources available to me. I still do a lot of work, as opposed to real work. That is, work that could be turned into sets of instructions. Processes could be built around my work, upgraded and run by humans, and ultimately, perhaps, automated entirely by software.

Work bogs me down. The more I can delegate, the more my time is free to do my real work. At least, in theory.

There’s a certain Malthusian dynamic in play with productivity. As our capacity to do work expands, that does not necessarily translate into more free time, an improved standard of living, or even more real work. Instead, we find or create more work to fill the vacuum. So nothing short of a process singularity can really free us from work.

By process singularity, I mean a standing reserve of operational resources that is cheap and powerful enough to absorb all demands. Such a singularity was not possible before, but has been made possible by coordinating operational resources with software.

If work is what I am doing with my time, it begs the question of the opposite: what should I do with my time? That is, what is my real work?

If capital is indeed the limiting factor, then my real work should be raising capital, either by increasing sales or selling equity. Increasing sales, of course, is far more desirable than selling equity. But if there is a legitimate model reason, if organic growth is too inefficient, then selling equity is the alternative. Debt financing being, as yet, unadapted to the startup market, if not unsuited.

So, if capital is indeed the limiting factor, then my real work should be raising capital. But is capital the limiting factor?

It certainly was not the limiter in the past. What was the limiter? The limiter, if anything, was architecture.

Perhaps capital is always a limiter, but if it is not the primary limiter, then it should not be the primary focus. Besides capital and architecture, there were and there are other limiters, but they are not primary.

Indeed, there is an abundance of limiters. The number of limiters, broadly defined, is equivalent to the number of problems. In our startup, there are a lot of problems. The more problems we solve, the more problems we discover — so the problematic surface area only grows. As we discover ever-more limiters, a hierarchy of factors emerges.

One reason that most startups focus on extremely discrete ‘problems’ is that there are many problems contained in every problem. As the problem is explored, it is mapped. As it is mapped, a solution emerges to match the problem. If the problem is too extensive, the solution will be too complex, and too intimidating to build.

Too intimidating does not mean impossible. Too intimidating means too many factors, because more factors suggests more chaos. Chaotic systems have so many factors, that the relationships between these factors are difficult to map. The factors are interacting in ways that are so complex, that there are no obvious essential relationships.

But order may underlie even the most chaotic systems. The order may just be invisible to the eye. If the designer can establish a hierarchy of factors, then an architecture can emerge. Architecture implies structure, and structures bring order to chaos. Structures bring order to chaos by organizing every factor. Organizing them means categorizing and sorting them taxonomically, standardizing them so that likes are likes, and all distinctions are explicit, moving them into an instantly accessible standing reserve, and networking them according to their essential relationships.

For the past two years, architecture has been my primary limiter. Until a hierarchy of factors becomes clear — until essential relationships emerge from the chaos — a solution cannot be designed. Until a solution is designed, capital spent on additional operational and engineering resources increases chaos. Increases chaos because it adds decision-making and coordination friction, adds various emotional and financial expectation pressures, and makes it harder to see and modify the model’s characteristics.

Capital makes the characteristics of a model harder to manipulate, because the most natural thing to do with capital at a startup is to spend it solving problems. But until a hierarchy of factors is clear, the hierarchy of these problems is not clear, so it is not clear where maximum leverage exists.

Throwing money at problems is a fascinating exercise. Problems absorb capital in three different ways: hiring people, hiring vendors, and buying things. These three go together. You hire people. If you make no capital available to them, then they have to apply labor to the problem. But if you make capital available to them, they will buy things to assist their labor. If you make a lot of capital available to them, they will hire vendors to solve the problem for them, and these vendors will, in turn, to buy things and do labor.

A startup must innovate. For innovation to occur, there is no way of avoiding labor. But when capital is available, labor is avoided. If you can, hire more vendors. If there are no more vendors to hire, buy more tools. If there are no more tools to buy, then labor.

But by that point, you have run out of time to labor, because most of your time is spent managing labor — the labor of your team. And most of their time is spend managing the labor of your vendors. Nobody has time to innovate.

Buying solutions is not innovating. Hiring people, hiring vendors, buying tools, buying goods and services — none of this creates original value, all of this is just buying solutions.

By a certain logic, perhaps, if you could buy all the solutions that exist for every problem that you have, then you would discover what is missing. Having thrown money at the problem, you will have revealed the true problem.

In practice, if you buy all the solutions that exist for every problem that you have, the solutions themselves become a huge distraction. In all the noise generated by a huge team and a large number of vendors using every tool they can to attack every problem they can— there is so much present, it is very hard to see what is absent. In all the visible chaos, an invisible order escapes you.

Either way, the true problem is the same. The true problem is solutions. Solutions become chaotic, solutions become a huge distraction—the hierarchy of factors is obscured.

All the kings horses and all the kings men 
could not put Humpty Dumpty back together again.

Humpty Dumpty has fragmented. To put him back together again, the essential relationships between all of his different pieces need to be re-established. Glue — that is, connecting tissue, that is coordination technology — is required. But not just glue, but an architecture. How many squares does it take to fill in a circle, or a sphere? An infinite number, arranged by a formula hidden by a calculus unknown to the king’s courtiers.

Throwing money at problems is not like throwing iron filings at a magnet. Money does not reveal the lines of force, the hierarchy of factors. The problems which absorb the most capital are not necessarily the essential problems, the highest-leverage problems, the problems that should dominate the relationship hierarchy. The problems which absorb the most capital are the ones that are most solved-for. The problems which absorb the least capital, which are the most intractable, are not necessarily the most important either.

Practically, you don’t have the luxury of testing the theory in practice; you just run out of money. But even theoretically, we see why deploying capital increases chaos.

Maximum chaos may be necessary at the beginning of the design process, when the designer needs data to work with. To the listening designer, data suggests its own organization. So the designer merely assists the data in self-organizing.

Back to my creative frustrations. I am a frustrated creative. I have, within me, the capacity to generate unlimited ideas. In the past, I have generated literally hundreds of ideas.

Not only business ideas, but ideas for creative projects, art projects, of every kind. Given time, and other resources, I could do them all.

But I stand on economic ground. I have limited time, limited money, limited operational and engineering resources.

So two years ago, I picked a single idea, a single problem to solve. Within that ‘problem’, I discovered, again, nearly infinite problems, each of which is capable of absorbing nearly infinite resources.

I raised capital to attack this problem and I spent that capital. In so doing, I tested a theory about capital not being the primary limiting factor. Without an architecture, capital increased chaos. From the chaos of that period, however, an architecture ultimately emerged. In the aftermath, those of us that remained were able to design a hierarchy of factors. That hierarchy now tells us where to apply capital and labor in a productive manner. In other words, there is a model — a business model, a service model, an operations model, and a technology model — that structures our execution in such a way that it makes the big problem tractable. There is now a machine that turns inputs into outputs.

Now that an architecture is in place, perhaps it makes sense to raise capital again. But this assumes that the architecture is correct. Is it? It assumes that the machine works. Does it?

Testing an architecture and testing a machine itself requires resources — time, money, operations, engineering — and testing can absorb as much resources as you can afford to throw at it. But the whole point of testing is to somehow limit resource risk, so as not to put a full load of strain on a structure that cannot support it. The only real test is not a test. So testing is, by definition, only limited.

So we have done limited tests. To me, as a designer, the important thing, the thing that I care about, is that the tests did not fundamentally break the architecture. Where the architecture failed, it failed tactically. Minor tweaks were made, and then solved. Minor gaps were exposed, and then filled. The more we tested, the more this iteration continued. But not fundamental restructuring was necessary.

This means to me that the structure is not ready to support a full load, but it is ready to support a gradually increasing load, so that it may have the pressure necessary to evolve efficiently.

If I am correct, and I believe myself to be, then the question returns: should I raise money again, is it time?

Well, what other uses of my time do I have?

I could invest time in organizing myself and the company further. But doing so would just increase my confidence that organization is a tractable problem.

I could invest time in learning. But the application of that learning would ultimately be design, improving the design of our architecture.

I could invest time in creativity, but again, the application of that creativity would ultimately be design: even new ideas would just challenge, and then ultimately reinforce, the existing hierarchy.

I could invest time in leadership and management: improve our plans, prioritize and sequence our objectives, attempt to improve our decision-making structures, attempt to improve our reporting systems, invest in our culture, invest in our training curriculum. But again, all of these things ultimately resolve into design. Either they break the architecture, or challenge it in such a way as to reinforce it.

So I have done so. I have done all of these things. I have invested in organization, learning, creativity, leadership and management. I have attempted to break the architecture. But all I have been able to accomplish is to challenge it in such a way as to reinforce it, and have learned where its weak points are.

Why don’t I just continue on these paths — why raise money at all? The only reason to raise money is if there is a model reason to raise money. And I’m increasingly convinced that there is. The gap is not so large that surmounting it without selling equity is impossible, but it is large enough that it would be painfully inefficient to attempt to do so.

If I do decide to raise money, then the next problem I confront is this: how to translate the internal logic of the company to an external audience. In so far as we are innovating, metrics are arbitrary and irrelevant. But for that very reason, there are no indicators of our fundamental progress that are not subjective and qualitative in nature. To invest in a design process for a system that is not yet growing reliably or scaling, the only way to assess risk is to evaluate the design process itself.

Tomorrow I would like to think about what I can do over the next month to raise capital. If indeed, raising capital is the limiting factor in my creative journey, then what is the limiting factor within the dimension of raising capital?