In most project management tools, subtasks are assigned to specific people. “Design login flow” is assigned to Jane. “Write API spec” is assigned to Marco.
It works fine when everyone is in the office and nobody is overloaded. It breaks the moment anything changes.
The person-bound problem
When work is bound to people:
- Jane goes on vacation and the login flow stalls. The PM has to reassign it to Alex, who has different context and priorities.
- Marco is overloaded because three different projects all assigned “API spec” to him. Nobody noticed because each project tracked its own load.
- A new hire replaces Marco and suddenly nothing works. Every existing assignment points to a person who’s gone.
These aren’t edge cases. They’re the most common causes of project stalls.
Roles as the unit of assignment
Role-based architecture flips the model. Instead of assigning “Design login flow” to Jane, you assign it to the role Designer. The role is filled by Jane today — but if Jane is unavailable, anyone with the Designer role can pick it up.
What this enables:
- Automatic capacity balancing. Sprint planning sees “we have 3 Designer-role tasks and 1 Designer’s worth of capacity” — before anyone commits to a sprint.
- Clean handoffs. When a Designer leaves, the work they owned doesn’t die with them. It’s still attached to the role, and the next person to fill it inherits a clean state.
- Skill-based matching. A “Senior Engineer” task doesn’t accidentally get assigned to a junior engineer. The role carries the skill requirement.
The trade-off
Role-based assignment requires one thing most teams don’t have: clear role definitions. Not titles — roles. A Designer is different from a Senior Designer. A Backend Engineer is different from a Frontend Engineer. Once you define them, the tool does the matching.
That’s how Neztdo assigns work. Tasks go to roles. People fill roles. The system handles the rest.