HockeyStick show
HockeyStick Show
Building Better Platforms, with Ajay Chankramath, Sean Alvarez & Nic Cheneweth - HockeyStick #49
0:00
-40:35

Building Better Platforms, with Ajay Chankramath, Sean Alvarez & Nic Cheneweth - HockeyStick #49

Welcome to Episode 49 of The HockeyStick Show! I’m Miko Pawlikowski, and this week I sat down with three platform leaders who’ve lived through the messy, unglamorous reality of building internal platforms that actually help teams ship better software: Ajay Chankramath, Sean Alvarez, and Nic Cheneweth.

We unpacked what platforms really are, why they’re misunderstood, and how good platform work is far more human than technical.


Platforms Aren’t Magic — They’re Just Good Engineering Done at Scale

All three guests pointed out a simple truth: most companies don’t need fancy platform branding, they just need to fix the basics. Shared tooling, stable environments, repeatable patterns — the “boring stuff” is what creates real leverage.

A platform isn’t a product you install. It’s a consistent way of working that reduces chaos and duplication.

Lesson: A platform is not the shiny thing — it’s the reliable thing.
Action: Identify one repeated pain your teams face and solve it once, centrally.


Internal Customers Matter More Than Internal Technology

A theme that came up repeatedly: platform work only succeeds when the platform team treats engineers as customers, not as people who should “just use what we built.”

Ajay talked about how teams often skip discovery and jump straight into building. Sean emphasized empathy. Nic highlighted that many “platform failures” are really product failures — misaligned expectations, poor communication, and unclear value.

Lesson: If no one is using your platform, it’s not a platform — it’s shelfware.
Action: Before building anything new, interview five developers about what they actually need.


Reduce Cognitive Load, Don’t Add to It

Every engineer knows the pain of juggling too many deployment paths, tooling options, and config formats. A good platform reduces cognitive load by removing decisions that shouldn’t matter.

This isn’t about limiting freedom. It’s about letting teams spend their energy on product, not plumbing.

Lesson: The best platform decisions remove decisions.
Action: Pick one workflow today that your team repeats and standardize it.


Developer Experience Is a Business Metric

Nic made a point that stuck with me: no executive wakes up excited about “platform engineering.” They care about throughput, reliability, cost, and time-to-market. A platform only earns its place when it moves those numbers.

You don’t justify platform work with architecture diagrams. You justify it by showing how much faster teams deliver because of it.

Lesson: If you want executive support, speak the language of outcomes.
Action: Track one metric affected by platform friction — and show the before and after.


Platforms Fail When They Become Mandates Instead of Choices

Sean raised this repeatedly: forcing a platform onto teams rarely works. The healthiest platforms are opt-in, because they’re useful enough that teams choose them.

Mandates hide problems. Adoption exposes them.

Lesson: If you have to force adoption, the real issue isn’t adoption — it’s value.
Action: Ask a team why they didn’t choose your platform. Their answer is your roadmap.


Culture Makes or Breaks the Platform

Ajay described how teams often treat platform issues as technical problems, when they’re usually cultural ones: trust, communication, ownership, and the willingness to collaborate across team boundaries.

The best platforms grow in environments where experimentation is allowed, feedback loops are short, and teams feel safe saying “this isn’t working.”

Lesson: A platform is a cultural artifact as much as a technical one.
Action: Start including platform updates in your engineering ceremonies — make it part of the conversation, not an afterthought.


A final thought from me

This conversation reminded me that platforms aren’t about abstraction layers or golden paths or YAML templates. They’re about helping people do their best work without tripping over the infrastructure underneath them.

If you take one thing from this episode: treat platform engineering as a service, not a structure. Talk to your teams, fix the pain that matters, and keep the human side front and center.

Thanks for listening!

Discussion about this episode

User's avatar