Platform teams risk alienating developers—here's how to enforce compliance without friction

Imagine your platform team announcing new deployment rules with a tight deadline and no consultation. That's a recipe for resentment. Davide de Paolis, engineering manager at SevDesk, opened his talk on internal compliance with a cautionary scenario: imposing cloud infrastructure guidelines without stakeholder buy-in, refusing to discuss timelines with product managers, and breaking deployments if teams don't comply.

He was describing a path to failure.

Why enforcement without consent breeds backlash#

Platform teams occupy an awkward position: they're removed from product deadlines and shipping pressure, yet they arrive with mandates about how other teams must work. The initial impulse is understandable. When costs climb and security vulnerabilities emerge, urgent action feels necessary. But forcing change creates resistance, not adoption.

De Paolis's team at SevDesk—an accounting software company built on AWS with roughly 15 teams and 80–90 engineers—learned this the hard way. When they replaced homegrown infrastructure tools (Keycloak, Longhorn, Harbor) with AWS-native services (IAM, EBS, ECR), they pushed significant work onto product teams without preparing them. Developers suddenly had to:

• Switch between multiple AWS accounts instead of one
• Rewrite deployment pipelines
• Learn unfamiliar cloud services
• Tag every resource according to new policies

The developer feedback was blunt: "That's a shitty developer experience." The platform team, frustrated that people weren't reading the lengthy documentation, didn't recognize the real problem: change is hard, and documentation alone doesn't make it easy.

The compliance challenge: tagging as a case study#

Resource tagging is deceptively simple—just key-value pairs denoting owner, criticality, and service name. But SevDesk's original policy documentation was sprawling and outdated. Manual tagging invites typos and inconsistency. Without enforcement, compliance drifts.

The platform team experimented with AWS's native controls: Tech Policies (which define allowed tag values), Service Control Policies (which block non-compliant deployments), and the AWS resource tagging standard (which flags violations in Security Hub).

However, they hit practical limits: Service Control Policies have character limits and caps on how many can be attached. Different AWS services implement tagging differently. The solution: focus on "heavy hitters"—the services consuming the most cost and resources—rather than trying to enforce every service at once.