Liquid roles: why we rotate responsibilities

In a big company, fixed roles are an advantage: clarity, specialization, clear responsibilities. In a 3-4 person community project, those same fixed roles are bottleneck number one. People end up waiting on each other: waiting for the designer to deliver, for the dev to review, for someone to write copy. Liquid roles are the answer.

What "liquid roles" means

It doesn't mean everyone does everything. It means each person has a primary role and a secondary one, and secondary roles rotate monthly or per sprint. Example:

• Ana — Product (primary) / Writing (secondary)
• Luis — Engineering (primary) / Distribution (secondary)
• Marta — Design (primary) / Product (secondary)

The next month, secondaries rotate: Ana moves to Distribution, Luis to Writing, Marta to Engineering (basic stuff, obviously, not architecture refactors).

Why it works

1. Eliminates bottlenecks. If the designer gets stuck, another member's secondary role unblocks. No one is held hostage by one person's capacity.
2. Distributes knowledge. By month three, everyone understands how each part of the product works. Reduces "irreplaceable person" risk.
3. Builds internal empathy. The person writing copy this week stops saying "copy is easy" when they return to their primary role.
4. Makes the project resilient. If someone leaves, the project doesn't split in half — there's already a second person who partially knows that area.

What liquid roles are NOT

• Not pure democracy. Someone leads every decision. The "primary" role owns their area; secondary supports.
• Not total multi-skilling. Not everyone does everything. Asymmetry by design.
• Not mechanical monthly rotation. Rotation follows project needs, not a strict calendar.

How to start

1. Each person declares their primary role in week 1 of the project.
2. At the end of month one, each person declares which area they want as secondary. Not imposed — chosen.
3. In weekly meetings, the secondary role gets explicit airtime: what did you learn this week, what did you support.
4. Rotation happens when it makes sense, not as ritual. If someone found a combo that works, they stay longer.

The real risk

The biggest risk is making someone's primary role invisible. If Luis does engineering and has distribution as secondary, he may end up always doing both because it's faster that way. Watch that the secondary doesn't become "whatever no one else wants to do."

When not to use liquid roles

• In teams of more than 6-7 people: you need more specialization, not less.
• In projects with highly specialized technical execution (serious ML, cryptography, hardware): the primary role is already complex enough.
• When the team just met: first test trust with fixed roles, then experiment with liquid ones.

For most projects born in the community, liquid roles are what makes progress depend on the team, not on one person.