Core Topology

The company has no departments. It has no divisions, no business units, no named teams in the sense that other organisations would recognise. What it has, instead, is a topology — a set of concentric regions distinguished only by their proximity to something called Core, which is not a department either but a kind of organisational gravity well around which everything else arranges itself in diminishing densities of privilege, information, and access to the executive calendar.

I should be more precise. The company has many things called Core. There is Core, which is the innermost function and which builds the product’s primary infrastructure. There is Core Platform, which supports Core. There is Core Platform Services, which supports Core Platform. There is Inner Core, which is not inside Core but adjacent to it in a way that implies even greater interiority, as though proximity alone were insufficient and one needed to announce it in the name. There is Core-Adjacent, a designation whose hyphen performs the work of acknowledging that one is not, in fact, Core, while insisting that the distance is negligible. And there is Near-Core, which is farther out but facing inward, and Core-Facing, which is farther still but has oriented itself toward the centre with the determination of a compass needle.

Beyond these lies a region the company refers to, when it refers to it at all, as Outer. Not Outer Core — that designation was briefly used in 2021 but retired after the teams so labelled complained that it made them sound geological. Simply Outer. The people who work in Outer do not describe themselves as working in Outer. They describe themselves as working on specific problems — payments, or localisation, or the partner API — and are baffled when someone from Core Platform Services asks them what layer they’re on, as though the organisation were a cake and everyone should know their position relative to the fondant.

The topology is not documented anywhere, which is to say it is documented everywhere — in the Slack channels people are added to, in the meetings they are and are not invited to, in the physical arrangement of the office (Core sits in the centre of the fourth floor, literally, with concentric rings of desks radiating outward, a layout chosen by a workplace experience team that has since been reorganised into something called Core Environment, which maintains the floorplan but not, notably, the carpets). It is documented in response times. An email from Core to Core Platform will be answered within the hour. An email from Outer to Core will be answered within the week, or acknowledged within the week and answered never, the acknowledgment serving as a kind of receipt confirming that the message has reached the gravity well and been absorbed.

The product mirrors the organisation with a fidelity that would delight Conway and depress everyone else. The software is structured as a series of concentric services, each wrapping the one inside it, each adding a layer of abstraction whose primary function is to restrict access to the layer beneath. The innermost service — called, inevitably, Core — handles the fundamental data model. Core Platform wraps Core and exposes a subset of its functionality through an internal API that requires an authentication token issued by Core Platform Services, which wraps Core Platform and manages the token lifecycle. To reach the actual data model from Outer, a request must pass inward through four services, each of which logs the request, evaluates the caller’s entitlements, adds latency, and occasionally returns an error whose message reads CORE_ACCESS_DENIED: insufficient proximity, a status code that someone wrote as a joke in 2020 and that the system now returns in production with no one able to locate the code that generates it.

The product’s user interface reproduces the same logic for customers, though the company would strenuously deny this. Features are arranged in tiers: Core Features, available to all users; Core+ Features, available to premium subscribers; and Deep Core Features, available only to enterprise clients who have signed a contract that includes, among its provisions, a dedicated “Core Liaison” — an employee whose job is to relay the enterprise client’s requests inward through the organisational layers and return with whatever answer survives the journey. The Core Liaison role is widely considered the most stressful position in the company, not because the work is difficult but because the Liaison must constantly translate between two frames of reference: the client’s, in which features either exist or do not, and the company’s, in which features exist at specific radii and can only be accessed by traversing the appropriate number of intermediate layers, each of which has its own roadmap, its own prioritisation process, and its own understanding of what “core” means.

Information at the company flows inward. This is the first principle of its political economy, and everything else follows from it. A decision made in Outer — say, a change to the partner API’s rate-limiting policy — must be communicated inward for approval, passing through Core-Facing, then Near-Core, then Core-Adjacent, then Core Platform Services, until it reaches someone with sufficient centrality to approve it, at which point the approval flows back outward through the same layers, acquiring at each stage a slight modification that reflects the approving layer’s priorities, so that by the time the approval returns to Outer it authorises something related to but distinct from what was originally proposed. The partner API team has learned to draft proposals that anticipate four rounds of centripetal distortion and embed their actual intent at a depth the intermediate layers are unlikely to reach.

