One company that gets this right is Github. I exist as my own person there. I'm affiliated with my employer as well as other organizations.

We are long past the days of "the company man," when a person's identity was solely bound to their employer. That relationship is much more fluid now.

A company that gets it wrong is Atlassian. I've left behind a trail of accounts in various Jirae and Confluences. Right now, the biggest offender in their product lineup is HipChat. My account is identified by my email address, but it's bound up with an organization. If I want to be part of my employer's HipChat as well as a client's, I have to resort to multiple accounts signed up with plus addresses. It's great that GMail supports that, but I still can't log in to more than one account at a time.

More generally, this is a failure in modeling. Somewhere along the line, somebody drew a line between `Organization` and `Person` on their model, with a one-to-many relationship. One `Organization` can have many `Person` entities, but each `Person` belongs to exactly one `Organization`.

I'll go even further. The proper way to approach this today is to relate `Organization` and `Person` by way of another entity. Reify the association! Is it employment? Put the start and end dates on the employment. Oh, and don't delete the association once it ends… that's erasing it from history.

I think the default for pretty much any relationship these days should be many-to-many. Particularly any data relationship that models a real relationship in the external world. We shouldn't let the bad old days of SQL join tables deter us from doing the right thing now.