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 and the existing row (with its existing id) is returned instead of a new resource. On a reused row, lead: true promotes the employee, while lead: false or omitting lead leaves their leadership as it was: an addition never demotes a current lead, so use the update endpoint to demote. A genuinely new row is created with the lead you send, or 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.