Your PLATFORM Is NOT the Main Character

It's a tale as old as technology itself...

A bunch of people were hired to build a system. So we did.

Then we were asked to build another one. So we did that too.

Then a third one was requested. And we built that too...

Somewhere along the way, we realized that we were starting to develop a pretty big infrastructure footprint. It was making increasing demands on our team of folks trying to develop the systems... someone needed to focus on managing the infrastructure. So we hired a bunch of folks to do that.

The writeup requesting the creation of the Platform Team probably mentioned something about "providing the platform as a service that developers could just use, that would accelerate their development work"... a way to abstract all the operating system patching and security configurations and other things that an application developer would think of as a distraction.

Slipping Off the Rails

It was all going well, at first... but over time, the platform team got bogged down in dealing with Security, Compliance, Network, Storage, Building management, Vendors, or any number of other teams that they have to interface with. Gradually, their focus was shifted from the Developer teams they were created to serve.

Before long, the Platform team even forgets to reach out and maintain those feedback loops with Dev. "Eh, we know what they need."

But that's the problem... the Platform doesn't know what the developers need. Those needs are changing with every new task! And the "Developer-centric" focus gets replaced with the "Platform-centric" focus.

But... we're devs too, aren't we?

Yeah you are. But you've got different goals. And when your goals diverge... how will you know? How will you choose the path that best supports the business? When the business asks if you've built for scale, the question will be... "whose scale did we build for?"

And for what it's worth, sometimes the platform folks have actually forgotten that they're developers too. They sink deep into the mentality that "I don't write software. That's what those folks do." (Personally, this is a reason that I tend to try and use the term Builders instead of Developers. It has fewer connotations to it.)

Real Platform Teams Aren't Platform-Centric

How can a Platform team tell that they've lost the plot?

• Tooling decisions get made without input from dev teams. How often do you get input from the people you think should be using what you build?

• Platforms are technically excellent but adoption is slow. "Developers just aren't using what we built!" becomes a common complaint.

• Metrics are infrastructure-focused (uptime, compliance), not outcome-focused (time-to-first-successful-deploy, lead time to change, etc). Do you measure your team in ways that show how your constituents are succeeding?

Key Insight: A technically great platform that no one uses is a failure of product thinking, not of engineering.

Think Like a Product Team

Have you ever thought, “we built this great thing, why aren’t they using it?”

If so... it's ok. It's a common thing to feel like that! Most of us (myself included) came to Platform work by way of the Engineering organization. We were great at supporting the system, and we gradually grew our skills and responsibilities until we caught the attention of the Platform team/manager. We weren't trained to think about Product management.

But think about it from the Product perspective:

If I'm making a product that I intend to sell on the open market, does it make sense to just build it and then hope that it's what customers will need?

Product teams do a ton of market research - they're constantly talking to their customers and prospects about what people need.

So let's think about our Platform from a Product perspective. Your platform has:

• Users (the dev teams you want to adopt it)
• Use cases (speed to deliver, autonomy within the platform)
• Adoption goals

Your platform is a product. So we need to adopt some of those Product skills to make our Platform successful! Here's how you get those wins:

• UX Thinking. Your finely-crafted YAML-based behemoth is worthless if your devs can't use it easily. Are you thinking about what's best for you or what's best for them?

• User Onboarding. Think of it like a "first date"... if that first impression is awful, are you going to get a second date?

• Clear Documentation. Imagine it's your first day in the platform. How do you know what to do? Do you have docs to help you or do you have to spend all day asking questions?

• Empathy, not just enforcement. Yeah, sometimes you have to do things because you have to protect the safety and security of the platform. Sometimes those decisions can make things more difficult for developers. Are you doing what you can to minimize the blast radius of those decisions, or are you just YOLOing your compliance rules into place?

Re-Center on the Developer

The obvious play here is to figure out how to reconnect the Developer feedback loop. But if you're out of practice, it might be tough to prime that pump again. Here are some ideas:

• Spend time watching developers work. Look for what they get stuck on, or what doesn't work right the first time.

• Run internal user interviews and usability studies. Many dev teams have a UX person... maybe you can partner up and learn a few tricks from them?

• Host “Platform Office Hours” or embed team members into product teams periodically.

• Invite a rotating developer to your planning meetings.

• Build trust before you enforce standards. The fastest way to alienate developers is to show up late with a gate instead of early with guidance.

Wrap-up

I'm closing today's post with some questions:

1. When was the last time you observed a dev team using your platform tools?

2. Can a new developer ship something useful in their first day using your platform?

3. Do you measure platform success in developer terms (like ease-of-use, adoption, or reduced toil)?

4. Are dev teams sending you requests — or sending you workarounds?

If the answers make you uncomfortable... you’re not failing. You’re just ready for the next step.