Cooperative vs Employment: A Conversation the Community Was Ready to Have

How the Conversation Started

This article isn't a manifesto or a pitch. It's where we landed in a conversation with RAD-KOP — a Russian IT community that's spent several years trying to build cooperatives instead of classic employment. I come in not as a preacher but as the technical advisor to a federated-cooperation project: I help with architecture and process, but most of what follows isn't my conclusions — it's the shared experience of people who've already taken the knocks.

It started with a simple itch: to make something together. Not to "hire" and not to "get hired," but to gather as a team of equals and own the result jointly. Sounds naive — until you start unpacking what exactly people dislike about employment, and what a cooperative actually changes and what it doesn't.

One example from our discussions sets the tone nicely. A team builds a realtime platform that generates a tangible share of the division's profit, and at year-end they get a bonus — respectable by corporate standards, but a small fraction of the value created. The corporate logic here is clear: the business carries the risk, pays back infrastructure, carries unprofitable lines — the multipliers exist, and they're honest. But once the multiplier effect gets serious, another fact surfaces: teams could earn more than the current market average, and global practice bears this out. Options, profit-sharing, bonuses tied to company profit without a hard ceiling — companies around the world do this precisely because it retains the people who create the most value. Fair? By corporate standards — more than fair. By the standard of value created — the gap is visible.

On one call, a RAD-KOP member put it so well there was nothing to add: "Salary is payment for risk. A share is payment for value." The corporation pays you because you agreed to stability. But if you're willing to take on part of the risk — why not get part of the upside? That question is what the whole discussion unwinds from.

What's Wrong With Employment (No Drama)

The community agrees the problem isn't evil bosses. The problem is the incentive structure.

An engineer builds a system that processes transactions in real time, and its business value is measured in serious sums every month. The engineer's reward is a fixed salary. The corporation takes on the risk: investment, infrastructure, customer base. In return it takes the upside. The employee gets stability in exchange for giving up a share of the result. This isn't injustice — it's structure. But it's worth asking yourself: are you okay with that trade?

The second thing that comes up in almost every conversation is the lack of a voice. You can be the best tech lead in the company. But if a new director decides to "optimize" — your opinion won't count. Not because they don't respect you. Because that's how the structure is wired. Managers make the decisions, and the engineer has no systemic mechanism of influence — only personal relationships and political instinct.

Third: stability is a probability. The mass layoffs of recent years showed that a "stable job" is a statistic that works in your favor — until it doesn't. A shift in strategy, a new CEO, "headcount optimization" — and the statistics change. And you don't control that.

The Cooperative: Mechanics Without Slogans

A cooperative is an organization where workers are co-owners. Not formally, as in stock option programs, but genuinely: they vote, they see the finances, they distribute the profit. The model has existed for over a hundred years — Mondragon in Spain with 65,000+ worker-owners, ESOP companies in the US, IT cooperatives like Igalia in Spain. Here in Russia, RAD-KOP speaks the same language. This isn't a utopia — it's a time-tested alternative.

Principle	What it means
Co-ownership	Every member owns a share of the results. Not an option with a 4-year cliff, but a real share
Transparency	All finances are open. Everyone knows how much the cooperative earned
Democracy	Key decisions are made by vote. One member, one vote
Distribution by contribution	Reward is tied to contribution, not to title
Mutual accountability	No "I just work here"

An Honest Comparison

No model wins on every criterion — that's the first thing the community agrees on, so nobody sells anybody a fairy tale.

Criterion	Corporate employment	Cooperative
Income	Fixed, predictable	Variable, tied to results
Upside	Minimal (bonuses, rarely options)	Direct share of the profit
Stability	High (while the market is good)	Medium (depends on the team)
Decision-making	Top-down	Democratic
Career growth	Vertical (management)	Horizontal (expertise + contribution)
Bureaucracy	High	Low-to-medium
Entry	Simple (you got the job)	Harder (values must align)
Exit	Simple (you quit)	Regulated (share buyout)
Scaling	Well-established	Harder, requires culture

A cooperative isn't "better." It's about a different set of trade-offs. And the whole value of the conversation with RAD-KOP is that there, those trade-offs get named out loud instead of swept under the rug.

Why This Can Work Specifically in IT

A separate topic in our discussions is why the cooperative model fits IT especially well. The arguments are simple: low capital costs (a laptop and internet), measurable contribution (code, design, analytics — all of it can be assessed), remote work with no office to anchor to, and high margins on intellectual labor. Where for a factory a cooperative means machines and workshops, for an IT team it's a chat, a repository, and an agreement on how to split the result.

That's exactly why the "itch to make something together" stops being a slogan in IT and turns into a working task: set up the processes so that co-ownership doesn't kill your speed.

Three Distribution Models Already Tested Firsthand

The liveliest part of the conversations is how to split the profit. Inside RAD-KOP and the teams close to it, this isn't theory: people have tried different schemes one after another and can tell you what fell apart and what held up.

The first — split evenly. You earned it, you divide it equally among everyone. Beautiful, communist-style, and completely unworkable. Within a couple of months it becomes clear: one person is carrying the project on their back, another drops in for a couple of hours in the evenings, and they get paid the same. The first starts quietly boiling over. The second sincerely thinks it's all fair — after all, they're participating too.

