In the rapidly evolving landscape of cloud-native development, the tension between agility and governance is a persistent friction point. As organizations scale, the need for centralized platform teams to manage infrastructure becomes undeniable. However, the path to maturity is often paved with good intentions that manifest as "forced workflows"—a phenomenon that frequently leads to a significant decline in developer experience (DevEx).
At the recent Dev Summit Munich, Davide de Paolis, a veteran in platform engineering, shared a transformative case study titled The Road to Compliance. His insights reveal that the key to sustainable governance lies not in stricter enforcement, but in the strategic application of empathy, incremental adoption, and a "shared purpose" mindset.
The Genesis of the Friction: An Ambitious Start
When an organization recognizes the need for a dedicated platform team, the common practice is to pool experienced engineers—often those with deep DevOps and cloud-native backgrounds—from various product teams. De Paolis’s organization followed this blueprint, assembling a team with the explicit mandate to build a centralized service catalog, a robust internal developer platform (IDP), and a Cloud Center of Excellence (CCoE).
Initially, the team’s ambition exceeded their ability to integrate with existing developer workflows. They introduced multiple AWS accounts and complex configuration requirements to teams that were previously accustomed to a more monolithic, "looser" environment.
"They were used to having one account, and permissions were broader and looser," De Paolis explained. "Now they had to switch contexts, update configurations, and learn new skills."
The result was a classic case of technological "paternalism." The platform team, acting with the best of intentions, pushed documentation that was often dense, outdated, and navigationally hostile. Developers, overwhelmed by the sudden shift in cognitive load, began submitting endless support tickets, creating a bottleneck that soured the relationship between the platform team and the product squads they were meant to serve.
Chronology of a Turnaround: From Friction to Flow
The turning point for De Paolis’s team came when they realized that compliance is not a technical problem to be solved, but a cultural challenge to be navigated. They identified three distinct phases of their evolution:
1. The Realization of "Forced Adoption"
The team recognized that developers—much like any other internal customer—dislike being told what to do without context. The "command and control" approach to platform engineering often backfires, leading to shadow IT or active resistance. The platform team acknowledged that their top-down mandates were driving developers away rather than empowering them.
2. The Shift to Minimal Governance
The team pivoted by applying a "Minimum Viable Governance" (MVG) model. Instead of enforcing every possible compliance standard at once, they focused on what truly mattered. By identifying high-priority risks, they reduced the initial friction for developers while still satisfying the organization’s security and compliance requirements.
3. The Incremental Rollout
Moving away from "hard blocks," the team adopted a strategy of:
- Inform: Communicate the "why" behind the change.
- Detect: Use automated tools to identify non-compliant resources without immediately breaking the build.
- Enforce: Only after providing ample time for adjustment did they implement automated guardrails to prevent non-compliant resources.
The Case Study: Simplifying Resource Tagging
Perhaps the most illustrative example of this shift was the organization’s approach to resource tagging. An earlier attempt at mandatory tagging had failed spectacularly, resulting in inconsistent data, poor cost attribution, and manual, error-prone workflows.
De Paolis’s team restarted the effort with a "simplify first" philosophy. They slashed the number of required tags, keeping only the essential metadata. They then implemented AWS Tag Policies and Service Control Policies (SCPs) to standardize inputs. Rather than just blocking, they leveraged AWS Security Hub’s Resource Tagging Standard to provide visibility into what was missing.
By showing developers exactly what was out of compliance—and explaining that these tags were necessary for cost transparency and ownership—the team transformed a bureaucratic chore into an act of shared accountability.
Official Perspectives: The Philosophy of Guardrails
In an exclusive follow-up interview with InfoQ, Davide de Paolis expanded on the philosophy that guided these successes.
On the Role of Policy
"We treat policies as guardrails, not handcuffs," De Paolis noted. The objective is to make the compliant path the easiest path. By embedding policies into the platform using AWS-native tools (Config, Security Hub, SCPs), the organization ensures that compliance is a byproduct of normal development rather than an external check performed at the end of the pipeline.
On Communication and Feedback Loops
De Paolis emphasizes that communication is a core feature of the platform. "For larger initiatives, we use a Tour of Duty model, where engineers temporarily join the platform team," he explained. This cross-pollination of roles ensures that the platform team understands the reality of the developers’ daily lives, while developers gain an appreciation for the complexities of cloud governance.
When asked about the "platform vs. product" dynamic, De Paolis was clear: "Most importantly, we frame changes as collaboration, not enforcement. That shift helped move us from a confrontational dynamic to one of shared ownership."
Implications for the Industry
The lessons learned by De Paolis’s team have broad implications for the platform engineering movement.
Empathy as a Technical Skill
The most successful platform engineers are those who view developer experience as a primary KPI. When developers feel "patronized," productivity drops. When they feel supported by "sensible guardrails," they move faster and more safely. Empathy, in this context, means designing for the user’s cognitive load rather than just the architect’s ideal state.
The Power of "Inform, Detect, Enforce"
This three-step lifecycle is a replicable pattern for any organization struggling with governance.
- Inform: If the developers don’t understand the business value (e.g., how tagging leads to better budget allocation), they will view compliance as a tax.
- Detect: Providing dashboards and clear feedback allows developers to self-correct, which is far more efficient than waiting for a security audit to reveal a problem.
- Enforce: By the time a hard block is introduced, the team should have already had the opportunity to adjust.
Prioritization is Mandatory
Platform teams often fall into the trap of trying to solve every security finding at once. De Paolis warns against this. "If you have thousands of security findings, you need to start somewhere," he advises. "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."
Conclusion: The Long Road to Compliance
Compliance is not a destination that is reached once and forgotten; it is a journey of continuous improvement. The "messiness" of the middle—where legacy processes clash with new, automated workflows—is an inevitable part of the transformation.
However, as De Paolis’s experience demonstrates, the outcome of this transformation is a more resilient, transparent, and high-performing organization. When platform teams stop acting as gatekeepers and start acting as enablers, compliance becomes an invisible, integrated element of the development lifecycle.
The shift from "enforcement" to "collaboration" is not just a change in tone; it is a fundamental shift in how modern engineering organizations must function to survive and thrive. By prioritizing the human element of development, teams can turn the daunting task of compliance into a natural, seamless part of their daily work. As De Paolis concluded: "Transparency, empathy, and incremental rollout matter as much as the technology itself."







