Common focus is one thing; changes should be driven by a concrete external goal that is shared by all parties. You don't push code because it's Thursday, you push code because it's got new feature X that matters to client Y.

A culture of humility is also important; Ops/IT people build walls of process when developers chew them out for mistakes, which only gets worse when a chunk of those mistakes (but not all) end up falling on the developers. At most shops, when there's a problem, this is the general flow of things:

1. The software got updated on the site, and now customers can't access anything, but everything looks to be running.

2. Sales/Management/CS scream to fix the problem.

3. Ops blames Dev, and Dev blames Ops.

4. After the problem is fixed, Ops adds new process to make sure this problem doesn't happen again.

When, in my perfect world (and at both places I work, for the most part), it goes like this:

1. The software got updated on the site, and now customers can't access anything, but everything looks to be running.

2. Sales/Management/CS scream to fix the problem.

3. Dev and Ops both say, "We might have screwed up, let's dig deeper...", find the problem and fix it.

4. Whoever found and fixed the problem gets a beer.

This can't work unless you've got a company culture of "fix the problem, reward the fixer", rather than the prevailing culture of, "nail the responsible party to a tree."

Finally, getting out of the ivory towers is also really important. Dev people need to realize that their mistakes cause serious grief for the Ops guys, and the Ops people need to realize that making life harder for the developers through over-regulation (not having local admin, etc) causes equal pain. Mutual respect, which comes from working together, is important.