Before we start — the one thing to hold onto
Most teams think they need a platform. They don't. They need fewer obstacles. I've sat in rooms with platform teams who built beautiful internal tools — and product teams who didn't use them because the golden path was harder than the dirt road.
A platform isn't technology. It's a product — and your developers are the customers. If they don't choose to use it, you don't have a platform. You have a museum.
That one idea changes everything. It turns platform engineering from a build exercise into a product discipline.
Keep it in mind.
Purpose
The goal of this workshop is concrete: design internal developer platforms and golden paths that accelerate delivery, improve developer experience (DevEx), and create standardised, secure, observable pathways.
I've seen organisations invest millions in internal platforms that teams worked around — not because the platform was bad, but because nobody asked the developers what they actually needed. This workshop fixes that.
You'll leave with a platform engineering strategy, golden path specifications, and a DevEx baseline.
Who Should Attend
This workshop is designed for the people who build platforms — and the people who suffer when platforms are built wrong.
- VP Engineering, Platform Leads, Engineering Managers
- DevOps and SRE Teams
- Architects and Infrastructure Leaders
Typical team size: 6-12 participants
Format: In-person or virtual (hybrid available)
Try it yourself — The friction audit
Before the workshop, ask a developer on your team: "what's the hardest part about getting your code into production?" Not the technical part. The frustrating part. The part that makes them sigh.
If their answer isn't "writing the code," that's exactly why this workshop exists.
What You'll Achieve
By the end of this workshop, you will have:
- Platform engineering maturity assessment and target state vision
- Golden paths and paved roads definition for teams
- Internal platform product roadmap and governance model
- Developer experience (DevEx) metrics and improvement plan
- Observability-driven development (ODD) integration
- Platform vs product strategy alignment exercises
- Self-service API and UX specifications
- Technical standards and guardrail design
These aren't architecture diagrams. They're product specifications your platform team will actually build.
Typical Outcomes
Immediate outcomes (within 1 week):
- DevEx baseline assessment complete
- Platform team charter and value proposition defined
- Initial set of golden paths identified
Short-term outcomes (within 1 month):
- First golden path (e.g., service creation) delivered
- DevEx metrics dashboard deployed
- Platform team roadmap prioritised and approved
Long-term outcomes (3-6 months):
- Increased developer productivity (measured via DORA metrics)
- Reduced onboarding time for new teams
- Higher deployment frequency with lower failure rate
- Consistent security and compliance across all services
Workshop Structure
Day 1:
- Morning (3 hours): DevEx assessment, pain points, and target state vision
- Afternoon (3 hours): Platform product thinking, team topology, and governance
Day 2:
- Morning (3 hours): Golden paths design workshop (paved roads vs dirt roads)
- Afternoon (3 hours): Integration with CI/CD, security, observability; roadmap creation
Total duration: 2 days
Adjustable: Can be condensed to 1 day for organisations already underway
Try it yourself — The golden path test
Look at your current "standard" way to create a new service. How many steps? How long does it take a new developer? Would you choose it if you had a choice?
Most teams I work with find their golden paths are actually obstacle courses.
Prerequisites & Preparation
Before the workshop:
- Developer experience survey (pain points, bottlenecks, satisfaction)
- Current platform capabilities inventory (what exists today)
- CI/CD, security, and observability tooling documentation
- Team structure and service catalog
Recommended team composition:
- 1 VP Engineering or Engineering Manager
- 2-3 Platform/DevOps Engineers
- 2-3 Software Engineers from product teams (to provide ground truth)
- 1 SRE or Observability specialist
- 1 Security Engineer
- 1 Product Manager (platform as product)
How to know if this landed
You'll know this has landed when someone stops asking "why aren't teams using the platform?" and starts asking "what do teams actually need?" They can explain DevEx metrics in their own words. They understand why golden paths must be better than dirt roads. They treat platform engineering as product development, not infrastructure.
What changes when the mental model clicks
I've run this session with platform teams ranging from startups with zero platform to enterprises with platforms nobody uses. The gap at the start is usually not about engineering quality — it's about not treating developers as customers.
What changes after this workshop:
Teams stop treating platform engineering as an infrastructure problem and start treating it as a product problem. The DevEx assessment tends to be the moment things click — people realise they've been measuring platform success by uptime instead of by developer satisfaction.
The golden paths design tends to immediately change how people think about standards. They start asking "would a developer choose this?" instead of "is this the right way?" Their adoption goes up. Their friction goes down. They stop blaming "developer resistance" when the real problem was that nobody made the right way the easy way.
Book a Workshop
Ready to give your platform team the product mindset they need?
or
2-day strategic design workshop includes DevEx assessment, platform product thinking, golden paths design, team topology mapping, and roadmap creation.