Information also flows outward, but selectively and with diminishing resolution. Core knows everything. Core Platform knows everything except what Core is planning for next quarter. Core Platform Services knows what Core Platform is building now but not why. Core-Adjacent knows what Core Platform Services has shipped but not what it is building. Near-Core reads the release notes. Outer reads the blog post. By the time information reaches the company’s customers, it has been through so many layers of abstraction that it no longer resembles the original fact, in the same way that a press release does not resemble a board meeting, and for the same structural reasons.

This gradient produces its own economy. Proximity to information is the company’s primary currency, more valuable than title or compensation, because information determines what you can build, what you can plan for, and whether your work will be rendered obsolete by a decision made three layers inward that you will learn about when the API you depend on starts returning CORE_ACCESS_DENIED. Engineers in Outer spend considerable energy cultivating relationships with people one or two layers closer to the centre — not for career advancement, though it helps, but for epistemic survival. Knowing what Core Platform is planning is the difference between building something that will be supported next year and building something that will be deprecated by a service you have never heard of, built by people you have never met, announced in a Slack channel you do not have access to.

The company’s All Hands meetings are exercises in radiative information transfer. The CEO — who occupies a position the topology does not account for, being simultaneously inside Core and above it, like a point that is both the centre of a circle and perpendicular to its plane — presents a slide deck whose contents have been approved by Core, reviewed by Core Platform, and stripped of specifics by Core Platform Services before being rendered into language sufficiently abstract to be shared with the full company. The Outer engineers attend these meetings with the same attention a medieval peasant might bring to a royal proclamation read in the village square: listening not for what is said but for what can be inferred from the gaps, the emphases, the things that were almost said and then redirected into a phrase like “we’re excited about the direction.”

Careers at the company are understood as journeys inward. No one speaks of promotion in the usual sense. People speak of “moving closer to Core,” and the phrase carries a weight that “moving to a new team” does not, because it implies not just a change of function but a change of ontological status — a transition from the periphery, where things are contingent and precarious and subject to reorganisation, to the centre, where things are essential and permanent and subject to nothing except the decisions of people even more central than you. The most senior engineers are not those with the most experience or the broadest skill set but those who have migrated furthest inward, accumulating at each stage the institutional knowledge — the access credentials, the unwritten API contracts, the Slack channel memberships — that constitute proximity’s material form.

The reverse journey is also possible, though it is not called demotion. It is called “going to work on an Outer problem,” and it is spoken of the way one might speak of a colleague who has taken a leave of absence to find themselves, with a mixture of respect and the quiet certainty that something has gone wrong. Occasionally the company reorganises, and in the reorganisation a function that was Near-Core is reclassified as Outer, and the people in that function experience a sudden and disorienting loss of access — Slack channels disappearing, meeting invitations drying up, emails going unanswered — as the topology adjusts around them and they discover that their proximity was not a property of their work but of their classification, and that the classification has changed.

I have described the company as though its topology were pathological, and I want to resist that framing, because the topology is not an aberration. It is a discovery. Every organisation of sufficient size develops concentric structures of access and information. What is unusual about this company is not that the structures exist but that the company has made them explicit — has named them, mapped them, built its product around them, and in doing so has produced a kind of honesty that most organisations avoid. Other companies have cores. They call them something else. They call them “leadership,” or “the platform team,” or “the people who were here before the Series B.” The euphemisms change. The topology does not.

The company’s most distinctive contribution to organisational theory is the verb “to core,” which has entered its internal vocabulary as a transitive verb meaning to move a function closer to the centre, and its opposite, “to decore,” meaning to move it outward. “We’re coring the authentication service” means it is being absorbed into Core Platform. “We’re decoring the analytics pipeline” means it is being pushed to Outer, usually because no one in Core Platform wants to maintain it anymore. The verb has a passive form — “we got decored” — that is spoken with the specific resignation of people who have learned that their function’s position in the topology was always contingent, that the centre holds only what it chooses to hold, and that the rest is Outer.

The product, too, has been cored and decored over the years, features migrating inward when they become important enough to protect and outward when they become embarrassing enough to disclaim. The company’s original product — a simple scheduling tool — now lives in Outer, maintained by three engineers who joined the company when it was small enough that there was no topology at all, just people in a room building something. They remember a time before Core. They do not discuss it often. When they do, it is with the careful precision of people describing a country that no longer exists, and whose borders, they now understand, were already forming around them even then, invisible, concentric, and inevitable.