Compliance work can look like paperwork standing between engineers and shipping. I used to see it that way, and I think most engineers still do. I have come to see it differently, and I think a few of those differences are worth writing down.
A control is a promise, written down literally
Every control I have ever been asked to follow started as a promise. A customer asked whether their data was safe, a regulator asked how changes reach production, an auditor asked who can approve a deployment, and someone answered. The control is that answer in its most literal form: a checklist, a quarterly review, a sign-off field.
Engineers rarely get shown the promise. They get shown the control, with no explanation of what it is protecting, and that is where most of the friction comes from. A rule you do not understand feels arbitrary. A promise you understand feels like a design constraint, and engineers are good at design constraints.
So the first thing I think engineers should understand is what the control is for. And the first thing I think a manager should do is find out and tell them.
The control is a first draft
The second thing is that the control is an implementation of the promise, not the promise itself. It was written by whoever answered the question first, usually under time pressure, usually without an engineer in the room. It is a first draft.
That matters because first drafts can be revised. If a control says a human reviews every change before production, the promise behind it is that no change reaches production unexamined. A pipeline that blocks on review and records who approved what keeps the promise better than a spreadsheet does, and most auditors will agree once someone explains it. The mistake is treating the spreadsheet as the requirement.
The engineering is in the evidence
Most of the cost of compliance, in my experience, is the cost of producing evidence by hand once a year. Screenshots, exports, a week of someone's time assembling proof that the team did what it says it does.
I think the real engineering problem is making evidence a byproduct of normal work. The pipeline already knows who approved a change, what tests ran, and what was deployed when. Access is already defined somewhere. If those facts are recorded as they happen, in a form someone else can read, the annual scramble mostly disappears, and the team gets something better than a passed audit: it gets a system it can actually reason about.
The auditor is not the adversary
The last thing is a matter of posture. It is easy to treat an audit as something to survive, giving the narrowest true answer and hoping the questions stop. I think that posture costs more than it saves. An auditor who understands how the system works asks better questions and accepts better answers. An auditor who is kept at arm's length falls back on the checklist, and the checklist is the expensive path.
None of this makes compliance free. There is real work in understanding each promise, revising the control to fit how the team actually ships, and building the evidence into the pipeline. But it is engineering work, with the same satisfactions as any other, and I think teams that see it that way end up with both a cleaner audit and a better system.
Photo source: https://photos.robertstowe.com/new-mexico