How-to: 10 real-life Tips to make your Internal Platform successful

Platform Engineering, internal developer platforms and cloud foundation platforms have been trending in the past years.

Platform engineering refers to the design, development, and maintenance of internal platforms aimed at scaling expertise and best practices within an organization. These platforms often aim to provide self-service capabilities to developers, while also enforcing governance and compliance requirements. The goal is to accelerate application development and relieve developers from cumbersome ticketing flows and governance overhead.

We see organizations investing significant amounts of resources into building different types of internal platforms.

However, they are often built for early adopters and don’t cross the chasm to serve a large “mainstream” user base within an organization.

The following 10 points help you to change that and drive adoption of your platform past the chasm from cloud-natives to cloud newbies.

1) Nail your mission

Be clear about what you are aiming to achieve. Write it down and tell people in your organization and beyond, over and over again (more than you think). To come up with a great mission it helps to have these three things clear:

• A detailed understanding of the main challenge you are looking to solve
• A target state you aspire to
• Guiding Principles that will help take decisions

2) Establish a platform team

This sounds like a no-brainer, but often times the nature of a team is not clearly defined. In these cases building an internal platform might just be a “nice-to-have” feature. If this happens you’ll most probably not reach your ambition.

A platform team should be defined as such. It is their goal to build a product and their interaction model with internal customers is an API or a self-service portal. Like a startup they have to deliver value in order to generate demand for the service they are offering. For a reference you can check team topologies. The counterpart of a platform team would be an enabling team. An enabling team facilitates processes like cloud migration, usually on case-to-case basis.

Looking at Cloud Centers of Excellences, both, enabling teams and platform teams have been established. However, only the latter will be able to scale with rising cloud adoption.

3) Obsess over your customers

Yes, you might be building a self-service portal or an API in order to make sure you do not have to serve every of your customers individually. BUT, that doesn’t mean you shouldn’t talk to them anyways. This might be straight-forward, but it still goes wrong many times. Not because platform teams forget about their customers, but because they assume that they think and feel like them, even though this is not the case.

As an internal platform team it’s crucial that you know, who your customers are, what they want to achieve, what their pains are and how they feel and think about your platform.

User research and customer interviews in the beginning are a great start to get this going, but don’t stop there. Or you might risk to only consider the early adopters, but not the cloud newbies.

Aim to continuously collect feedback from your customers to understand and solve their pains. This doesn’t mean you have to build what they tell you. You might as well be able to come up with better ideas, but you need to understand how they work and make the right design choices to bring your platform to success.

4) Get C-level approval

Building an internal platform may not have been on your C-suites radar until now. If you want it to succeed, you should make sure that it gets there better sooner than later. To achieve that here are 3 things you can do.

• Leverage external, objective sources for argumentation. For your internal platform the CNCF’s platform whitepaper can be helpful for making the case of a platform or the Cloud Foundation Maturity Model for an overview of capabilities a Cloud Foundation Platform can cover.
• Have a well-connected champion, someone that knows his/her way around the organization, not an external person, not a new person.
• Explain how your platform impacts your organizations security posture (if it does) and operational costs.
• Show don’t tell. Whenever you can be as specific as possible. Showing a clickable prototype will be much more powerful than a vague Powerpoint slide.

5) Choose an easy use case to start

Don’t try to demonstrate the feasibility of your platform with the most complex scenario that is on your mind. As an engineer, you might feel the urge to proof that it works. But it will make your life much harder. It will take longer and you’ll receive your first feedback from real users too late.

That’s why we recommend to start with an easy use case and address the people that can leverage that. With their feedback you can iterate and bring your internal platform to the next level.

To give you an example: Landing Zones

When building Landing Zones you probably will consider different networking models, varying from sandbox environments to hybrid setups with on-premise connectivity.

6) Choose the right level of abstraction

One of the reasons for building an internal platform is that you want to abstract complexity away. As an expert of your field, it can be hard though to choose the right level of abstraction.

Too much flexibility can be overwhelming and won’t deliver value. Too much abstraction will feel like a cage to them and not cover their requirements. You need an in-depth understanding of your customers, their goals and their challenges in order to provide them with the right product.

In that context, we often speak of golden paths in platform building. They are recommended “routes to success” for popular user journeys.

Choose the user group you are building the golden path for. One way to do that is to just choose the user group that is the majority of your internal customers. Alternatively (and often superior) you can go for a group that is strategic to your mission. In cloud these could be cloud-native users in an IT organization where the majority of workloads are still based on traditional IaaS deployments, but cloud-native is what you are aiming for in the future.

Identify their most popular user flows and define a route to success. A frequently chosen pattern in Cloud Foundation Platforms is to provide native access to a cloud environment (e.g. Azure subscription), with a pre-configured vnet service. Users won’t have to go through all the networking options the providers offer. You take away that heavy lifting for them and give them a proven path to success.

7) Iterate and learn

Don’t fall into the trap of waterfall planning. Come up with MVPs and get feedback from your internal customers as early as possible. Iteration even works for strategies. Keep your strategy as a living document that is allowed to evolve over time.

8) Build a brand

You are engineers, not marketeers. And still, it helps enormously to build a brand for your internal platform. Here’s how:

1. Give it a good name that is easy to understand and to remember.
2. Get a logo (Your communications department, might actually be happy to get the chance to design it.).
3. Order some swag to give away and give it to your first users.
4. Get out of the building and tell your story at MeetUps, conferences and other opportunities. It changes the way your platform is seen internally as well, you will see.

9) Build a community

Giving your users a voice and letting them talk to each other has great multiplying effects. You can do this by hosting regular internal community calls. It’s fine if only 5-10 people join in the beginning. They will appreciate the treatment. You can also leverage existing formats your organization already has, like newsletters or podcasts. Bring some of your early adopters in and let them share their story and you’ll see it’s even better than when you doing it.

Next level: While a bit more effort, gamification is a great lever to drive engagement within a striving community. Quizzes or awards for good practices drive adoption and let people belong to your mission.

10) Think about Day 2, 3.. 50

Yes, point 5 was to start with an easy use case. Nevertheless, it’s important that you also think about more advanced use cases and requirements that may come up in the future, even if you’ll only implement them later in time.

Our modular landing zones (instead of one monolithic landing zone) are a great example of this. For your early cloud use cases a generic baseline might be enough. Early adopter cloud teams will know what they are doing in the cloud anyways. However, the more people adopt the cloud, the more their use cases vary and in the end you want to enable them all. Modularizing landing zones in order to tailor them to specific use cases, might be a bit more complex in the beginning, but ensures your internal platform withholds the use of different user groups, e.g. teams building container applications, data science teams or traditional IT leveraging IaaS.

We’d love to hear what other initiatives you have kicked of to drive adoption of your internal platforms. Let’s schedule a chat.