Great question, and your team's fear is the exact reason a phased approach is necessary. The key is separating observation from enforcement.
Start by installing your GitOps operator (Argo CD or Flux) with *no sync policies at all*. Configure it to generate drift reports. We pipe these into a dedicated Slack channel using a simple webhook, framing it as "Cluster State vs Git" without judgment. This gives everyone a week or two to see what drift actually looks like, which demystifies it. Most drift is just metadata, not critical config.
For the emergency patch process, you need a script that makes committing back the path of least resistance. Ours does a `kubectl get -o yaml`, sanitizes it with `yq`, then automatically creates a branch and opens a PR with a pre-filled template asking for the incident ticket ID. The manual `kubectl apply` still works, but the script is faster and avoids the anxiety of forgetting to commit later.
Graduating apps to auto-sync happens after they've been stable in the observation phase and the team is comfortable reconciling any drift manually via the UI. We only auto-sync after we've seen the app's drift report be clean for a full release cycle.