![]() |
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
This is the third part of a series. Read also:
New paradigms and technologies succeed partly through the strength of community. We’ve seen this repeatedly, first in the web development world, open source, DevOps and now platform engineering. Communities are valuable to the success of your platform and your business.
The developers using your platform are not just your customers; they form a community that needs nurturing. Part of it is thinking about the portals and documentation for your platform.
Another part is about how you interact with them through events and varied communication channels like chat groups, and general developer relations and advocacy. The most successful platform teams we’ve talked with put a lot of time and thinking into the basics of promoting their platform offerings.
For most operations people, “support” is not a source of daily joy. And, while self-service/ticketless developer support models have improved this process, even the most wonderfully automated platforms still require some support.
When you take care of infrastructure needs and provide sensible defaults for how to package and manage applications, your developers will have more time to explore and stumble on problems higher up the stack. They may have more application development and dev tool questions. They might have questions about how to use and integrate services instead of how to configure them. If you’re lucky, they’ll start asking, “How can we make this application more secure from the start?”
Your platform team may not be equipped to answer all of these questions. And while there are some early stories of generative AI helping, we’ve seen platform teams rely on the internal developer community to help.
One of the platform teams at Mercedes-Benz adopted a familiar community-based support method by using an internal chat application as one of their primary support channels. Making support requests that were typically hidden behind a help desk was intimidating at first, but, as developers started using these semi-public forums, their fellow developers and peers pitched in. Ultimately, the developers preferred this support-by-community-chat method because it’s more human.
In addition to support, there are some standard community management practices that platform teams find useful. Bryan Ross, former colleague and field CTO at GitLab, has a great overview of these practices, showing that community management is a “cornerstone of successful platform engineering teams.” In addition to thinking about support as part of community management, Ross goes over a comprehensive internal community management and communications plan.
The community around your platform is part of its value. It is part of your platform, so the better you manage the community, the better you’ll be managing the platform.
If you want people to use your platform, they need to (1) know it exists, (2) understand what it does and (3) actually want to use it. Internal conferences and a regular speaker series help with all three. They provide structured, recurring opportunities to showcase what the platform does, train developers and ops folks, and build a sense of community.
The goal isn’t to just throw events, that’s just a fun side effect. The goal is to make sure developers understand what’s available, learn best practices and, ideally, share what they’ve built. Showing developers what is possible with your platform is hugely motivating.
Done right, this makes adoption easier, reduces onboarding, retains existing developers and grows their use of the platform, helps attract new developer teams to the platform and helps platform teams stay connected to their users.
Remember that in a Platform as a Product approach, developers are your customers. If they don’t know what’s available, how to use it or what’s coming next, they’ll find workarounds. These conferences and speaker series are a way to keep developers engaged, improve adoption and ensure the platform stays relevant.
There’s a human side to this, too often left out of focusing on “the business value” and outcomes in corporate-land: just having a friendly community of humans who like to spend time with each other and learn.
You don’t need giant, multiday vendor-style conferences. Those are great for different purposes, but expensive, overkill and not effective for what we’re talking about here. The right format for an internal platform community is more like:
Everything should be recorded and stored somewhere accessible. These sessions aren’t just for the live audience — they build a growing library of training material.
Don’t think of these events as just one point in time. Just as with YouTube, you should expect a lot of viewers to come to the sessions afterward. So you need to curate the internal archives of your recorded sessions properly.
Make finding and watching the videos easy. For example, rather than distributing recordings as Zoom meetings that require a password, have an internal web page that allows viewers to just click on a video and watch. Having good titles and brief descriptions of the recordings is a must, and transcripts are handy and improve accessibility overall.
A good event needs a good agenda. If people aren’t interested in the topics, they won’t show up. Here’s what works:
It’s good practice to source speakers from other companies and organizations. For example, you might have developers come in from a different industry to talk about their experience using the platform. Knowing “how other people do it” is valuable and often has more credibility than “how we do it.”
Successful platform teams have active platform advocacy. This requires at least one person working full time to essentially build empathy with your users by working with and listening to the people who use your platforms.
You may start with just one platform advocate who visits with developer teams, listening for feedback while teaching them how to use the platform and associated methodologies. The advocate acts as both a councilor and delegate for your developers. They not only help surface the virtues of your platform, but they also gather feedback from your users to help improve their experience and the platform overall.
At large organizations, 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.
The journey to successful platform adoption is more than just communicating technical prowess. Embracing systematic approaches to platform marketing that include clear messaging and positioning based on customers’ needs and a strong brand ethos is the key to communicating the value of your platform. But it doesn’t stop there. Investing in robust community management through dedicated support channels, engaging events and active platform advocacy fosters a thriving ecosystem where developers feel heard, supported and motivated to use and champion the platform.