Q&A Summary from a Live Session | TechStrong Group & EY
This document summarizes key insights from a live session on Platform Engineering, featuring experts from EY (Terja Shadri) and TechStrong Group (Mike Bizard, Sharon Florentine).
The session explored the why, how, and what of Platform Engineering — including standardization, security, developer experience, ROI, and AI integration.
Perfect for:
- Interview prep
- Internal training
- Leadership presentations
- Onboarding new platform teams
Answer:
Platform Engineering is the practice of designing, building, and operating internal developer platforms that provide standardized, automated, and self-service toolchains to help software teams build, deploy, and operate applications faster and more securely.
Goal: Reduce cognitive load, accelerate delivery, and improve consistency.
| DevOps | Platform Engineering |
|---|---|
| Focuses on culture, processes, and collaboration. | Focuses on building the platform (infrastructure, toolchains, workflows). |
| Emphasizes CI/CD, automation, feedback. | Builds reusable, opinionated components (e.g., IaC, security policies). |
| Reactive to team needs. | Proactively designs foundations for software delivery. |
Bottom line: DevOps enables delivery. Platform Engineering enables DevOps.
- Reduce developer cognitive load
- Improve time-to-market and onboarding speed
- Standardize architecture, security, and compliance
- Enable reuse and reduce duplication
- Improve reliability, security, and observability by default
North Star Metric: Time to 10th PR (e.g., Spotify reduced it from 42 days to ~20).
A sustainable platform balances standardization with developer experience (DX).
- Be opinionated, not dictatorial: Enforce good practices (e.g., secure by default), but allow flexibility for edge cases.
- Focus on DX: Easy to use, well-documented, fast feedback.
- Enable self-service: Developers deploy with a click.
- Start with a TVP (Thin Viable Platform): Even a well-documented Wiki counts.
Avoid: Over-engineering, forcing adoption, or ignoring developer feedback.
- Focus on value, not mandates.
- Make it easier than doing it manually.
- Involve developers early: Co-design workflows, run feedback loops.
- Create a Platform Adoption Team (internal consultants) to help teams transition.
Truth: Developers won’t resist a platform that makes their lives easier — they’ll help improve it.
| Challenge | Solution |
|---|---|
| Cultural resistance | Start small, demonstrate value |
| Platform proliferation | Centralize with leadership buy-in |
| Budget constraints | Use TVP, vendors, or open-source tools |
| Legacy systems | Wrap in containers, create adapters |
Start with a TVP (Thin Viable Platform) — even a Wiki with patterns counts.
Track these KPIs:
| Metric | Why It Matters |
|---|---|
| Time to 10th PR | Developer velocity |
| Time to onboarding | New devs become productive faster |
| Reuse KPI | Time saved via automation (e.g., 4 hrs → 30 mins per VM) |
| Platform adoption rate | % of teams using the platform |
| Lead time for changes | Speed from commit to production |
| Security compliance rate | % of deployments meeting baselines |
CFO Pitch: "We’re reducing total cost of software development and security."
Security is baked in, not bolted on.
- Security by default: Enforce encryption, IAM, network policies.
- Security tools as platform services: SCA, SAST, CSPM.
- Policy-as-code: Use Open Policy Agent (OPA), AWS Config.
- Developer-focused: Scanning, approval gates, feedback in pipeline.
Result: Developers don’t have to "think about security" — it’s handled automatically.
AI is another layer on the platform.
Use cases:
- AI asset marketplace: Pre-approved models (e.g., LLMs, NLP tools).
- Prompt catalog: Curated, secure prompts for common tasks.
- Platform co-pilot: GPT-like bot to guide developers: "How do I deploy a web app on Java?"
- AI for optimization: Use internal data to train domain-specific LLMs.
Caution: Never use public AI models with sensitive data. Use data privacy controls.
- ITSM remains: Change requests, SLAs, P1/P2 tickets still apply.
- DevOps workflows still exist: CI/CD, monitoring, incident response.
- Platform as a product: The platform itself follows ITSM processes.
Bottom line: Platform Engineering enhances, not replaces, ITSM and DevOps.
Use opinionated flexibility:
- Standard path: Offer a "golden path" (e.g., .NET + Kubernetes).
- Alternative paths: Support other languages/frameworks, but with less friction.
- Use the Pareto Principle: Focus on the 20% of use cases that drive 80% of value.
Example: 95% of apps use .NET → invest in better DX for .NET.
Phased approach:
- Start with a TVP (Thin Viable Platform):
- A well-documented Wiki with:
- Architecture patterns
- IaC templates
- CI/CD example
- Security policies
- A well-documented Wiki with:
- Add automation: Use Terraform, Ansible, or Pulumi.
- Introduce self-service: Build a developer portal (e.g., Backstage, Port).
- Scale with vendors: Use open-source or commercial tools.
- Grow iteratively: Add features based on feedback.
No need to build everything at once. Start small, validate, then expand.
This internal team acts as consultants and enablers:
- Helps teams migrate to the platform.
- Provides training, documentation, and support.
- Gathers feedback and drives platform improvements.
They’re not "enforcers" — they’re "helpers" who make adoption easier.
- Use the same observability stack the platform uses for its own services.
- Instrument all platform components (APIs, IaC, pipelines).
- Provide dashboards and logs for developers to troubleshoot.
- Enforce telemetry standards (e.g., structured logs, trace IDs).
Goal: The platform should be as observable as the apps it deploys.
“We’ll build a full platform from scratch.”
Why it fails:
- Too expensive and time-consuming.
- No real-world feedback to validate design.
- High risk of over-engineering.
Better approach:
Start with a TVP (Thin Viable Platform). Use existing tools (e.g., Backstage, Port, GitHub Actions). Learn from real usage.
Lesson: “Don’t build the castle. Start with the gate.”
- Wrap them in containers or APIs (e.g., via Docker, API Gateway).
- Create adapters to connect to modern workflows.
- Gradually refactor or migrate over time.
- Monitor closely and document.
Goal: Avoid forcing a complete rewrite — integrate and evolve.
The platform will become:
- AI-powered: Co-pilots, auto-generated IaC, smart recommendations.
- More modular and composable: Plug in new tools and services easily.
- Domain-specific: Industry-focused platforms (e.g., healthcare, finance).
- Self-optimizing: Use internal data to improve performance and cost.
The platform will not just support development — it will drive innovation.
| Principle | Action |
|---|---|
| Start small | Begin with a TVP (Thin Viable Platform). |
| Focus on DX | Make it easy, fast, and joyful to use. |
| Be opinionated, not dictatorial | Enforce good practices, but allow flexibility. |
| Measure ROI | Track time to PR, onboarding, reuse, security. |
| Treat platform as a product | Use product management practices. |
| Involve developers early | Listen, co-design, and iterate. |
Special thanks to:
- Terja Shadri, Assistant Director of Cloud Platforms, EY
- Mike Bizard, Chief Content Officer, TechStrong Group
- Sharon Florentine, Managing Editor, TechStrong Group
For their expert insights on Platform Engineering, developer experience, security, and future trends.