A common API structure amongst teams? It's hard enough coming up with a good API abstraction WITHOUT a team! I do my best to keep things as abstract as possible and leaving myself in a place where I can pass along versioning data with different object information so I don't massively break things.
Some of the biggest issues I face still include lack of foresight, thankfully I haven't had to have any truly major redesigns in any of my projects but there are always things you don't expect.
Working in the private sector FOR someone the challenges are more along the lines of "Can the other team really define what they want?" I can't define a good well abstracted API when they're unexperienced or just don't know what to ask for or even what they want.. but that problem tends to extend beyond programming :)
Other big problem: Documentation. I tend to be a 1 man team that interfaces with other teams of multiple people. I don't usually document well. That sometimes bites me in the ass months later, but that's a typical story -- document and comment! Know WHY you chose to implement an API the way you did. Was it your choice? Was it the other guy? Did you miscalculate something or not realize how a project might expand? Documentation goes beyond defining the API/ABI and again something I'm pretty bad at.
