Among the Deployers

I arrived at the Tëkël settlement in the second week of the wet season, having been warned by my predecessor van Doorn that the trails would be impassable and the mosquitoes theological in their persistence. Both proved accurate. What van Doorn had not prepared me for — and what forms the substance of these notes — is that the Tëkël operate a software production system of considerable sophistication whose organisational logic is, to the Western observer accustomed to the corporate division of labour, profoundly alien. I spent nine months among them. I do not claim to have understood what I saw. I claim only to have seen it, and to report it as faithfully as the distance between their world and mine permits.

The Tëkël number approximately three hundred souls distributed across four longhouses along the upper reaches of the Kwai-Kwai, a tributary too minor to appear on most maps. Their primary subsistence activity is swidden agriculture supplemented by fishing and the gathering of forest products, but for the past eleven years — since the arrival of a Starlink terminal purchased, I was told, with the proceeds of a legal settlement against a logging company — they have also produced software, principally API middleware and data transformation services, which they sell to clients in São Paulo and Medellín through a broker known only as “O Alemão.” The revenue from this activity is not trivial. It funds the satellite uplink, a diesel generator, a small cluster of refurbished ThinkPads, and a quantity of steel tools and medical supplies. But the economic dimension, while important, is not what makes the Tëkël case ethnographically significant. What is significant is how they organise the work, because the organisational form is not borrowed from their clients, nor from any manual or methodology. It is derived, in every structural detail, from their kinship system, and their kinship system is not ours.

The Tëkël reckon descent matrilineally, which is common enough in the ethnographic literature, but they combine this with a feature that is rare and, for the software question, decisive: they do not recognise inheritable property in productive resources. A woman’s garden reverts to the longhouse on her death. A man’s fishing weir reverts to the river — literally disassembled and its stakes returned to the bank. Tools may be kept by children as personal effects, but the right to use a resource does not pass from parent to child. It passes, if it passes at all, through a system of rotating custodianship administered by the këlam, a council of women past childbearing age whose authority on matters of allocation is absolute and, in my experience, unchallengeable.

The këlam do not own anything either. They assign. The verb in Tëkël is vëtash, which van Doorn translated as “to place a hand upon temporarily,” and the temporariness is not a softening euphemism. Custodianship of a garden plot is granted for one planting cycle. Custodianship of a fishing weir is granted until the next full moon after the catch drops below a threshold determined, opaquely, by the këlam. There is no appeal, no negotiation, and — this is the point — no expectation that the custodian will still be the custodian next season.

The consequences for software production are immediate and total.

There are no teams, in the Western sense. There is no service ownership. The concept, when I explained it through my interpreter Kalë — a young man of sharp intelligence who had spent two years in Manaus and understood Portuguese — produced first confusion and then hilarity. Kalë translated the idea of permanent team ownership of a codebase back to the longhouse as something like “a man who sleeps in his fishing weir and will not let others fish,” and the laughter went on for some time. The eldest of the këlam, a woman called Tëkash-u, said something that Kalë rendered as: “Does the river belong to the weir, or the weir to the river?” I recorded this but confess I did not at the time appreciate its architectural implications.

What the Tëkël do instead is this. When a piece of software must be written — a new API endpoint, a data transformation pipeline, a fix to an existing service — the këlam assign a vëtash-group of between two and five people to the task. The composition of this group is not random, but neither does it follow any principle I could discern from technical skill alone. Kalë told me that the këlam consider “who has not worked with whom recently,” “who is in a quarrel and must be made to sit together,” and “who has been sitting too long and needs to think about something new.” The vëtash-group works on the task until it is complete, and then dissolves. Its members return to the general pool of workers and await reassignment. They do not retain any privileged relationship to the code they have written.

I must be precise about this because it is the point on which the entire system turns. In the Western software organisation, the team that writes a service operates that service thereafter. On-call rotation, bug fixes, feature additions — all flow back to the originating team because the originating team “owns” the service. Among the Tëkël, the vëtash-group that writes a service has no more relationship to it than a potter has to a pot after it has been fired and placed in the longhouse stores. If the service breaks at three in the morning, the këlam assign whoever is available. If a feature must be added, a new vëtash-group is formed, and it will likely contain none of the original authors.

The reader trained in software engineering will immediately object: but what about context? What about the accumulated knowledge of the system’s quirks, its undocumented behaviours, its configuration secrets? How can a fresh group maintain code they did not write?

The Tëkël have an answer to this, and it is the second structurally interesting feature of their system. They do not maintain code. They rewrite it.

The practice is called ong-vëtash, which Kalë translated with some difficulty as “to give the garden back to the forest.” When a service becomes difficult to modify — when a new vëtash-group sits down to work on it and finds the code opaque — they do not attempt to acquire the “deep context” that the Western engineer hoards as a vassal hoards knowledge of his fief. They rewrite the service from its API contract inward. The API contract is sacred; the implementation is disposable. I watched this happen three times during my stay. In one case, an entire data ingestion pipeline was rewritten over four days by three people who had never seen the previous implementation. They worked from the API specification and a set of tests that are maintained — this is the one persistent artefact — in a communal repository that the këlam call the tëkël-ab, or “memory of the longhouse.”