The second — a percentage of the revenue from the specific project you're working on. Logical, but it creates skews: one person lands a fat contract, another lands a strategically important but low-margin one. People start picking projects not by interest or usefulness to the team, but by margin. Internal competition — exactly the thing they were running away from.

The third — and the one that works — is combined: a base part from overall profit (which doubles as a safety cushion), plus a contribution coefficient that the members themselves revisit each quarter. Not perfect, but it's the model where people stop counting each other's hours and start thinking about the shared result.

There's a hard-won conclusion about decisions too: voting on every question kills your speed. One team once spent two hours voting on which task tracker to use — two hours of life nobody's getting back. The common prescription is to delegate operations to working groups and only vote on strategy. But how to fairly assess contribution is the hardest question, and it's still being tuned everywhere this model gets tried.

There are always two sides to these conversations. On one — the moments when you want to drop everything: when two members can't agree on priorities and, instead of a manager's decision, an endless discussion begins; when variable income in a bad month hits a person with a mortgage; when a candidate who's perfect on skills doesn't pass on values — and the team loses a useful specialist for the sake of a culture that's still in its infancy. On the other — the things that are simply impossible in a corporation: when the team itself decides to rework the architecture because everyone feels responsible for quality; when financial transparency kills the politics — there's nothing to carve up behind closed doors when everything is out in the open.

The Downsides (No Rose-Tinted Glasses)

The community especially values the habit of saying the weak spots out loud. Here are the ones that come up most often.

Democracy is slower than autocracy. That's a fact. When several people vote on every question, speed suffers. It's cured by delegation, but the balance between democracy and efficiency is constant work.

Free rider. In a cooperative it's harder to part ways with an underperforming member — they're a co-owner. You need clear contribution metrics and rotation mechanisms. They get written into the charter, but almost nobody has tried applying them in practice yet — theory and practice can diverge here. The specific situation that pushes teams toward formalizing it sounds roughly like this: a member spends a month on a task they themselves estimated at "a week, max." They're not sabotaging — they just switch over to their own stuff, because there's no external control and everyone's internal control is different. In a corporation the team lead would notice at the daily. In an artel, where everyone is an equal partner, saying "you're slacking" isn't a management decision — it's a conflict between co-owners. And resolving it is many times harder.

Uneven income. There's no fixed salary — there's a share of the profit. In a bad month you earn less. For someone with financial obligations, that's a serious factor. A typical story: a three-week gap opens up between two contracts. For someone with a cushion — unpleasant but tolerable. For a member with a mortgage and a kid — real stress, and the conversation in the team afterward gets heavy. Hence the common conclusion: you need a reserve fund — a percentage of every contract is set aside to smooth over dips like these. A corporation solves this for you — a steady paycheck on the 25th. In an artel you solve it yourself, and that takes financial discipline that not everyone has.

Cultural barrier. In Russia, the word "cooperative" still drags the 1990s along with it. Explaining that this is an international model with a century of history, and not the infamous "Ozero cooperative," is tiring but necessary. At one meeting a potential client asked, in complete seriousness: "So a cooperative — is that like a commune? Do you all live together in one house?" In people's heads a cooperative is either a Soviet-era shop or hippies on a farm. That it could be a group of professionals with transparent profit distribution and democratic governance simply doesn't fit their worldview. Every such conversation is a little bit of outreach. It's exhausting, but without it the model won't scale beyond a narrow circle of like-minded people.

Scaling is an open question. Mondragon proved that a cooperative can grow to tens of thousands of people. But Mondragon was built over decades. Russian teams like RAD-KOP are very young. And it's still unclear how to preserve the culture of co-ownership when the number of members goes from five to twenty-five. When not everyone knows each other personally. When a strategy vote turns into a procedure rather than a conversation around a table.

Who This Is For

Which brings us to the shared conclusion we arrive at: the choice isn't about which model is "correct," but about which one is closer to you.

A cooperative suits you if you're tired of bureaucracy but don't want to freelance alone. If you're ready to be accountable for the shared result. If you value transparency more than a "steady paycheck." If you can work as an equal.

Employment is better if you value predictability above all. If you don't want to think about the business side. If you're comfortable in a hierarchy.

Both options are fine. There's no "right" choice.

But here's what people increasingly notice in these conversations: strong engineers are more and more often asking, "why don't I own the result of my own labor?" It used to sound philosophical. Now that one person with AI tools can replace an entire department, it's becoming economic. And the answer to it will determine how the IT industry is structured ten years from now. Which is why you want to be among those shaping that answer, rather than among those who just get handed it.

That, really, is what the itch that started the conversation with RAD-KOP comes down to: not to "get hired" and not to "hire," but to make something together — and figure out how to set it up fairly. If the topic resonates — here's how Digital Artel works, the federated-cooperation project I help as technical advisor, and a full breakdown of the co-ownership thesis in the manifesto.

---

Based on conversations with the RAD-KOP community and the Digital Artel manifesto.

Yours, DPUPP