Achieving Compliance as a Platform Engineering Team by Helping Developers
Ben Linders · rss · 2026-07-23 source ↗ Reader 🖥️
Career DevelopmentDeveloper Experience & FlowGolden PathGuardrailsOrganizational LegibilityPlatform EngineeringPolicy-as-CodeTrust
A platform team achieves durable compliance not by choosing better technical controls but by sequencing rollout (inform, then softly enforce, then strictly enforce) around transparency, shared purpose, and developer trust, because forced, patronizing enforcement fails even when the underlying tooling is sound.
practical · InfoQ news write-up of a conference talk, followed by a written Q&A interview with the practitioner — Short (894-word) trade-press piece condensing Davide de Paolis's Dev Summit Munich talk plus a three-question follow-up interview; testimonial in structure, not an argued essay — evidence is anecdotal and self-reported by the practitioner who owns the initiative.
Structure
| Part | Role |
|---|---|
| Opening frame | States the failure mode up front: a new platform team's forced workflows and outdated documentation degraded developer experience, setting up the rest of the piece as the diagnosis and cure. |
| Team formation and initial friction | Explains how an ambitious, well-intentioned platform team (service catalog, IDP, cloud center of excellence) nonetheless produced multiple-AWS-account complexity and context-switching pain for developers used to one loose account. |
| Diagnosis: patronizing mandate vs. shared purpose | States the article's causal claim directly: 'nobody likes to be patronised'; forced adoption rarely works, alignment does. |
| Tagging case study | Supplies the article's one piece of concrete evidence: a failed manual tagging effort replaced by a simplified, prevention (AWS Tag Policies/SCPs) + detection (Security Hub) + notification approach. |
| Focus lesson | Generalizes from the tagging case to a prioritization principle: minimum viable governance, important-and-urgent over important-but-not-yet-urgent neglect. |
| Shared-purpose lesson | Argues that tying compliance to company success and customer trust converts teams from resisters into co-owners. |
| Closing frame | Restates the thesis as a metaphor ('compliance is a journey'; 'change is messy in the middle') that book-ends the opening failure. |
| Interview Q&A | Elaborates the philosophy behind policy design ('guardrails, not handcuffs'), the tagging rollout mechanics, and the communication apparatus (Tour of Duty, RFCs, live Q&A) that the news write-up only gestures at. |
Key terms
- guardrails, not handcuffs
- minimum viable governance model
- inform first, softly enforce next, only then move to stricter enforcement
- internal customer mindset
- Tour of Duty Career Development
Propositions
- explicitcorroboratedForced governance rollouts (mandated workflows, multiple AWS accounts, unfamiliar concepts) without adequate documentation degrade developer experience and provoke frustration, even when the underlying platform ambition (service catalog, IDP, cloud center of excellence) is sound.conf: highsupports ←Time Warp: The Gap Between Developers' Ideal vs Actual Workweeks in an AI-Driven Era · p4 — Both identify security/compliance workload as a measurable drag on developer experience and satisfaction, from opposite vantage points (survey data here, platform-team practitioner account there).
- explicitcorroboratedForced or patronizing adoption of security and platform initiatives rarely works; alignment around a shared purpose does.conf: highsupportsHow Open Source Enables Collaboration in Creating a Platform · p13 — Independent case (AWS tagging/compliance rollout) corroborates the trust-not-mandate thesis for a captive internal-platform audience that lacks a market's exit and choice.supportsThree Pillars of Platform Engineering: A Virtuous Cycle · p10 — Both sources converge on developer trust, not mandate, as the mechanism that produces willing adoption of platform/governance changes.supports ←Presentation: Platform Engineering for Everyone - Success Can’t Be Coded · p3 — Both talks independently converge on the same causal claim from different domains — forced/patronizing platform or governance adoption fails, alignment around shared purpose succeeds.
- explicitdevelopedRolling out compliance/governance controls in the sequence prevention (policy-as-code validation at creation time) then detection (scanning for existing violations) then notification/communication is a reusable pattern across compliance initiatives, not specific to tagging.conf: highextends ←Terraform Introduces tfpolicy, an HCL-based Policy-as-Code Framework · p3 — tfpolicy's before-and-after-deployment evaluation is a concrete product realization of the generic prevention-then-detection governance sequencing pattern, extended so 'detection' can catch violations from actual provisioned state rather than only pre-existing drift.
- explicitA tagging initiative that treats tags as "just metadata" enforced by rule-definition alone fails; tagging adoption requires reducing scope to a minimal, opinionated tag set and tying it to outcomes developers care about (cost visibility, ownership, accountability).conf: high
- explicitPlatform and security teams cannot pursue every governance objective simultaneously; defining a minimum viable governance model and prioritizing what is important-and-urgent, without neglecting what is important-but-not-yet-urgent, is essential to avoid a later crisis.conf: high
- explicitSharing the business/customer-trust rationale behind compliance initiatives makes teams willing to support them and even fold them into their own roadmaps.conf: high
- explicitcontestedPolicies should function as guardrails that make the compliant path the easiest path, not as handcuffs; technical policy encoding (SCPs, AWS Config, Security Hub, tagging policies) alone does not create compliance — how policies are introduced (transparency, shared ownership, communicating the "why", gradual enforcement) determines adoption.conf: highcontradictsHow Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery · p13 — Golden Bricks argues compliance can be satisfied at the brick level (decentralized, encoded in the composable primitive itself); this article's platform team keeps enforcement centrally owned — SCPs, Tag Policies and Security Hub are platform-wide controls the platform/compliance team defines and operates, with consuming teams winning voice and buy-in but not guardrail ownership.
- explicitCommunication is itself part of the platform: mechanisms like a "Tour of Duty" rotation, RFCs, internal documentation, and live Q&A sessions, continuously adjusted based on feedback, are necessary infrastructure for governance rollout rather than an optional add-on.conf: high
- implicitFraming changes as collaboration rather than enforcement is what converts an adversarial 'platform vs. product' dynamic into shared ownership of compliance outcomes.conf: medium
- implicitThe organization's earlier, failed tagging initiative failed specifically because it lacked the sequencing (prevent/detect/inform) and trust-building the restarted initiative used, implying success was contingent on process redesign rather than on adopting better tooling per se.conf: medium
Arguments
Compliance and governance initiatives should be rolled out through a graduated inform-then-soft-enforce-then-strict-enforce sequence built on prevention, detection, and communication, rather than through immediate hard enforcement. strength: medium
Explicit premises:
- Forced workflows with poor documentation caused declining developer experience and frustration.
- The restarted tagging initiative, using this sequence, achieved less disruption and greater engagement.
- De Paolis states this sequencing 'proved reusable across other internal compliance initiatives.'
Implicit premises:
- Developer trust and voluntary compliance is more durable — and ultimately faster — than mandate-driven compliance, even though mandate-driven compliance can be technically imposed instantly.
- The organization has enough runway to treat compliance as a multi-stage 'journey' — an org facing an acute audit deadline or active breach may not have this luxury.
- Automated prevention and detection tooling (SCPs, Tag Policies, Security Hub) is mature and available enough at this organization to make the 'soft' stages meaningfully softer, rather than merely a slower path to the same hard wall.
Inferences:
- A
- s
- i
- n
- g
- l
- e
- t
- e
- a
- m
- '
- s
- t
- a
- g
- g
- i
- n
- g
- e
- x
- p
- e
- r
- i
- e
- n
- c
- e
- i
- s
- g
- e
- n
- e
- r
- a
- l
- i
- z
- e
- d
- i
- n
- t
- o
- a
- c
- r
- o
- s
- s
- -
- i
- n
- i
- t
- i
- a
- t
- i
- v
- e
- ,
- r
- e
- u
- s
- a
- b
- l
- e
- p
- a
- t
- t
- e
- r
- n
- b
- a
- s
- e
- d
- o
- n
- t
- h
- e
- i
- n
- t
- e
- r
- v
- i
- e
- w
- e
- e
- '
- s
- o
- w
- n
- a
- s
- s
- e
- r
- t
- i
- o
- n
- ,
- w
- i
- t
- h
- n
- o
- s
- e
- c
- o
- n
- d
- c
- a
- s
- e
- s
- h
- o
- w
- n
- .
Treating developers as internal customers and communicating context/impact before implementation is what secures compliance adoption, more than the specific technical control chosen. strength: medium
Explicit premises:
- "Policies alone don't create compliance. How they're introduced matters."
- Tagging adoption improved once teams saw tagging as an enabler rather than bureaucracy, following visibility-first communication.
- Framing changes as collaboration, not enforcement, moved the organization from a 'platform vs. product' dynamic to shared ownership.
Implicit premises:
- Developers' compliance behavior is primarily attitudinal and trust-driven rather than purely constraint-driven — convince first, and technical enforcement becomes low-friction rather than the load-bearing mechanism.
- The platform team has the standing, credibility, and spare capacity to run 'Tour of Duty' rotations, RFCs, and live Q&A sessions — a communication-heavy answer that assumes headcount a thinly staffed platform team may lack.
Inferences:
- T
- h
- e
- i
- n
- t
- e
- r
- v
- i
- e
- w
- e
- e
- '
- s
- s
- e
- l
- f
- -
- r
- e
- p
- o
- r
- t
- o
- f
- w
- h
- a
- t
- w
- o
- r
- k
- e
- d
- i
- s
- t
- r
- e
- a
- t
- e
- d
- a
- s
- s
- u
- f
- f
- i
- c
- i
- e
- n
- t
- e
- v
- i
- d
- e
- n
- c
- e
- ,
- w
- i
- t
- h
- o
- u
- t
- i
- n
- d
- e
- p
- e
- n
- d
- e
- n
- t
- v
- e
- r
- i
- f
- i
- c
- a
- t
- i
- o
- n
- (
- a
- d
- o
- p
- t
- i
- o
- n
- r
- a
- t
- e
- s
- ,
- e
- r
- r
- o
- r
- /
- i
- n
- c
- i
- d
- e
- n
- t
- c
- o
- u
- n
- t
- s
- ,
- d
- e
- v
- e
- l
- o
- p
- e
- r
- -
- s
- a
- t
- i
- s
- f
- a
- c
- t
- i
- o
- n
- s
- c
- o
- r
- e
- s
- )
- .
Narratives
- The failed early resource-tagging initiative (ownership, cost attribution, and governance left inconsistent and manual) versus the restarted effort, which simplified the tag set, used AWS Tag Policies and Service Control Policies to prevent untagged resources at creation, and used the AWS Security Hub Resource Tagging Standard to detect existing out-of-compliance resources.
→ Serves as the article's only concrete piece of evidence for the abstract thesis (prevention + detection + communication beats blunt mandate); the entire 'reusable across other internal compliance initiatives' claim rests on this single case. - The platform team's own formation — pulling experienced developers with strong DevOps/cloud backgrounds from product teams, then drafting an ambitious roadmap (service catalog, internal developer platform, cloud center of excellence) that immediately created friction: multiple AWS accounts, new concepts, and outdated documentation for developers used to one loose account.
→ Establishes that a well-intentioned, technically competent platform team can still create real developer pain — the article's 'villain' is the team's own initial approach, not an external mandate or a hostile actor, which sets up empathy and process redesign (rather than better tooling) as the fix.
Questions addressed
- ✅ How should a platform team roll out governance without degrading developer experience?
Sequence rollout as inform first, then soft enforcement, then stricter enforcement, combined with focus/prioritization (minimum viable governance) and communication of shared purpose. - ✅ How do you use technical policies (SCPs, Config, Security Hub, tagging policies) to implement compliance?
AWS-native policy-as-code tools encode expectations directly into the platform, but policies alone are insufficient — they must be paired with transparency, shared ownership, and communicating the 'why' before enforcement tightens. - ✅ What tag scope should a platform mandate, and how should it be rolled out?
A minimal, opinionated required tag set, applied via infrastructure-as-code and platform defaults, introduced visibility-first before stronger policy guardrails are added. - ⭕ What happens when 'soft enforcement' isn't fast enough for an actual audit, regulatory deadline, or active security incident?
- ⭕ Whose time and headcount funds the extensive communication apparatus (Tour of Duty rotations, RFCs, live Q&A sessions) this approach depends on?
Gaps
- incompleteNo adoption or outcome metrics are given for the restarted tagging initiative or the broader compliance rollout (no tag-coverage percentage, before/after count of Security Hub findings, or developer-satisfaction score) — the claim that it produced 'less disruption and greater engagement' is asserted, not measured.
Read next: Look for the referenced conference talk video itself, or a follow-up case study, for quantitative before/after data (tag coverage %, time-to-compliance, developer satisfaction survey) to check whether the qualitative success narrative survives contact with numbers. - uninformedThe 'inform first, softly enforce next, then stricter enforcement' cadence has no time-boxing: the article never says how long each phase lasted, what triggered graduation to the next phase, or what happens to non-compliant resources that persist through all three phases.
Read next: Compare against policy-as-code and compliance-automation literature that specifies staged rollout with explicit graduation criteria (coverage thresholds, grace periods) to see whether 'gradual enforcement' claims elsewhere fill in what this piece leaves vague. - illogicalThe article generalizes from a single team's single case (tagging) to 'this is an approach that proved reusable across other internal compliance initiatives,' but no second initiative or its outcome is described, so 'reusable' rests entirely on the interviewee's own unverified assertion.
Read next: Look for other case studies, or the interviewee's later talks or writing, describing a second compliance initiative rolled out with this same cadence, to test whether 'reusable' holds beyond tagging. - incompleteThe article never examines governance-team incentives: SCPs and Security Hub findings can be used punitively (blocking deploys, escalating to management) regardless of the 'guardrails not handcuffs' framing, and nothing addresses what stops a well-communicated soft-enforcement regime from later hardening into the very 'handcuffs' it says it wants to avoid.
Read next: Read organizational-legibility and agent-governance literature on how declared 'advisory' controls harden into mandatory gates over time, to test whether this compliance rollout is durable or a temporary honeymoon phase.
Related documents
- Three Pillars of Platform Engineering: A Virtuous Cycle
- Governing AI in the Cloud: A Practical Guide for Architects
- Presentation: Platform Engineering in the Age of AI
- How Open Source Enables Collaboration in Creating a Platform
- Reverse Engineering your Software Architecture with Claude Code to Help Claude Code
- 2024_final_dora_report
- Presentation: Platform Engineering for Everyone - Success Can’t Be Coded
- Netflix CPTO on AI and the future of product and tech roles | Elizabeth Stone
- The Meter Was Always Running
- What 60 Years of Data Reveals About How Men and Women Experience Leadership