# The Developer Experience — Talking Points > **Companion to:** `the-developer-experience-marp.md` (10 slides) > **Content source:** `the-developer-experience.md` (full source of truth with speaker notes) > **Purpose:** Presenter-ready cues — 3-6 talking points per slide + the one key takeaway the audience should remember. > **Audience:** Senior Leadership — CTO, Head of Cloud, Head of Infrastructure, Head of DevOps --- ## Slide 1 — Title **Talking points:** - Brief introduction — this deck covers *who uses the platform and how fast/safe they ship*, not the internal mechanics (that's the companion deck) - Set the frame: velocity without sacrificing safety, and security/observability/compliance as platform defaults rather than per-team effort **Key takeaway:** The consumer surface is intentionally tiny. The platform's surface is large and opinionated. --- ## Slide 2 — Two Consumer Surfaces, One Platform **Talking points:** - This is the thesis of the deck — the two surfaces are *parallel*, not a progression. A citizen developer doesn't "graduate" to the developer surface - Both produce a contract; both get the same treatment. The platform is opinionated in what it accepts, regardless of who is declaring - The leadership takeaway: we expand who can ship safely without lowering the bar. There is no "citizen developer mode" with weaker checks - The citizen developer surface is agentic — an AI agent produces a contract that passes the same safety envelope as a senior engineer's. Be honest: the skill catalog and real agent runtime are planned **Key takeaway:** Two consumer surfaces, one safety envelope. No weaker mode for non-technical users. --- ## Slide 3 — The Contract — The Entire Consumer Surface **Talking points:** - Hold this slide — the audience should sit with how small the consumer surface is. Three things: app code, a contract, a one-line CI definition - The contract is a single YAML file: module, environment, inputs. That's the entire consumer-facing interface to production - Walk the "does not" list quickly — no infrastructure modules, no platform repo cloning, no cloud credentials, no state backends. Every item is a category of toil the platform removes - For the Head of DevOps: this is the lever for throughput — the bottleneck moves off the platform team's ticket queue - The consumer never touches platform internals — the platform fetches itself at run time. When the platform ships a fix, every consumer on a floating tag gets it on their next run **Key takeaway:** Three things. That's the entire consumer-side surface. Everything else is the platform's job. --- ## Slide 4 — The Developer Feedback Loop **Talking points:** - This directly answers "but developers hate platforms that hide what they're doing" — the platform is opinionated about *what* runs, not *opaque* about *that* it runs - Streamed output by default — the plan, policy results, and each check record flow to stdout. A `--quiet` mode exists for log-only contexts - PR comments after every successful pipeline stage — a developer always knows where they stand without refreshing a dashboard - Connection strings posted as PR comments — human-readable, no hunting. Runtime secrets go to encrypted Parameter Store, never to logs - The "errors become GitHub issues" point is a DX win that also helps the platform team — every consumer failure is a tracked, queryable artifact, not a lost log line - Clear, explainable halt reasons — a policy violation, an insufficient confidence signal, or a missing attestation. Never an opaque debugging exercise **Key takeaway:** The platform closes the feedback loop — streamed output, PR comments, clear halt reasons, no secrets in logs. --- ## Slide 5 — Versioned, Predictable Releases **Talking points:** - This is the "no surprise upgrades" story — consumers aren't forced to chase the platform, and the platform isn't forced to support N forks of every workflow - Floating MAJOR + MINOR tags (e.g. `@v1.6`) — a consumer automatically receives patch updates within the line. Pin to exact version for stability, or float on MAJOR only for new features - Semantic versioning with a clear contract: interface → MAJOR, behavior → MINOR, lifecycle → PATCH - Unversioned references (`@main`, bare) are discouraged — the versioned tag is the only immutability lever a consumer has - The automated release job computes the next semver on merge to main, creates the tag, and updates the floating tags — no manual release process **Key takeaway:** Consumers control when they absorb platform improvements. No surprise upgrades. --- ## Slide 6 — Friendly Onboarding **Talking points:** - This looks like a small thing; it's actually a cultural one — the platform's posture is "help me get started," not "you should have known" - First impressions of a platform are made when it fails for the first time. The platform fails gracefully with a guided prompt, not an opaque error - The prompt tells the consumer: what's missing, what the platform will provision, the expected turnaround, and how to request an environment - The pipeline exits without attempting a deployment — no partial state, no confusing errors - Both onboarding paths end in a sandbox dev submission that must pass the confidence gate before the consumer is promoted - Be honest: the citizen developer onboarding path is planned, not yet shipped **Key takeaway:** The platform fails gracefully. First impressions drive adoption — platforms that fail opaquely get routed around. --- ## Slide 7 — Safe Promotion Path **Talking points:** - Promotion is a workflow choice, not a contract mutation — this matters because it means a promotion can be reviewed as a *diff in the workflow*, not as a rewritten contract - Approach A (one contract, environment passed by the job) keeps the single source of truth — the contract never changes - Approach B (environment-specific contracts) lets teams whose inputs genuinely vary keep that variation explicit and reviewable - The platform raises the bar automatically: dev ≥ 0.50 (autonomous) → qa ≥ 0.75 (QA attests) → prod ≥ 0.90 (SRE attests). The consumer can't bypass the gates — they pick *which* environment to target, and the platform applies the right bar - Separation of duties is enforced — the QA approver cannot be the prod approver. Be honest: design is tested, wiring for qa/prod/dr is planned - No staging environment — the design deliberately removes the "staging is basically prod but not really" anti-pattern **Key takeaway:** Change the environment field, not the contract. The platform raises the bar automatically. The consumer can't bypass the gates. --- ## Slide 8 — Safe Decommission **Talking points:** - The counter-argument to "deletion protection makes cleanup impossible" — decommission is a first-class, gated, two-approval flow, not a lock with no key - The change request must be `approved` in the CMDB and match the consumer repo — no CR, no decommission - Two SRE human-attestation gates: one to disable deletion protection, a second to zero counts and destroy - The per-stack encryption key enters a 30-day grace window so encrypted data remains recoverable — the key is permanently deleted only after the window expires - For the Head of Infrastructure: the CMDB validation means decommission is auditable, not just possible - Uptime monitoring is not automatically destroyed — it can be left running to watch decommissioned endpoints go dark **Key takeaway:** Tearing down is as gated as deploying. Two SRE approvals, CMDB-validated change request, 30-day key grace window. --- ## Slide 9 — Self-Service Module Catalog **Talking points:** - The catalog is what makes "declare intent" practical — you can only declare a module that exists - Primitives are single-purpose resources (S3, VPC, ECS, IAM, ALB, ECR, CloudFront, WAF, RDS) — each with documented inputs/outputs, usage, compliance extension points, and versioning - Modules are composed patterns (a static site with CDN + WAF; a microservice with VPC + ECS + ALB + registry) — one well-reviewed module serves every consumer - Validated examples per module — `simple.yaml` + `complex.yaml` + variation files, validated against the contract schema in CI. Examples cannot drift from the schema silently - For leadership: the catalog is the leverage — a fix to a module serves every consumer on the next run. This is the compounding asset - Auto-promotion of patterns (after 3 observed usages) and compliance extension points (GDPR, SOX, SOC2, DORA) are planned **Key takeaway:** The catalog is the compounding asset. One well-reviewed module serves every consumer. A fix serves everyone on the next run. --- ## Slide 10 — The Desired Outcomes **Talking points:** - Close on the strategic frame — the platform is not "a CI/CD tool," it's the organizational lever for shipping safely at the pace the business demands - Velocity without sacrificing safety: speed is in the ergonomics (a simple contract, a one-line `uses:`), safety is in the gates the consumer cannot bypass - Security, observability, and compliance as platform defaults — not per-team effort, not post-hoc remediation. Encryption, deletion protection, uptime monitoring, policy checks, and evidence are on by construction - Auditability as a byproduct, not a project — every production change is traceable to a human attestation and a tamper-evident evidence event - The bottleneck moves off the platform team's ticket queue — a merged change progresses through lower environments without a platform engineer joining a thread - Infrastructure as a utility, not a craft — teams consume, they don't maintain. The platform compounds value over time by learning from recurring patterns - The path to the citizen developer — the same safety envelope that serves a senior engineer will serve a non-technical consumer. Expanding who can ship safely without lowering the bar **Key takeaway:** Velocity without sacrificing safety. Security and auditability as byproducts. The bottleneck moves off the platform team's queue.