Thanks a lot, Tassio!

That always happens. And that is the hard part.

Often duplication solves that, but in some other cases it is ok just to share some common code. Because each decision has a pro and a con, it is to evaluate and see how teams behave. If you are creating a choke synchronization point between teams, remove it. If it is only occasional, really occasional, and it is not full of these occasional situations —becoming a recurring problem— then you can have a common library.

Yet, the problem is complex. Fortunately, there is a lot of good literature about how to overcome it. If you are interested, Domain Driven-Design —as it was conceived, try to look for the original sources— can help a lot. It describes boundaries, how they work, etc. And it even explains that each team should have its own repository —not shared with other teams—, and it even contemplates something called "shared-kernel" that it is just this shared library. If you want an introduction, the book Domain-Driven Design Distilled it's a great start. It's short, easy to read, it introduces almost every concept, and you can read several times to get all the concepts —at least that is what I needed, combining with real practice.