Ah, Devops! Yes, I've been in a similar situation. I set up a support desk, writing documentation and certification tests for the new platform at my firm (also

Ah, Devops! Yes, I've been in a similar situation. I set up a support desk, writing documentation and certification tests for the new platform at my firm (also providing them a portal and a nifty sentinel program that got shelved) before moving to an architecture team. I was pretty much lead technologist for them. Here's the surprising part: You make it up as you go. OK, you don't really make it up. You take the lead, find out what the business needs and stakeholder needs are, attempt to apply relevant principles (which you'll discover as you go) to their logical conclusions, and yield only when there's pushback from your boss. I was frequently given the responsibility of making people comply with the rules while being forced to ask for their permission as we went. I was nice. I was mean. I cajoled. I coerced. Principles - all and sundry were applicable. I applied principles from business to technology to morals and ethics. Principles of Unix Programming: http://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond.E2.80.99s_17_Unix_Rules http://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond.E2... The Principle of Least Privilege: http://en.wikipedia.org/wiki/Principle_of_least_privilege http://en.wikipedia.org/wiki/Principle_of_least_privilege Dr. Dobbs has an article about effective devops - http://www.drdobbs.com/architecture-and-design/top-10-practices-for-effective-devops/240149363 http://www.drdobbs.com/architecture-and-design/top-10-practi... - and IBM has a slightly different view: http://www.ibm.com/developerworks/devops/practices.html http://www.ibm.com/developerworks/devops/practices.html In general, Google for "best practices", "principles", "devops" and related terms. Always do the right thing, especially when your co-workers want to take the easy road, you'll set yourself apart from them. When asked to push code, read it and know what it does. When asked to review permissions changes, scrutinize it carefully, and ask questions. Write documentation. Know the process. Talk to the stakeholders. Update the documentation. Ask how it can be made better. Think hard, and answer that question.