The Communication Blueprint Every Platform Engineering Team Needs
How poor communication can undermine your Platform Engineering efforts
Inspired by an excellent article on the relevance of blogs for platform engineering teams by my long-time friend, Ben Neise, I wanted to share my thoughts on how a team blog fits into a comprehensive communications strategy for such teams.
I’ve had the opportunity to work with platform engineering teams from across the industry and, in my experience, if you don’t have a plan for how your team will communicate with others, you’re going to fail.
There are some reasons for this:
Customer centricity is a core tenet of platform engineering. Your success is measured not only on what capabilities your team provides, but how they execute them.
Your comms plan includes the outcomes you would like to see. This is an important part of explaining its importance to your team. It will likely include building awareness of capability, growing user adoption, maintaining user satisfaction, reducing support tickets, and avoiding fallout after changes.
The act of communicating is often more important than the content of the communication. In busy enterprise environments, it’s surprisingly easy to forget how great a team is, or if they still exist, unless you’re receiving regular signals of momentum.
Communication is needed at all levels, whether that is to demonstrate value to leadership, reassure other teams that changes you make can be positive for them, or simply to ensure your customers know about the latest new feature or an important upcoming change.
Communication doesn’t necessarily come naturally to everyone. Many engineers may feel uncomfortable with the premise that they must “serve” customers. As a leader, you must empower your team and help them navigate a potentially large personal change in culture.
In this article, I’ll outline the communication channels that I’ve seen and how the most innovative, mature, and highly successful teams employ them.
The Communications Blueprint
1. Product Website
A simple, one-page product website could be the single best improvement you make for the visibility of your team. With a friendly URL, it acts as an attractive landing zone for both new and existing platform users. Engineers often shy away from sales or marketing, but the truth is that in their own lives, they’ll quickly judge the quality of a product based on the vendors’ website.
Your product website should be visually attractive and only needs to answer three simple questions: “what problem does the product solve?”, “What benefits can developers expect?”, and “Where can they find out more?”.
I should stress that your product website needs to be visually attractive - your goal is to provide prospective users a level of polish that they expect from external companies. You don’t need to be a professional web design either; there are plenty of templates available for as little as $10 that you can customize to your needs. Also, your product webpage shouldn’t change much because it’s purpose is to simply be a landing zone for users, where they can follow links to find the information they need.
2. Team Blog
As per the post that inspired this article, creating a blog for your platform engineering team is an excellent way to share additional detail or context with your user base.
Blog posts are incredibly practical. You’ll often be limited in how much you can share on other mediums like email or Slack, but blog posts provide a practical way to share detailed information, engaging users with diagrams, screenshots, or videos. They can also be updated with clarifications and FAQs, enhancing user engagement and transparency.
Blog posts are also brilliant for user engagement. There’s huge value to be had in using your team blog to give users a “look behind the curtain”, as to how your team or platform operates. There’s so many great benefits to doing this! The more knowledgable users become about your platform, the more likely they are to become advocates of it. Your engineers also get an opportunity to practice outreach in safe environment before tackling the more daunting task of presenting at conferences. And, by demonstrating some transparency, you build trust and loyalty with users which can be vital come the day that you have outage.
3. Health Dashboard
I’m always disappointed by both the lack and quality of most product health dashboards. When a user experiences a problem with your product, your duty is to minimize their frustration and fix their problem as quickly as you can. The quickest way to infuriate a user is to not respond to their pleas for help. Of course, if you have an outage affecting all users, it’s unreasonable to assume that you’ll somehow be able to help everyone independently.
A health dashboard gives users a fast, convenient way of working out if a problem is already known about, and if so, get progress updates towards its resolution. It gives your team an ability to communicate with everyone in an efficient manner. Users are generally much more forgiving if they know what the problem is, that someone is looking at it, and they know when they can expect a further update.
Users need to able to trust the dashboard though. If the platform is known to be having a problem and the dashboard is all green, then nobody will look at it ever again. Likewise, if problems are reported but then no fix is ever posted, it leaves users with an uneasy feeling about the quality of the platform.
It’s worth noting that new, prospective users will often look at a health dashboard to determine how reliable a platform is. Of course, they’ll be interested to see if you’ve had any big outages, but also in how you handled such events. There are plenty of examples where vendors have been applauded after a major incident, rather than chastised, simply because they were open, honest and timely in their updates.
4. Documentation
I believe that great documentation is the secret to a well-run business. Whilst many teams might see it as a necessary evil, I believe the art of intentionally recording your knowledge is one of the most selfless and positive change you can make in a team.
Well written documentation is unfortunately rare to find out in the field; it’s either a handful of pages hidden in a darkened corner, or an absolute glut of poorly organised pages of outdated technical instructions that assume you already know everything.
The issue is that documentation tends to be written from the perspective of the author, not the reader. Like any good product, Great documentation is user-centric, organized around the user’s journey, with a clear ‘Getting Started’ guide that demonstrates how a simple use case is ludicrously easy to accomplish and a comprehensive ‘Knowledge Base’ giving the user confidence that there is support available for more challenging applications.
5. Email Updates
Emails are universally hated, but they remain one of the most efficient mediums for communicating asynchronously across a large number of people. Most people have overflowing inboxes, so email updates are best kept for non-urgent, fairly infrequent updates - I’d suggest monthly at most.
Unlike some of the other mediums in this article where users are seeking information, email updates are a team’s opportunity to initiate comms with users. They are a phenomenal way of signposting that your team have been hard at work, adding features and fixing bugs. Bear in mind, however, that people on average spend just 3-5 seconds skimming the content of an email before deciding if they should bin it. You can greatly improve your chances by using nicely formatted html - as always, there are templates available for as little as $10 you can tailor to your needs.
That said, it’s not actually important if people read your email update. Its primary purpose is simply to remind people that you exist and you’re moving forward. As a company director once explained to me as a young engineer, “communicating change is as important as the change itself”. He added, “if people don’t see evidence of movement, they assume stagnation”. Wise words that I’ve passed on to every business I’ve worked with over the past five years.
6. Messaging / Chat
Messaging or chat systems like Slack or Teams are now ubiquitous across the business world. Indeed, it’s not uncommon to find both within a single organization, although that could change if the EU have their way. My advice would be that it is vital that your team is present wherever your user base is - even if that’s not your platform of choice.
Chat is a fantastic way of building a relationship with your users. Unfortunately, it’s just as easy to permanently ruin any credibility you’ve built up. There are few golden rules I advise teams to follow:
Chat moves quickly, your team should aim to answer queries within 30-60 minutes. It’s a very bad look if various people are chatting in realtime about your product and your team are nowhere to be seen.
Chat should be thought of as a “public” customer service platform. I strongly encourage platform teams to have a separate “internal” channel where they can discuss and debate topics. A user should never see two engineers debating with one another - they both lose credibility.
It’s often tempting to solve matters in private, but engineers should always update the chat platform with the outcome. Not only does this help users find solutions in future searches for similar problems, but any prospective users visiting the channel will see things being followed up. Seeing a problem reported and then no solution is not a good look.
Chat is great for adhoc queries, but anything bigger should be tracked in issue management software. Nobody likes to be told to “open a ticket”, so ensure your engineers can do this on behalf of the user.
Conclusion
In conclusion, effective communication is a cornerstone of successful platform engineering teams. By leveraging a combination of these communication channels, teams can ensure they are not only delivering valuable capabilities but also maintaining strong relationships with their users. Each communication channel plays a unique role in building awareness, fostering user adoption, and ensuring ongoing satisfaction. By adopting a customer-centric approach and empowering team members to communicate effectively, platform engineering teams can build trust, demonstrate transparency, and ultimately achieve greater success in their initiatives. Remember, in the messy world of enterprise environments, it’s not just about the changes you implement but also about how well you communicate those changes that truly drives your team forward.