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.
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.
- Spend half of your day in conference rooms;
- Stop giving a single fuck about the privacy, and 'excel in transparency' (or whatever corporate bullshit is applicable).
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?
Yes, this is the only reason why people become system administrators.
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.