What's your philosophy on developer ownership, and how do you instill that in your team?

I believe every team member needs to take ownership of the actions and processes they are managing and deploying. I would not necessarily distinguish a developer from other IT professionals regarding ownership.
We all love when our employees take ownership of something, but how do we ensure that happens regularly?
It starts with setting up expectations and communicating very clearly with each team member, team leads, and managers. In every product/project meeting, I reiterate the responsibilities, what needs to be the outcome, who needs to take ownership of the whole process, and who needs to take ownership of the sub-processes. I coach my team leads and manager to do the same when overseeing a project or delegating a task or activity.
It is essential to have end-to-end ownership when the situation allows it. 
I find it ineffective when the person/team takes ownership of the problem/process while it is on their table. Then once it's sent/escalated to a different team/group, you transfer the ownership and forget about it. Things get lost if the other side is not embracing the ownership. I encourage my team to follow up and keep the ownership of the process/action even when it is not directly in their hands. They might wait on another team's input, but they are the one that needs to push, verify and ask for results and communicate that with the customers or other internal teams.
It's about setting the culture that this team takes ownership very seriously. You show that via examples, it needs to come from the top. Your employee needs to see and experience you taking ownership and following up on them until the end. 

I push developer ownership very strongly. Ownership begins at the beginning of discussions with product, even before defining. We try to provide insights around what we are looking for and the direction that we are going to take, at least for the engineering leads. When things are more mature, that's when we start pulling in the developers on the team. We explain to each team what we're trying to achieve, and then there's a big push to product. For product, you need to define whys rather than try to bring in a solution right away. You can propose something but don't introduce a solution if you can’t answer the why, because then we can't elaborate or change. We can't know if what we are doing is achieving the goal if you’ve already defined it. That leaves little room for us to do anything. 

I've been through phases at a number of companies where QAs were extinct. But when quality assurance is gone, that causes a bottleneck. Then when it goes to product, you create a cycle in which you’re always getting stuck. You can't move forward or move continuously. So much of this process needs to happen beforehand. It could be a matter of just switching our approach, so we make small changes and deploy all the time. Having that continuous deployment means that the developers are in constant communication with UX to understand whether what they did is correct. They’re always talking to product to see if they missed something.

Once they are certain, that is where the ownership comes in. They need to be certain that they built something that's reasonably good and is achieving the goal. The developers will move forward, we’ll provide tools, and they will go and deploy. They put their code into production, and monitor to make sure that they deliver the expected value to the customer. And if things don't go perfectly, then we iterate again.