3 Things I Learn From Kevin Kwok's Figma Analysis (25/30)

I'm writing 30 posts in 30 days. This is number 25.

I read Kevin Kwok’s atomic concepts which I hugely enjoy. I want to cover three things I learn and enjoy the most.

Abstraction Level and Kolmogorov Complexity

I have covered abstraction levels in previous posts. It continues to be an important concept for me. What Kevin covers in his analysis on Figma, is to augment the choosing the right abstraction level with the criteria of how many relevant dimensions can the right abstraction pack in?

He applied this concept of packing dimensions into an abstraction on the case of explaining what a company does and using a Computer Science concept, the Kolmogorov Complexity to explain it as analogy:

Often the smell test of a company is how easily it can be dimensionally reduced. It’s like some variant of Kolmogorov complexity. How few core elements can maximally explain it? People fairly push back that companies are intrinsically messy and cannot be compressed in this way. It is often true that VCs and outsiders simplify their view of companies in ways that are easier to remember but useless in practice. The flaws in this dimensionality reduction aren’t reasons to ignore it—they are the reason it is important.

There are at least two further points here I want to highlight.

One, a good abstraction packs the fewest number of core dimensions. And in the case of using an abstraction to explain a company, a good abstraction helps to remember what the company does, but is not good to rely on solely for replicating the success of that company.

Two, by definition, an abstraction, good or bad, will definitely miss out certain details. Rationalists’ favorite slogan — the map is not the territory — has an echo here. It’s amazing how much insight this one paragraph packs by itself.

Clarity is the Goal for Abstractions

Three quotes in a row. And all dealing with the narrow focus on building a product, and building a company.

As product becomes the driver of most interactions with a company, external gatekeepers and proselytizers like journalists and bankers become less important. Instead, it’s the clarity of a company’s product and product—and founder—driven distribution that become most key. We’re still early on in companies internalizing this.

This clarity is not just for users. It’s even more important for employees. They are the people who build complex compounds around these atomic concepts, and their misunderstandings are the root of future deviations and issues that arise. Founders get advice to repeat what matters more regularly than they think they need to. Repetition may help employees remember what’s important, but it pales in comparison to the clarity that comes from having strong atomic concepts to begin with. Like memes, simplicity is what makes them so transmissible.

One exercise I’ve often found useful for CEOs to do with their co-founders and team is to ask an important question about the company—and see how much everyone’s answers differ. People are always shocked at how much they differ from even their co-founder. It’s natural to have differences and that doesn’t even mean either person is wrong. But these unexpected differences in how to think about the company are the underlying faultlines that make it difficult to synchronize as a company on what matters and to have a common framework by which to discuss and debate important decisions.

The mission statement, company values, written principles, and similar exercises that we see major corporations announce loudly and frequently, are a form of instructions to current and future employees. As companies get larger, it becomes harder for the founder to transmit their vision and values across time and space to the employees simply by setting a good example and let osmosis take its time.

Easy transmission, and easy recall are key. Kevin argues that while repetition helps easy transmission and recall, clarity achieves that even better. And he didn’t say this explicitly, it’s clear that he implies clarity + repetition work even better together.

When the clarity is high, it’s easy to be thoroughly embodying the clear vision or values everywhere. Be it in the way customers interact with employees, management making tough trade-offs, the product decisions such as what gets made, how they get made, how they are sold, how they behave in the hands of customers, etc, a clear vision is easily perpetuated throughout all these different interactions in the product lifecycle. Once that happens everywhere in a product lifecycle, it’s a form of repetition. Arguably, it’s a more powerful one than the naive version of repetition when management keeps repeating slogans, and the ads keep repeating catchphrases.

Perhaps, it’s an occupational hazard as a developer. The last quote about faultlines remind me of debugging the clarity of the abstraction. It can be about making the abstraction be stickier, or clearer. Or it can be about correcting the version of the abstraction in the employees’ minds. Or both depending on the situation. Which brings me to the last point about abstraction.

Needs Constant Refactoring

This time, a single quote of three paragraphs.

All of this shouldn’t be misinterpreted. Very few companies come out of the womb with crisp atomic concepts. The nature of building a company is messy and complicated. Critics are right to say that many analyses over-simplify and give post hoc explanations of how to think about companies (yours truly included).

But the process of examining that complexity and finding the most lossless ways to dimensionality reduce is not the province of armchair analysts. It’s essential for founders and companies themselves to regularly do this refactoring. Just as companies build up technical debt, so too do they build up narrative debt.

Typically fundraising is a natural fitness function for doing this refactoring. For top companies this is increasingly no longer true—but the importance of this clean up has not shrunk. Whether for the sake of their users and employees—or so they can expand into becoming more complex platforms—companies must grapple with who they truly are, before they can go after who they want to be.

In the first point, I talked about how Kevin taught me that a good abstraction tries to reduce the number of core elements needed in it. In the second point, there’s an explicit example I note about debugging the abstraction when checking against people’s version of it. In software development parlance, once you identify the gaps in your debugging, you need to refactor the code.

Which is why Kevin compares narrative debt with technical debt. Partly, the refactoring is to make sure the abstraction is working consistently correct across the different mind-spaces: employees’ heads, investors’ heads, and customers’ heads. And partly, this is to ensure that the dimensionality of the abstraction continues to be low which in itself helps with clarity and transmission of the abstraction.

Over time, it is easy to add more dimensions to an already working abstraction. Just as it’s easy to add more features to a successful piece of software. This is called software bloat. A good software company will strive to keep the software lean while increasing its range of features and their power/reach. This is a refactoring that never truly ends.

Great Example of Thinking with Abstractions

In the middle of his piece, Kevin had this awesome graph which shows two axes labelled with values. He didn’t write what those two axes mean, and I like to be shameless in suggesting what they are. Both axes are about abstractions, but the horizontal one (x-axis) is about the input users to manipulate to produce the output users care about on the vertical (y-axis). That is, pixel-vector-component-template are the abstractions users typically use to represent their inputs for their design work. Whereas, image-canvas-project-collaboration are the abstractions designers use to represent their design work outputs.

Figure 1: Graph comes from Kevin Kwok’s piece on Figma

Simultaneously, there is a kind of hierarchy in each abstraction axis. The higher abstraction value can be seen as incorporating entities from its immediate lower value and transcending the lower value as well.

An example is a collaboration between designers includes the projects they work on. Both “collaboration” and “project” are adjacent abstraction values on the output axis. Notice how a collaboration is more than just a sum of previous projects. A collaboration as an abstraction level transcends the project as an abstraction level on the output abstraction axis. I don’t want to stray too far from topic, but if you like the concept of “includes and transcends” and you like philosophy, I recommend googling about “holons”.

The principle of interleaving the abstraction ladder for inputs against outputs from the users’ point of view is another great gem in that essay of his. I have praised enough of that post. You should just go and read it instead.