One useful principle that I try to apply, and see violated regularly, is that a sysadmin should understand the boundaries of their reponsibility, and take care not to overstep the mark.
What I mean by this is that often in sysadmin duties, questions and problems will arise that actually require decisions to be made by other areas of the business, but IT may attempt to address the problem without seeking out those decisions from the business.
Some good but by no means exhaustive examples of this are:
Applying retention periods to email storage. IT should not configure this retention period without consulting the business' legal authority. Setting it to 3 years because your disks can't hold any more than that, is not good enough. If it later turns out that email must legally be retained for a longer time e.g. 7 years, you are up a creek.
Disposal of old servers and workstations and secure data deletiohn - IT needs to consult with the business executives or suitable delegations as to the data security and disposal requirements of their organisation.
Some folks see this as sloping-shoulders shrugging off responsibility, or are lulled into the notion that they must be able to answer any question authoritatively no matter the subject. Often as IT folks I think we get lulled into a sense that we are expected to answer authoritatively on any subject, and not just the one in which we're knowledgeable.
So yeah... Learn and apply appropriate boundaries of responsibility to your role, and the non-IT people in your organisation will appreciate and respect your understanding of how IT fits into the business. You'll avoid a reputation of being a loose cannon, difficult to control, or arrogant. Not to mention protecting yourself against any ramifications that may arise down-the-line if the decision that was taken leads to problems.
Oh and in conjunction with the above and as a seperate principle in its own right: Always establish an email trail of decisions so that they can later be traced back and proved.