When a new platform team set out on implementing their roadmap through forced workflows with poor documentation, developer experience declined. Success came from simplifying governance, prioritizing what matters, and rolling out compliance incrementally through prevention, detection, and communication, as Davide de Paolis explained in the video of his talk The Road to Compliance from Dev Summit Munich. Empathy, focus, and shared purpose drove successful adoption.

When the need for a dedicated platform team became clear, the organisation formed one by bringing together experienced developers with strong DevOps and cloud backgrounds from product teams, De Paolis said. The team was ambitious, drafting roadmaps for a service catalog and envisioning an internal developer platform and cloud center of excellence.

However, these changes created friction. Developers were suddenly faced with new workflows, multiple AWS accounts, and unfamiliar concepts, De Paolis explained:

They were used to having one account, and permissions were broader and looser. Now they had to switch contexts, update configurations, and learn new skills.

At the same time, documentation was often lengthy, outdated, and hard to navigate. As a result, developers submitted frequent requests and voiced frustration about a declining developer experience. "Nobody likes to be patronised and told what to do," De Paolis stated, pointing out that security and platform teams often fall into this trap. Forced adoption rarely works; alignment around a shared purpose does, he added.

One concrete example was resource tagging. An earlier tagging initiative had failed, leaving ownership, cost attribution, and governance inconsistent and largely manual. De Paolis’ team restarted the effort with a different approach: simplify first. They reduced the number of required tags and standardized them using AWS Tag Policies and Service Control Policies to validate inputs and prevent the creation of untagged resources. In parallel, they used the AWS Security Hub Resource Tagging Standard to detect existing resources that were already out of compliance.

By combining prevention, detection, and notification, the team introduced tagging with less disruption and greater engagement, De Paolis argued:

Inform first, softly enforce next, and only then move to stricter enforcement. This is an approach that proved reusable across other internal compliance initiatives.

A key lesson was focus. Platform and security teams can do many things, but not everything at once. Defining a minimum viable governance model and prioritizing what truly matters to the business is essential, De Paolis explained:

If you have thousands of security findings, you need to start somewhere. Focus on what’s important and urgent, but don’t ignore what’s important and not yet urgent, or it will become a crisis later.

Sharing context and purpose proved critical. When teams understood that compliance initiatives were tied to company success and customer trust, they were more willing to support them and even incorporate them into their own roadmaps.

Compliance is a journey, De Paolis said. It takes time, patience, empathy, and a lot of communication. It works best when it’s embedded into everyday workflows and treated as a shared responsibility:

Transparency, empathy, and incremental rollout matter as much as the technology itself. When teams see compliance as something that helps them move faster and safer supported by clear detection and sensible guardrails, adoption follows naturally.

Change is always messy in the middle, but it’s worth it in the end, he concluded.

InfoQ interviewed Davide de Paolis about their journey of compliance.

InfoQ: How do you use tech policies to implement compliance in your organization?

Davide De Paolis: We treat policies as guardrails, not handcuffs. The goal is to make the compliant path the easiest one. We use AWS-native tools like Service Control Policies, AWS Config, Security Hub, and tagging policies to encode expectations directly into the platform.

That said, policies alone don’t create compliance. How they’re introduced matters. We prioritize transparency, shared ownership, and clear communication around the "why." Whenever possible, we rely on automated detection and gradual enforcement rather than sudden hard blocks. Combined with an internal customer mindset, this makes compliance something teams align with naturally.

InfoQ: What was your approach for rolling out tagging, and how did that work out?

De Paolis: Initially, we treated tagging as "just metadata," assuming teams would adopt it once rules were defined. That didn’t work. Tagging only succeeds when it’s clearly tied to outcomes developers care about—cost visibility, ownership, and accountability.

We started with a minimal, opinionated set of required tags and made them easy to apply via infrastructure-as-code and platform defaults. We focused on visibility first, showing teams what was missing and why it mattered. Only later did we introduce stronger guardrails through policies. Adoption improved significantly once teams saw tagging as an enabler, not bureaucracy.

InfoQ: How do you communicate changes and collaborate with teams?

De Paolis: Communication is part of the platform. We explain context and impact before implementation and communicate early to avoid surprises.

For larger initiatives, we use a *Tour of Duty* model, where engineers temporarily join the platform team (or vice versa). This provides hands-on feedback and helps spread context back into product teams. We also use RFCs, internal documentation, and live Q&A sessions, continuously adjusting based on feedback.

Most importantly, we frame changes as collaboration, not enforcement. That shift helped move us from a "platform vs. product" dynamic to shared ownership.

About the Author

Ben Linders