TCP #95: The Real Conflict Between Speed and Compliance
Most platform teams see opposing forces. High performers see architectural choices. Compliance as infrastructure eliminates the tradeoff.
You can also read my newsletters from the Substack mobile app and be notified when a new issue is available.
Platform teams get two mandates from leadership.
Move fast. Ship features. Reduce deployment friction. Enable developer velocity.
Stay compliant. Pass audits. Maintain SOC 2. Meet regulatory requirements.
Teams hear these as opposing forces. Speed requires removing gates. Compliance requires adding them. The tension feels irreconcilable.
It is not.
Why Speed Matters and Why Compliance Matters
The case for speed is straightforward. Market position depends on delivery velocity. Competitors ship daily. Your team ships monthly. The gap compounds. Customers leave. Revenue suffers. Engineering talent follows.
Speed means reducing cycle time. Fewer approvals. Fewer handoffs. Fewer barriers between code and production. Developer experience improves. Productivity increases. The business moves faster.
The case for compliance is equally clear. Regulatory violations carry material consequences. GDPR fines reach 4% of global revenue. HIPAA violations trigger federal investigations. SOC 2 failures cost enterprise contracts. A single breach terminates customer trust.
Compliance means control. Access reviews. Change approvals. Audit trails. Segregation of duties. Evidence collection. These controls protect the organization from catastrophic risk.
Both arguments are correct. Speed matters. Compliance matters. The conflict arises when teams treat them as competing priorities that need to be balanced.
Balance implies tradeoff. Tradeoff implies loss. Teams optimize for one at the expense of the other.
This is the trap.
How Compliance as a Project Creates Deployment Bottlenecks
Most organizations treat compliance as a project. The project has phases. Requirements gathering. Control implementation. Documentation. Audit preparation. Remediation. The audit passes. The project ends.
Six months later, controls have drifted. Documentation is stale. New services launched without security reviews. The next audit finds gaps. Leadership launches another compliance project. The cycle repeats.
Compliance-as-a-project creates two failure modes.
First, compliance becomes a gate. Security reviews block deployments. Change advisory boards meet weekly. Approval workflows add days to every release. Platform teams compensate by batching changes. Batch size increases. Deployment frequency decreases. Velocity collapses.
Engineering sees compliance as the constraint. They are correct. The constraint is real. The diagnosis is incomplete.
Second, teams build escape hatches. They create exception processes. They route around the gates. The exceptions become standard practice. Compliance controls exist on paper. Reality diverges. The audit passes because auditors review documentation, not behavior.
The organization thinks it is compliant. It is not. The organization thinks it is moving fast. It is not. Both goals fail.
Speed is easy. Predictability is hard. I build platforms that deliver both.
The root cause is architectural. Compliance implemented as a project layer sits outside the platform. The platform enables speed. The compliance layer constrains speed. The two systems conflict.
The conflict is structural, not philosophical.
Building Compliance Into Platform Infrastructure
Compliance is not a project. It is an operating system.
An operating system runs continuously. It does not have an end date. It enables work rather than blocking it.
Compliance as an operating system means embedding controls into the platform layer. The platform enforces compliance by default. Teams move fast because the platform makes compliant actions the path of least resistance.
Access control becomes infrastructure. Developers provision resources through the platform. The platform enforces least privilege, generates audit logs, and rotates credentials. No security review required. The control is in the code.
Change management becomes deployment architecture. The platform enforces testing gates, gradual rollout, and rollback capabilities. Deployments happen daily. Every deployment is compliant.
Data protection becomes the default configuration. The platform encrypts at rest and in transit, enforces retention policies, and manages key rotation. Developers build features. The platform handles compliance.
This approach inverts the traditional model. Traditional compliance starts with requirements and builds controls from them. Compliance as an operating system starts with the platform and embeds requirements.
Make compliant actions easier than non-compliant actions.
Automate evidence collection.
Treat compliance debt like technical debt.
The platform becomes the compliance boundary. Everything inside the boundary is compliant by construction. Teams move fast inside the boundary. The boundary enables speed rather than constraining it.
The tension between speed and compliance dissolves when compliance is built into the infrastructure.
When Compliance Becomes Platform Architecture
Leadership says move fast and stay compliant. Platform teams hear contradiction. The contradiction exists only when compliance is external to the platform.
Build compliance into the operating system. Speed and compliance become one and the same.
Whenever you’re ready, there are 2 ways I can help you:
Free guides and helpful resources: https://thecloudplaybook.gumroad.com/
Get certified as an AWS AI Practitioner in 2026. Sign up today to elevate your cloud skills. (link)
That’s it for today!
Did you enjoy this newsletter issue?
Share with your friends, colleagues, and your favorite social media platform.
Until next week — Amrut
Get in touch
You can find me on LinkedIn or X.
If you would like to request a topic to read, please feel free to contact me directly via LinkedIn or X.