But also, if there's a manager in the middle of the bullpen, people tend to clam up. I experienced this. Managers can have a very hard time handling the typical heated and frank discussions that can arise among engineers. At one time, we had the project manager in our cube maze along with the engineers. If he sensed that two engineers disagreed with one another, or that they were discussing a problem, he would step in to manage it. The obvious outcome was that the engineers found another place to hold our discussions.
You keep using that word. I don't think you know what it means.
(Coming from a contract 'devop')
There is no such thing. Either you code, and your code helps a company's devops requirements. Or you're in ops because you can't code. I need to collaborate less than devs do. My clients know for a fact that most of my work is done more productively at home in the quiet. Yes we need to talk, plan, work with others (sometimes) but who doesn't?
It turns out that devs are great at a lot of ops type tasks.
Basically what you get is developers' innate tendencies towards laziness and over-automation yield really good ops solutions.
Where your typical sysadmin will be perfectly comfortable running a hodgepodge of shell scripts and byzantine commands through the terminal every time he wants a server push, your typical developer just wants the fucking code up on the server so he can get back to work he finds less objectionable.
This is absolutely how you want to approach ops. Just get the shit running with as little human interaction as possible.
The whole point of devops is that it combines development and operations; i.e. everyone works together to make sure that both development and operations are mutually supportive and co-ordinated. Most devops teams I have seen almost all the team are capable developers and sysadmins / operations.
If you are a coder, an engineer, or an architect, then open office is painful.
If you are a manager, then open office is embarrassing.