A long time ago, when my company was much smaller, dividing the development work over teams was quite easy:
Over the years the boundaries between the teams have become fuzzy:
All this seems to indicate that it's not a good idea anymore to have this split in teams. Maybe the 'generic' team should evolve into a 'software quality' team (defining and guarding the rules for writing good quality software), or into a 'software deployment' team (defining how software should be deployed, installed, ...).
How do you split up the work in different teams if you have different applications?
Notice that thee advantage of having the mix (allowing everybody to write everywhere in the code) is that:
But the big (and maybe only) disadvantage is that this generic code may become nobody's responsibility if there is no clear team that manages it anymore.
What is your vision?
When you have various "application" teams, you will always end up with replicated functionality - the same type of helper classes, the same problems solved several times over, often in slightly different ways.
The trouble is, nobody really wants to be on the "generic" or "framework" team, and that team has a very hard job both advertising what functionality is available from their code base, and then ensuring that the "application" people actually use it.
You need to designate some lead engineers/developers. The role of these people is to oversee the development of code amongst both the "application" and "generic" teams. They are also responsible for knowing what functionality the "generic" team has available for reuse, and then ensuring that it is actually used (and not just reinvented). Initially making one (or a few) people knowledgeable and responsible in this area is going to spread the knowledge faster than just having a team meeting and saying "hey everybody, here is a new set of APIs, start using them". One of the roles of these lead developers is to administer code reviews, and part of that code review can be to ensure that the appropriate "generic" code has been used, and if not then they can ensure that the offending piece of code is refactored.
Of course the generic team are also going to have to do a good job documenting what they have - if an application developer cannot find what they want amongst the generic code, they will go ahead and write it themself, perpetuating the cycle you currently have.