Tsing on scalability:

Progress itself has often been defined by its ability to make projects expand without changing their framing assumptions. This quality is “scalability.” The term is a bit confusing, because it could be interpreted to mean “able to be discussed in terms of scale.” Both scalable and nonscalable projects, however, can be discussed in relation to scale. When Ferdand Braudel explained history’s “long durée” or Niels Bohr showed us the quantum atom, these were not projects of scalability, although they each revolutionized thinking about scale. Scalability, in contrast, is the ability of a project to change scales smoothly without any change in project frames. A scalable business, for example, does not change its organization as it expands. This is possible only if business relations are not transformative, changing the business as new relations are added. Similarly, a scalable research project admits only data that already fit the research frame. Scalability requires that project elements be oblivious to indeterminacies of encounter; that’s how they allow smooth expansion. Thus, too, scalability banishes meaningful diversity, that is, diversity that might change things.

Tsing, The Mushroom at the End of the World, page 38

(Emphasis mine.) I think about scalability and diversity in my work-life quite a bit: the tech and media industries have explicitly acknowledged the need for diversity (while so far only making token steps towards achieving it). But there’s often a notion that diversifying an organization will not require changes to that organization’s culture: the concept of “culture fit” presumes someone can neatly fit into the existing culture, as opposed to challenging it or expanding it—or even razing it. That tech (and, increasingly, media—and oh, that boundary is nothing if not fluid) also speaks of scalability in religious terms puts Tsing’s contention here in an even more interesting light. Scalability is expressed not only in the external artifacts of an organization—the software, the servers, the business model—but also the people who work for it and the people who interact with it as customers, clients, and, increasingly, inconstant laborers. That latter category—the Uber drivers, TaskRabbits, and Postmates—seems especially relevant to notions of scalability. Uber can scale, but the single parent who works as a driver and can’t predict what they’ll make from week to week cannot.

Tsing continues:

Scalability is not an ordinary feature of nature. Making projects scalable takes a lot of work. Even after that work, there will still be interactions between scalable and nonscalable project elements. Yet, despite the contributions of thinkers like Braudel and Bohr, the connection between scaling up and the advancement of humanity has been so strong that scalable elements receive the lion’s share of attention. The nonscalable becomes an impediment. It’s time to turn attention to the nonscalable, not only as objects for description but also as incitements to theory.

A theory of nonscalability might begin in the work it takes to create scalability—and the messes it makes. One vantage point might be that early and influential icon for this work: the European colonial plantation. In their sixteenth- and seventeenth-century sugarcane plantations in Brazil, for example, Portuguese planters stumbled on a formula for smooth expansion. They crafted self-contained, interchangeable project elements, as follows: exterminate local people and plants; prepare now-empty, unclaimed land; and bring in exotic and isolated labor and crops for production. This landscape model of scalability became an inspiration for later industrialization and modernization.

Tsing, The Mushroom at the End of the World, page 38

There’s the savage bit again: scalability often swamps all other considerations. If you define scalability as the solitary success metric, then you are bound to ignore—or violently overcome—all other measures. So another place to begin to build a theory of nonscalability might be to ask by what other metrics we should measure progress. Scalability cannot be our only aim.