I don't think that these two goals are at-odds. In many companies, the problem is just that neither group, developers or sysadmins, really seems to understand t

I don't think that these two goals are at-odds. In many companies, the problem is just that neither group, developers or sysadmins, really seems to understand the other. But both want the same thing -- to ship a working product. Developers really don't want growth at the expense of software that doesn't work. But many developers come from a computer science background, and I've never seen a computer science curriculum teach students about logging, testing, runtime instrumentation, monitoring theory, security, or deployment. In university, you write code in a very unrealistic fashion. Lots of individual coding, some teamwork, but your assignments nominally have well-defined inputs and outputs, and students effectively never have to carry projects across classes and semesters, the way that you would with a production application. Sysadmins, having been exposed to this, assume that developers are out to kill everything with a BIOS, and as a result tend to lock systems down, or implement weird hacks to get around the lack of logging or instrumentation. In companies I've consulted with, a bit of education goes a long way towards fixing this. I usually rotate a dev at a time through the sysadmin team, where they can both help in debugging problems, as well as tackling all the interrupts that would otherwise be divided evenly among all the engineers. The developers learn about why logging is important, gain a better understanding of the deployment process and environment, and the sysadmins gain a greater understanding of what the devs are trying to accomplish. It's amazingly effective in fixing the false dev/ops split, and in getting the two teams working together effectively.