Five sales techniques that double platform adoption

Why platform engineers should spend 85% of their time talking, not building

Your platform has been live for eight months. You’ve celebrated progress in weekly standups. You’ve walked the CEO through the architecture. You’ve defended the investment to finance. Yet, developers refuse to give up their rickety Jenkins box.

You’ve built everything the platform engineering playbooks recommend. Golden paths, self-service portals, clear standards. Your team has deep technical expertise. But you can’t convince a single development team to voluntarily migrate.

The problem isn’t your engineering. It’s that nobody taught platform engineers what tech sales teams have known for decades.

There’s a pattern in my conversations with hundreds of platform teams over the past four years. Teams struggling with adoption spend roughly 85% of their time building technical capabilities and 15% talking to users. Teams achieving strong adoption reverse those percentages. Technology is rarely the differentiator.

Why Are Developers So Stubborn?

I’ve lost count of the painful conversations I’ve had about platform adoption.

There seems to be a universal assumption that developers will migrate because the new platform is objectively better. Better architecture, better security, better metrics. The logic seems irrefutable. It’s completely disconnected from reality.

Developers are usually happy with their current solutions.

Sure, it’s probably held together with digital duct tape, but they’ve invested time learning those tools and achieved sufficient skills to make them productive. Your platform represents risk, learning curve, and a painful migration that nobody has time to do it. More fundamentally, developers value autonomy and your platform asks them to surrender control and trust your team.

I watched one large enterprise announce a Q3 migration deadline. Six months later, they had moved 4 of 23 teams … and two of those migrations were teams the platform engineer managed directly.

If you want development teams to adopt your platform, you begin by establishing trust. Listen to them. Be curious, not judgemental, about how they operate. Understand their challenges. Find the pains that would be solved by a better solution. Ask them what would influence a change and what might help make that process more smooth.

Sales is often seen a dirty word in technology teams, but that’s exactly what a good sales discovery session looks like! Deep empathy paired with active listening.

What you need to learn from Sales

You don’t need to become a salesperson, but borrowing a few of their methods will make you dramatically more effective at attracting users to your platform.

Question with structure, not just curiosity. Great discovery follows a pattern called SPIN. Situation (understand their current state), Problem (identify what’s broken), Implication (explore what that problem costs them), Need-payoff (help them articulate why solving it matters). Instead of random questions, you might ask “How do you deploy to production today?” (situation), “What elements are the most brittle in that process?” (problem), “How much time does your team lose when it breaks?” (implication), “What could you achieve if you got those hours back each week?” (need-payoff).

Let them discover the pain, don’t tell them. This is called trap setting, though that sounds more manipulative than it is. You’re asking questions that lead people to realise their current state is untenable. “Walk me through your last production incident. How long to detect? How long to fix? How many people involved? What were they working on before they got pulled in?” By the time they’ve talked through it, they’ve convinced themselves there’s a problem worth fixing - which is far more powerful than you telling them.

Connect technical problems to business impact. Sales teams call this building an implication chain. A development team might not think that their rickety Jenkins server is a big problem. Follow the chain: broken builds → developers wait → context switching → reduced productivity → delayed feature delivery → losing competitive advantage→ loss of revenue. Each link helps establish the context of the problem, it’s business impact, and builds urgency.

Surface objections early. Ask “What concerns you about changing your current setup?” in your first conversation, not your tenth. You’ll hear the real blockers: “We tried something similar before and it failed”, “The team doesn’t have time to migrate”, or “We need to keep our autonomy”. Don’t argue or dismiss - dig deeper. “That previous platform failed - tell me what happened. Was it the technology, the support model, or something else?” If they say “no time to migrate,” that’s actually “I don’t trust the ROI justifies the disruption.” The objection reveals what really matters. Now you’re having the right conversation.

Know what you still don’t know. After each discovery conversation, do a gap analysis. What critical information is missing? Who else needs to be in the conversation? What assumptions need validation? Sales teams track this obsessively because deals die from unknown unknowns. Platform adoptions do too - usually because you didn’t talk to the decision makers, or know about the re-org happening next quarter.

Start With One Conversation

Your first discovery conversation doesn’t need to be perfect. Pick one team next week. Ask about their last production incident. Follow the implication chain. Surface their concerns early. Take notes on what you still don’t know.

That platform team with 4 of 23 migrations after six months? Three months after they started running structured discovery, they hit 18 teams. Same technology. Different approach.

The rickety Jenkins box isn’t your competition. The pain of change is. Discovery helps you understand whether the pain of staying put exceeds the pain of switching. Once you know that, you know whether you have a product worth adopting.