The tëkël-ab is maintained by no one and everyone. Any member of a vëtash-group may add tests to it. No one may remove tests from it without the këlam’s approval, which is never granted. The tëkël-ab only grows. It is, in kinship terms, the one form of collective property the Tëkël recognise: not owned by any individual, not assignable by the këlam, not revertible to any commons, but held in perpetuity by the longhouse itself as a corporate entity. When I asked Tëkash-u why the tests could never be deleted, she said, through Kalë: “You can forget what you have learned, but you should not forget what you have suffered.” I believe she was referring to production incidents.

The practice of ong-vëtash has a consequence that will strike the Western engineer as either liberating or horrifying: there is no technical debt. There cannot be technical debt, because technical debt is a property of code that persists long enough to accumulate it, and Tëkël code does not persist. A service is written, runs, and is eventually rewritten, and in the rewriting, whatever compromises the previous vëtash-group made are simply not carried forward. The forest reclaims the garden. A new garden is planted. The soil is fresh.

I asked Kalë whether the Tëkël experienced the phenomenon I described to him as “a system that everyone is afraid to touch.” He did not understand the question. I rephrased it several times. Finally he said: “Why would you be afraid? You can always plant again.”

The kinship system impinges on software production in one further way that deserves mention, because it illuminates by contrast a feature of Western organisations so pervasive as to be invisible. The Tëkël do not have careers in software. There is no seniority ladder. There is no distinction between “junior” and “senior” engineers, because there is no continuous accumulation of status through prolonged custodianship of increasingly important systems. A person who has been writing software for ten years and a person who began last month are equally eligible for assignment to any vëtash-group. The këlam may factor experience into their assignments — I believe they do — but the assignment itself confers no status, and its completion confers no claim on future assignments.

This is directly analogous to the garden system. A woman who has farmed the best plot on the south-facing slope for three seasons has no claim to it in the fourth season. She has demonstrated her skill, and the këlam will note this, but the plot is not hers. She cannot leverage her history with it into a permanent allocation. She cannot argue that she has “deep context” on the soil conditions. She cannot warn that a transition to a new custodian would “introduce unacceptable risk.” The këlam would find such arguments incomprehensible — or, more precisely, they would find them antisocial, because the Tëkël understanding is that prolonged custodianship of any resource is not a sign of competence but a sign of hoarding, and hoarding is the most serious accusation that can be levelled at a member of the longhouse, more serious even than laziness or cowardice, because the hoarder breaks the cycle of vëtash on which the entire social order depends.

I once observed a young man named Dëkui-n who had written an exceptionally elegant piece of code — a parser for a complex CSV dialect that one of the São Paulo clients required. His vëtash-group completed the work in two days. The following week, the këlam assigned a different group to extend the same service, and the new group, finding the parser difficult to extend in the direction they needed, rewrote it entirely. I expected Dëkui-n to be upset. He was not. When I asked him about it, he seemed puzzled by my concern. Kalë translated his reply as: “The fish I caught yesterday fed people yesterday. Today there are new fish.”

I do not wish to romanticise the Tëkël system, and the conventions of this journal require me to note its deficiencies as honestly as its virtues. The practice of ong-vëtash is wasteful. Code that is perfectly functional is rewritten because the people assigned to modify it find it unfamiliar, and their first instinct — trained by a lifetime in a culture that does not accumulate — is to start fresh rather than to learn what is already there. The absence of persistent teams means that certain kinds of deep architectural knowledge are difficult to develop, because no one stays with a problem long enough to discover its subtler dimensions. The këlam’s assignment process is opaque and, I suspect, not immune to favouritism, though I could not confirm this. And the system works at the scale of three hundred people producing middleware. Whether it could function at the scale of a Western technology company is a question I am not equipped to answer and do not wish to speculate upon.

But I will note this. During my nine months among the Tëkël, I never once observed the phenomenon that dominates life in the Western software organisation: the political struggle over ownership of a system. I never saw two groups argue over which of them was responsible for a service. I never saw a group refuse to fix a bug on the grounds that the offending code belonged to someone else. I never saw a person’s status or job security depend on their continued custodianship of a system that only they understood. I never saw a system that no one was willing to touch. And I never saw a piece of software defended not because it was good but because dismantling it would dismantle the organisational structure that had formed around it.

Whether these absences are worth the cost of the inefficiencies I have described is a question that each reader must answer according to their own situation. I will only say that when I returned to London and sat in my first architecture review meeting — in which three teams spent ninety minutes debating which of them owned a shared database table — I thought of Tëkash-u, and her question about the river and the weir, and I could not entirely suppress the urge to laugh.

Acknowledgments. I am grateful to the Tëkël community for their hospitality, and in particular to Kalë for his patience as an interpreter. I thank van Doorn for his field notes and his supply of antimalarials. Fieldwork was supported by a grant from the Leverhulme Trust. O Alemão declined to be interviewed.*