Where are you using WebAssembly?
Wasm promises to let developers build once and run anywhere. Are you using it yet?
At work, for production apps
At work, but not for production apps
I don’t use WebAssembly but expect to when the technology matures
I have no plans to use WebAssembly
No plans and I get mad whenever I see the buzzword
DevOps / Platform Engineering / Software Development

The Art of Platform Marketing: You’ve Gotta Sell It

One of the most important parts of a platform engineering strategy is one often overlooked. Take lessons from sales to boost adoption
Jun 6th, 2023 6:05am by
Featued image for: The Art of Platform Marketing: You’ve Gotta Sell It

“How do we get developers to actually use our platform?”

This is a question I’m often asked. A good first step is to make sure you take a product management approach and build an app platform that developers actually want to use, making sure that the golden path to production is not only useful but, well, fun. However, there is a second step that is often overlooked and misunderstood by platform teams: good, old-fashioned marketing. Once you have your platform set up, you have to build up what is essentially a full marketing plan to drive interest in and use of that platform. This includes not only brand, messaging and positioning and campaigns for outreach, but also platform advocacy.

What Platform Marketing Does

Platform marketing is used to drive awareness, trust and interest, but it also gives you an opportunity to get product management feedback about your platform. That last part is one of the underappreciated parts of advocacy (or “developer relations” as it’s sometimes called). When you’re developing in a product mindset, as most platform teams do, you’ll appreciate as much feedback as you can get from your customers — your developers. When infrastructure teams tell me they’ve built a platform or a Kubernetes cloud for developers but that developers aren’t using it, it’s usually because they need to do much more platform marketing.

Marketing doesn’t come easy to infrastructure people. It’s an off-putting word, perhaps only rivaled by “enterprise sales rep.” As ever with eye-roll-inducing phrases, what people actually dislike is bad, boring and useless marketing. At large organizations, most of the successful platform teams I talk with pay close attention to marketing, to good marketing. The likes of Mercedes-Benz, JPMorgan Chase, Duke Energy, The Home Depot, BT, the U.S. Air Force and Army and many others start their platform marketing plans from day one. And, in fact, marketing is a key part of scaling and sustaining how these organizations improve the way they make software.

I’ll be covering platform marketing as one of the “7 lessons from 7 years of running platforms” in my upcoming talk at PlatformCon, being held June 8 and 9. In the meantime, here’s a preview of one of those seven lessons: marketing and advocacy.


“Do you have a T-shirt yet?” my colleague DaShaun Carter likes to ask platform teams. This can seem like a flippant question, but it gets to an important part of platform marketing: establishing a brand. You need a name for your platform and the philosophy of software it supports. For example, the U.S. Air Force uses the brand Kessel Run, and JPMorgan Chase has the Gaia brand.

A brand performs two functions.

First, it creates an identity and a definition of what exactly your platform is. People tend to identify with the tools they use. They’re Java developers, Rust developers, Linux administrators, they follow XP or they’re site reliability engineers (SREs) instead of “DevOps engineers,” and so forth. That identity creates affinity and attraction to the brand — in this case, your platform. In doing so, it creates a certain joy in using the platforms and a passion for the platform.

Second, a brand helps define what your unique methodology and philosophy is. No matter if you’re doing agile, following DevOps principles, practicing SRE or sorting out what “platform engineering” means this quarter, you’ll need to adapt those methodologies to your organization’s unique needs. The sages of these methodologies aren’t so fond of cafeteria DevOps, where you just pick and choose the practices you want to use. However, in many large organizations, to get better, you need to make compromises and adapt stringent methodology principles.

Using your own name helps you take ownership of the methodology you’re putting together and change it as you learn what works. It’s a good time saver too. As one executive told me on a long elevator ride a few years back, don’t ever use the word “agile” when you’re doing agile. The first thing that’ll happen is that someone will start complaining that you’re not doing real agile, that you’re doing it wrong. And then you get stuck in the narcissism of a small-differences black hole instead of just getting on with the work.

The Book

You’re certainly going to need a manual, training, documentation and the usual three-ring binder material. But you’ll also want to write up the thinking that’s behind the brand. You need to codify and distribute your intentions, goals and principles. This is something more tactical, more usable than vision and strategy.

The exact content of The Book will vary, so it’s good to look at examples for inspiration. While it’s just a narrow slice of what would be in The Book, the UK Digital Service has a great list of design principles. You can see how we think about software at VMware Tanzu Labs in things like our FAQ and books like “Radically Collaborative Patterns for Software Makers.”

As you scale your platform to hundreds, then thousands of developers, this ongoing documentation of your thinking will be critical. It’s more than just tech documentation, it’s documenting the culture that your platform is built to support. This book will also help the platform team remember the point of the platform and their work as well. For example, to get the organization focused on building well-designed software, using lean-design techniques, deploying weekly, etc.

Platform Advocacy

Finally, the successful platform teams I talk with have very active platform advocacy. This means having at least one person working full time to just talk with, work with and listen to the people who use your platforms, usually developers. The role of “developer advocate” is pretty well understood by us vendors and cloud providers. Developer advocates love talking to people, and we also love talking about our craft. This means you can find out how it’s done easily by just asking us.

You’ll probably start with just one platform advocate who visits with developer teams throughout your organization listening to what these teams do, teaching them how to use the platform and associated methodologies and listening to their feedback. The advocate acts as a spreader of your platform, a booster and an explainer. Also, often overlooked, the advocate takes feedback from developers and others back to the platform team. They advocate for both the platform team and for the platform users.

As your platform and overall software transformation scale, you’ll add more advocates. Like JPMorgan Chase, you might even have a whole team of platform advocates. The Cloud Foundry platform team at Mercedes-Benz provides training, systematic feedback collection, quarterly community updates and numerous other community management functions that you’d expect an advocate to help with.

One of the common, maybe required, practices the advocacy team follows is holding quarterly internal conferences. These are actual, in-person conferences, often rotating through different regions and office locations with an online component. At these conferences, your platform team and executive sponsors talk a little bit about the platform, but you mostly get your customers — developer teams — to present and talk about the projects they’ve worked on. This serves two functions: training and, that’s right, marketing.

The marketing you’re taking advantage of at internal conferences is the most coveted of all marketing treasures: word of mouth. Having developers tell other developers that your platform is good, great even, will be the best way to get developers to use your platform, and use it well.

Start Platform Marketing on Day One

In addition to those important aspects of platform marketing, you’ll also need to do some marketing fundamentals, like producing content and documentation and working with product management to understand your customers and go to where they are, so to speak.

I haven’t seen many platform teams (or any, perhaps) that have scaled and sustained their developer platform without platform marketing. You’ve got to start thinking about marketing from day one, assigning at least one full-time advocate to start that work of creating a brand name and documenting your ongoing platform philosophy and principles. As with developer advocacy, you don’t need to spend time reinventing the wheel: Tech marketing is a well-understood set of practices. The trick is to actually do it.

If you want to hear the other six lessons of scaling and sustaining platforms in large organizations, check out my full talk at PlatformCon, ”7 lessons from 7 years of running platforms.”

Free ebook: Platform Engineering: What you need to know now

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Pragma.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.