A big part of trust is believing that we are each competent enough to understand why we have rules and to identify when following rules to the letter hinders rather than helps us. If you need to break a rule, break the rule!
At the same time, our rules and processes are one way that we communicate our shared expectations with each other. If you often find that a rule is being broken or a process is not being followed, it is important for the team to discuss whether we need to change our policies to reflect reality. When breaking rules, we encourage you to communicate your action and reasoning to the rest of the team through an appropriate channel (eg, email, code review, chat, etc.) Rules and processes are subservient to our goals, but that does not mean that they should simply be ignored.
As an example, imagine that some customer-facing service has a regularly scheduled maintenance window, outside of which the service should not be restarted. Deploying a fix to a critical security bug may be a good reason to violate that rule. However, we should make sure that we are being mindful that the rule was violated -- if we discover that the application is being regularly restarted outside of the maintenance window for "critical" fixes, that is an excellent indication that we need to re-engineer something, whether the application (to reduce critical bugs that hit production), our deployment process (so we can deploy without interrupting the service), or simply the rule (to set expectations of possible service interruptions for users).
As with everything else, our rules and processes are works-in-progress and require love and care to remain relevant and useful.