Platform Engineering Assessment
Phase 1: Platform Capabilities Inventory
- Catalog current platform capabilities
- Infrastructure provisioning (self-service)
- Application scaffolding / service templates
- CI/CD pipeline templates
- Environment management (create, clone, destroy)
- Secrets management
- Observability stack (logging, metrics, tracing)
- Service catalog / developer portal
- Database provisioning
- API gateway / service mesh
- Cost visibility per team/service
- Identify capabilities that are manual or missing
- Map capabilities to developer journey stages
Capability Maturity Matrix
| Capability | Not Available | Manual/Ticket | Partially Automated | Self-Service | Fully Managed | Current |
|---|---|---|---|---|---|---|
| Infra provisioning | [ ] | [ ] | [ ] | [ ] | [ ] | |
| App scaffolding | [ ] | [ ] | [ ] | [ ] | [ ] | |
| CI/CD | [ ] | [ ] | [ ] | [ ] | [ ] | |
| Environments | [ ] | [ ] | [ ] | [ ] | [ ] | |
| Observability | [ ] | [ ] | [ ] | [ ] | [ ] | |
| Secrets | [ ] | [ ] | [ ] | [ ] | [ ] | |
| Databases | [ ] | [ ] | [ ] | [ ] | [ ] |
Phase 2: Developer Experience Assessment
- Evaluate developer experience
- Time from idea to first deployment (new service)
- Time to onboard a new developer
- Cognitive load on developers (infra knowledge required)
- Number of tools developers must interact with
- Documentation quality and discoverability
- Developer satisfaction scores (survey)
- Identify top developer pain points
- Measure self-service adoption rate
Developer Experience Metrics
| Metric | Current | Target | Industry Benchmark |
|---|---|---|---|
| New service time-to-deploy | days | < 1 day | Hours |
| Developer onboarding time | days | < 5 days | 1 week |
| Tools to learn | count | < 5 | 3-5 |
| Self-service adoption | % | > 80% | 70%+ |
| Developer satisfaction (NPS) | > 30 | 20-40 |
Phase 3: Golden Paths & Standards
- Evaluate golden paths (paved roads)
- Standardized service templates exist
- Templates cover common architectures (API, worker, frontend)
- Templates include CI/CD, monitoring, security by default
- Templates are maintained and updated regularly
- Deviation from golden path is possible but requires justification
- Inner-source contribution model for templates
- Assess standardization vs. flexibility balance
Phase 4: Platform Team Assessment
- Evaluate platform team structure and practices
- Dedicated platform team exists
- Team treats platform as a product (product management, roadmap)
- User research conducted with internal developers
- Platform backlog prioritized by developer impact
- Platform SLOs defined and tracked
- On-call rotation for platform services
- Platform team size appropriate (1 platform engineer per 10-15 developers)
- Assess platform team skills and capacity
Phase 5: Adoption & Impact Metrics
- Measure platform adoption and impact
- Percentage of services using platform capabilities
- Deployment frequency (platform users vs. non-users)
- Lead time improvement from platform adoption
- Incident rate (platform vs. non-platform services)
- Developer time saved per week
- Cost efficiency improvements
- Identify barriers to adoption
Platform Impact Dashboard
| Metric | Platform Users | Non-Platform Users | Improvement |
|---|---|---|---|
| Deploy frequency | /week | /week | x |
| Lead time | hours | hours | x |
| Change failure rate | % | % | -% |
| MTTR | min | min | -% |
Phase 6: Improvement Roadmap
- Prioritize platform improvements by developer impact
- Plan capability buildout sequence
- Define adoption targets and timeline
- Plan team growth and skill development
- Establish platform product management practices
Counter-Rationalizations
| Shortcut | Counter | Why |
|---|---|---|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |
Output Format
- Capability Inventory: Current platform capabilities and gaps
- Developer Experience Report: Pain points and satisfaction metrics
- Golden Path Assessment: Template coverage and quality
- Adoption Metrics: Usage and impact data
- Platform Roadmap: Prioritized improvement plan
Action Items
- Catalog all current platform capabilities
- Survey developers on pain points and satisfaction
- Measure key developer experience metrics
- Assess golden path coverage and quality
- Identify highest-impact platform improvements
- Develop phased platform roadmap
- Establish platform product management practices