In trying to organize our Azure Devops we are trying to decide if we should use multiple projects, organizations, or not. The challenge is that we're housing multiple client projects each with its own solution. The options are to make multiple orgs (one for each client) or multiple projects under our own org. It seems per this https://learn.microsoft.com/en-us/azure/devops/organizations/projects/about-projects?view=azure-devops post MSFT recommends the least number of projects possible. We have about the same 10ppl jumping between the projects but there are cases where only a subset would have access, though that's less of a concern than proper use/organization of the repos in a multi-customer setting.
I had a call with someone from Microsoft Dev Ops, did a screen share and showed them the structure. She said that the way we have it currently split out works better and is the recommended method. I feel this goes against the published guide listed above and explained that. But given our natural tendency to have it setup this way coupled with MSFT's response I think this will work for our needs. So, for most of the projects where we will maintain the code for the long term, we will put it under our org, but continue to make different projects so we can have our own build processes, teams, boards etc. This was backed up by a MSFT MVP that I know as well, so hopefully this will help someone else thinking of how to structure their Azure Devops.