I'm a believer in the strong form of Conway's law: that the structure of any system designed by an organization is isomorphic to the structure of the organization (or, more colloquially, "you ship your org"). This coupling means that questions of organizational structure, technical architecture, and "what you actually sell" benefit from high level co-design.

That said, organizational structure comes not only from intentional decisions but also from culture. So as a corollary, "you ship your culture" as well.

Finally, I'll posit that the personality quirks of the early team are perhaps underacknowledged as an ingredient in a startup's culture. Palantir is where I "grew up" professionally. In a one-on-one, Alex Karp once told me "I'm not a micromanager... obviously". To anyone who has met the man, that is self-evidently true in a way that permeates the entire company's culture. His basic disposition is reflected in a tendency to push ownership to the edges, where the key tactical decisions get made by the people on the ground. This decentralization, the implicit & explicit elevation of trust & outcomes over process, worked because of the invisible scaffolding of the organizational design.

In many ways, as we're now building Spiral, I appreciate the "generative process" of culture in a different way than I did at the time.¹ These things don't just happen by accident.

One theme I've been reflecting on a lot lately is the virtues of "cross-hatching" organizational structures, and how to use them to productively internalize tension.

One now-in-vogue example is splitting the "software engineering" function between Forward Deployed Engineers (FDEs) and Software Engineers (SWEs). FDEs work with one customer across the whole product. They deeply understand both that customer's idiosyncratic needs and how to evolve & leverage the product towards something the customer valued. Conversely, SWEs own one piece of the product across all customers. This is what I mean by cross-hatching: think of a lattice pie crust, or better yet, of the beams that hold up a building. Splitting engineering resources in orthogonal directions can easily lead to internal tensions.

Frankly, at Palantir, each engineering org sometimes thought rather not-nice things about the other (I know well, from both sides of the metaphorical aisle). For a long time, I thought of this split as a vestigial artifact of the early (air-gapped) deployments, in which customer iteration occurred almost entirely inside SCIFs.² While that might have been the origin, the friction that ensued was a feature, not a bug. It converted external customer pain into internal pain, which better aligned the entire organization around customer outcomes, even at scale. (Shyam Sankar used to call this "metabolizing pain and excreting product leverage.")

A second, more subtle example of cross-hatching was between "people leads" and "project leads." Particularly for FDEs, most of the time, those weren't the same person. Your people lead's job was to make you succeed and advocate for you, balanced against project needs. Your project lead's mandate was, in some sense, the inverse: to ensure project success, while balancing the needs of the people on the team.

What I appreciate about this in retrospect is that it bought several things at once. First, the tension itself was healthy — when one person owns both roles, they tend to prioritize more strongly in one direction or another. Having two "leads" for a person with counter-weighted mandates resulted in a productive structural pressure, with each of the two leads compensating for the other's biases.

Second, new joiners had more than one source of mentorship and connection into the more tenured cohort of the team.

Third, it allowed a partial decoupling of leadership from management. Someone could be given a chance to lead with real business impact, without needing to actually manage people. On the other hand, folks with a knack for mentoring others could do so while being individual contributors on their own teams. There were many folks who did both very effectively, but it was still valuable for people to grow along those two dimensions somewhat independently.

At Spiral, we have a single engineering org, with everyone "forward deployable" in principle. That said, we have to work to combat a natural disjointing of context between the folks contributing to (open-source) Vortex and to (proprietary) Spiral, between deep tech engineering and talking to customers. We need a structure that productively internalizes those tensions, along with mechanisms for percolating context. The goal is to build a structure where individuals can reliably know what they need to know to make the right tradeoffs, which in turn lets us push more ownership to the edges.

The symptoms show up at the seams. A feature can ship in Vortex (yay for open source!) and then lag in Spiral, because actually deploying it to customers is "someone else's job." Or a workaround gets hacked into Spiral rather than fixed for everyone in Vortex. Those drops and externalities are symptoms of a structure that hasn't internalized tension in the right spots.

I've been thinking about how to improve this; we also happen to be doing so at a time of accelerating change. AI tooling lets each individual ship more code per unit time. Shipping code used to be the bottleneck, but per Amdahl's Law, as each line of code gets "cheaper", other components become the new constraining factor: particularly consensus, design, & taste. As humans are freed from the rote work that used to dominate their time, the purely human parts grow as a portion of "a day's work."

That has some subtle implications. Remote-first companies are still possible, but might be less tenable if they add too much friction to the human part of the work. Getting on a plane to meet in person becomes more important than ever. It also probably shifts the optimal team shape. The old "two-pizza" optimal team size of 5-8 was meant to balance throughput against consensus costs. But a "pod" of 3-4 is much more efficient for decision-making and can ship much faster than a 5-8 person team could a few years ago.

If we're orienting around more but smaller pods of people, then the question becomes, how do we structurally align those pods to resemble the system we want to ship? Teams with localized consensus will make good decisions faster — if and only if they have the right information.

In effect, the demands on the invisible scaffolding around those smaller teams become greater. And this is where it comes back to cross-hatching once more: how do we align the mandates of those pods into a stable structure that internalizes tension in the right places?