Assign an employee to a team, meaning create a membership. For companies with nested teams, two extra semantics apply. Propagation: memberships are inherited upwards, so after adding an employee to a sub-team, inherited membership rows for its ancestor teams are materialized asynchronously — rows you did not create will appear in later reads. Reuse: if the employee already has a membership row on that team (typically an inherited one), no new row is created — the employee becomes a direct member of the team, the lead flag is applied when you send one, and the existing row (with its existing id) is returned instead of a new resource. Omitting lead leaves a reused row's leadership as it was, so replaying an addition never demotes a current lead; a genuinely new row is created without it. The response is still 201 when an existing row is reused, so compare the returned id against what you already hold to tell the two cases apart.