Split your teams into cross-functional non-specialized units. In a good Scrum implementation, a PM should be able to handle 4-5 projects (given that your projects are relatively short in length) at a time. Just make sure your PM is staying out of the day to day workings of your teams.
I don't believe in dev leads. Let your teams self-organize. If they absolutely fail in this you can appoint a dev lead, but if you can avoid it, don't. The best scrum implementations have 1 job title for developers (and yes, that includes all the "QA" people as well).
You say that people participate in more than 1 project at a time. I would really, really encourage you to stop doing this. Assign a project to a team, and let them finish it. Assigning more than 1 project to the same team will generally result in both projects taking longer (due, mostly, too context switching). Unless there is a substantial blocking problem, try to keep it at 1 project per team at a time.
In summation: Create small multi-dimensional self-organizing stable teams with 1 project.
Edit: Why specialized teams are a bad idea
1) Specialized teams are specialized. This greatly limits the agility of your organization. If your dedicated UI team is backed up, but you've got the backend of three projects finished, what do you do?
2) Specialized teams are bad for team members. The more you pigeon hole your team members into specific, specialized roles, the more likely they are to never be able to leave that role. Low levels of specialization within a diverse team is different, as they are constantly exposed to areas outside of their specialization. But when they are locked into a team that only does one thing, they only see one thing.
3) Specialized teams are bad at design. The more focused your teams are on one aspect of your projects, the less likely they will be able to see and understand the overarching design of your project.
4) Specialized teams have to hand work off before the software is working. If you have a backend team, a UI team, and a QA team each team needs to hand off the work to another team, before the software is actually fully functional. Bugs found by the QA team need to be handed back to a different team, which then goes to another team, which then goes.... etc. This breaks the idea of delivering working software at the end of each sprint, and greatly increases project time with all the context switching required.
But don't take my word for it: google "Why multdisciplined Scrum teams"