I’ve killed two platform initiatives and successfully launched one. The difference between success and failure wasn’t technical—it was brutal honesty about why we were building it and what success looked like.
Your post deserves a CTO perspective because these decisions ultimately land on our desks, and I want to share what I’ve learned from both sides of the pivot-or-wind-down decision.
The Three Platform Experiences
Failed Attempt #1 (Microsoft, 2015): Eight infrastructure engineers, no PM, no UX researcher. Built what they thought was technically impressive. 5% adoption after 12 months. Wound down.
Failed Attempt #2 (Startup, 2019): Six SREs, technical excellence, developer-hostile UX. Kubernetes expertise through the roof, but developers preferred Heroku even though it cost 3x more. Killed after 18 months.
Successful Launch (Current company, 2024): Four infrastructure engineers, two product managers, one part-time UX researcher. 80% voluntary adoption in 12 months. ROI positive within 6 months.
The difference? Not the technology. Not the budget. Not even the talent level.
The difference: We treated it as a product with customers, not as an infrastructure project with users.
The Strategic Mistakes That Kill Platforms
Looking at your situation, I see four strategic failures that go beyond the tactical mistakes you’ve already identified:
1. Problem Definition Was Wrong
You said you were building an “internal developer platform.” But why? What specific, measurable problem were you solving?
In my failed attempts, the answer was always vague: “Modernize our infrastructure.” “Improve developer productivity.” “Reduce toil.”
In my successful attempt, it was specific: “Reduce time from git push to production from 4 hours to under 30 minutes for our top 3 services, which account for 80% of deploys.”
See the difference? One is a vision. The other is a problem with a measurable outcome.
2. No Clear Success Criteria Upfront
I’m willing to bet that when you pitched this to leadership 18 months ago, the business case was something like:
- Platform team: $2M/year
- Expected benefits: “Improved developer productivity,” “Faster time to market,” “Reduced infrastructure costs”
- Timeline: 12-18 months to “full platform”
- Success metric: “Adoption” or “Feature completeness”
Am I close?
Here’s what the pitch should have been:
- Platform team: $2M/year (6 people)
- Specific problem: Deployments take 4 hours, blocking 40 developers × 4 hours/week = 160 hours/week wasted
- Target: Reduce deployment time to <30 minutes within 8 weeks for ONE service
- Success criteria:
- Time saved: 150+ hours/week within 3 months
- Voluntary adoption: 60% of teams within 6 months
- Developer satisfaction: NPS >7 within 6 months
- Cost-benefit: Save 150 hours × $100/hour = $15K/week = $780K/year. ROI positive in 15 months.
With specific success criteria, you can make a pivot-or-kill decision based on data, not sunk cost fallacy.
3. Team Composition Was Infrastructure-Only
“Staffed entirely with infrastructure engineers”—this is the single biggest predictor of platform failure I’ve seen.
It’s not that infrastructure engineers can’t build platforms. It’s that building a platform is 70% product management and 30% infrastructure.
You need:
- Product managers who treat internal developers as customers
- UX researchers who understand developer workflows
- Technical writers who create usable documentation
- DevEx engineers who think about user experience, not just technical architecture
Without product discipline, you get technically impressive things nobody wants to use.
4. Timeline Screamed “Big Bang”
18 months to ship anything useful. That timeline itself was a red flag.
Successful platforms ship value every 4-6 weeks. They start with one team, one workflow, one pain point. They prove value, gather feedback, iterate, expand.
An 18-month timeline says: “We’re building everything before we validate anything.” That’s not a platform strategy. That’s a bet. And based on the 60-70% failure rate, it’s a bad bet.
The Uncomfortable Truth
Most platform failures aren’t technical failures. They’re product failures disguised as engineering projects.
You had the budget. You had the talent. You had leadership support. What you didn’t have:
- Someone asking: “What customer problem are we solving?”
- Someone measuring: “How do we know when we’ve solved it?”
- Someone with the courage to say: “This isn’t working. We need to pivot.”
That last one is what separates good leaders from stubborn ones.
Pivot or Wind Down: The Decision Framework
You asked for advice. Here’s the framework I use:
Vote PIVOT if:
Leadership is genuinely supportive (not just avoiding admitting failure)
Platform team isn’t completely burned out
You can identify ONE specific developer pain point with measurable impact
You’re willing to hire/develop product management capacity
You can commit to 6-week MVP with clear success/fail criteria
Developer trust isn’t irreparably broken
Vote WIND DOWN if:
Leadership support is just sunk cost fallacy
Team is demoralized and burned out
Developers have lost trust (“they promised solutions before”)
You can’t articulate one clear pain point to solve
Organization isn’t ready to treat platform as product
The $2M would create more value elsewhere
My Recommendation: Conditional Pivot
Based on your post, here’s what I’d do:
Recommendation: Pivot with a 6-week experiment and a kill switch.
The Pitch to Leadership:
“We’ve invested $2M and 18 months in a comprehensive platform that has 10% adoption. We can either wind it down now and redeploy the team, or we can try a focused 6-week pivot to solve one specific problem. If the pivot works, we’ll know by Week 8. If it doesn’t, we wind down with clear lessons learned. Either way, we make a decision based on data in 8 weeks, not 8 months.”
The 6-Week Pivot Plan:
- Week 0: Hire product manager (ex-engineer with product experience)
- Week 1: Developer interviews to find #1 pain point
- Weeks 2-5: Build minimum solution to that ONE pain point
- Week 6: Ship to 1-2 volunteer teams (not mandated)
- Weeks 7-8: Measure:
- Are they still using it without reminders?
- Has it measurably reduced time/pain?
- Would they recommend it to other teams? (NPS)
Success criteria:
- Time saved: >50% reduction in that workflow
- Voluntary usage: Both pilot teams use it without mandate
- NPS: >7/10 from pilot teams
If success criteria met: Expand to 2 more teams. Repeat.
If criteria not met: Wind down, redeploy team, document lessons learned.
The Hardest Part of Your Job Right Now
As the leader who greenlit this, you now have the hardest conversation ahead: Do you pivot or wind down?
Both are valid options. Both require courage.
Pivoting requires:
- Admitting the current approach failed
- Convincing leadership to invest more in a new direction
- Getting the team to believe in a different approach
- Actually changing behavior (not just saying you’ll change)
Winding down requires:
- Admitting the investment didn’t pan out
- Having the difficult conversations with the team about what’s next
- Extracting and sharing the lessons learned
- Moving on without the sunk cost fallacy
Either way, the worst option is to keep doing what you’ve been doing and hope for different results.
Air Cover and Execution
If you choose to pivot, your job as the leader changes:
Protect the team from scope creep. Say NO to “while you’re at it…” requests.
Manage executive expectations. Frame this as a high-confidence experiment, not a guaranteed success.
Celebrate learning over delivery. If you learn this approach doesn’t work, that’s success too.
Shield from politics. Platform team needs psychological safety to try something radically different.
The team will execute the pivot. Your job is to give them the air cover to do it without interference, second-guessing, or scope creep.
The Question That Matters
You asked: “What would you do?”
I’d pivot. But with three conditions:
- Hire a product manager immediately. Not eventually. Now.
- Commit to 6-week experiment with clear kill criteria. No moving the goalposts.
- Get real about what ONE problem you’re solving. Not a platform. One workflow.
If you can’t meet those three conditions, wind it down. The half-measures won’t work.
Final Thought
You wrote: “I’m having hard conversations with leadership now about whether to pivot or wind down.”
That sentence tells me you’re already ahead of most leaders in this position. You’re asking the hard questions. You’re not doubling down on failure. You’re seeking input.
That’s leadership.
Regardless of whether you pivot or wind down, you’ve already done the hardest part: admitting the current approach isn’t working and being willing to change course.
What’s the ONE developer workflow that’s the most painful at your company today? If you can answer that in one sentence, you have a shot at a successful pivot. If you can’t, wind it down and redeploy the team to something with clearer value.
Either way, I’m rooting for you. Please report back in 6-8 weeks with what you learned.