Please suggest how to divide teams

You make no mention of Scrum or Products.  Do you have identified Products?  Is there a Product Owner that can maintain a backlog of items that represent changes that need to be made for those Products? Have you asked the Developers if they have a better solution to the issues you are seeing? 

If you want my Scrum specific answer, here it is. 

Scrum is focused on having a team of individuals that fulfill specific responsibilities to create, maintain and manage a specific Product.  The team is made up of cross functional members that have all the skills necessary to accomplish the mission of achieving the Product Goal. In your current situation, you have multiple teams focused on a small portion of a product that will, as you have experienced, dependencies.  If one team had all the skills needed to make changes to code base to introduce new functionality, it would be easier to mitigate those dependencies to allow for faster delivery.  But it would require your organization to change the way that it thinks about software delivery. 

My not Scrum specific answer is pretty much the same so I won't go to the effort of typing it out. 

Ideally, any decisions on how to organize the people and teams would come from the teams themselves.

That said, the teams may want to investigate LeSS and Nexus for scaling Scrum and Team Topologies for structuring the teams around the value streams and products. Assuming that the teams are already practicing Scrum, LeSS and Nexus are two good structures for coodinating between three or more Scrum Teams working on a single product, while Team Topologies can give you some structures for thinking about how to think about the work taken on by each team within the context of the product. It could also be interesting for the teams to look at FAST Agile as an alternative approach for self-organizing.

If the teams have recognized that there is a problem and are struggling to think through ideas, these are a few things to bring to the team for their consideration. However, if the teams haven't yet realized the concerns, starting with the perceived problems would be a good start and then seeing if the teams have any thoughts for how to solve them, perhaps bringing in some of these solutions to have more concrete conversations.

Could you please help with the decision of how to split/divide teams to increase productivity?

First have a grip on how productivity is being measured. What are the clear value streams which are worth owning and maximizing? For each of these products, how is quality going to be accounted for so each increment is genuinely Done?

Quality is not a matter of "service ownership" to be handled as a separate concern. It's an accountability and a commitment made by Developers, irrespective of whether they have self-organized into feature teams or something else.

Hey,

Thanks for your suggestions. Really helpful.

Now we have lots of things to discover.