I have worked with engineering teams from partner companies and vendors for a long time, on both sides of that relationship. I think there is a question everyone asks about them and a question almost nobody asks. The one everyone asks is how to get more out of the team. The one almost nobody asks is why some of those teams behave like owners and some behave like a queue.
I have come to believe the answer is set mostly on the client side, and the contract has less to do with it than people assume.
Ownership comes from scope
A team that is handed a backlog of tickets will take tickets. That is not a failing. It is the only reasonable response to being given tickets. What produces ownership, in my experience, is being given an area: a product surface, a set of services, a kind of problem, with the expectation that the team will understand it better than anyone else.
The test I use is whether the team could say what they would work on next if nobody told them. If the answer is no, they do not own anything yet, however good they are.
Ownership comes from decision rights
Inside that area, the team needs to be able to decide. How to build it, when to refactor, which of two approaches to take. A team that has to ask permission for every technical choice learns quickly that the choices are not theirs, and stops making them.
I think the hard part for the client side is letting those decisions be different from the ones you would have made. The point of ownership is that the owner decides. If every decision is reviewed back to your preference, you have a slower version of making the decisions yourself.
Ownership comes from information
The quickest way to keep a team at arm's length is to give them less information than the in-house teams get, or to give it to them later. Roadmap changes, incidents, why a priority moved. A team that finds out about a change of direction after it has shipped the old direction will, correctly, stop investing in understanding the direction at all.
My rule is that a partner team in the planning conversation gets the same information as everyone else in it, at the same time. If something cannot be shared, that is a scope question, not an information question, and the scope should change.
The same standards, in both directions
Ownership also means being held to the same bar. The same code review, the same quality standard, the same definition of done. I think teams can tell the difference between being trusted and being ignored, and a partner team that is never pushed back on reads it as the second.
It cuts the other way too. If the in-house teams can skip a standard the partner team cannot, the standard is a status marker, and it will be resented.
Where this stops being true
Some engagements are not meant to be ownership. A short project, a staff augmentation arrangement, a team brought in to clear a specific backlog, all of these can be exactly what they are, and dressing them up as ownership helps nobody. The mistake I am describing is wanting an owner and setting up a queue. If what you want is a queue, say so, and run it well.
Photo source: https://photos.robertstowe.com/colorado