Over the past decade, I have had the opportunity to be involved in several platform developments. All were technology base-platforms in the broadest sense, but different in the details: highly regulated adoption of public cloud platforms as in-house platforms, private cloud platforms in the enterprise environment, and IaaS/PaaS platforms for managed service providers.

I thought about the key takeaways from these journeys and came up with five aspects common to all the environments and types of platforms I was involved with.

The insight came in different ways; sometimes we did the right thing and felt at ease, and other times we tried to do it differently and struggled with the consequences.

#1 the team first

Take the time to build a team that will be responsible not only for initial development but also for ongoing development and operations. It is okay if not all members are involved from the start, but make sure that team members are not involved in other complex areas; building a platform is hard. The team will have to make many decisions and operate differently from the rest of the organization in many ways. Create a low-friction, high-trust environment for progress.

The team should agree on some basic frameworks:

• Decision-making and decision records
  • Document and communicate design principles and strategies, which both influence or even limit options
• Documentation practices

Remember: The initial team composition won’t last too long, the team will change over time, just like the platform.

One important thing that changes as the platform evolves is the mindset required. During initial exploration and an MVP, you need pioneers to enable future success. But soon, as you move towards a product, you need settlers to manage the technical complexity, make the platform scalable, and focus more on the customer. See also: From pioneer to settlers

#2 landing zone as a strong foundation

The first huge milestone should be your platform’s landing zone. With the landing zone as a strong foundation, the platform and the team are well prepared to focus on the first use cases/customers. A rushed focus on the “Focus UseCase” will come back to bite you later. Just to make sure, an initial “Focus UseCase” for the platform is not a bad idea. This typically ensures an adequate budget and the required management attention.

Platform Landing Zone typically includes:

• Networking
• Security
• Policy guardrails
• Account vending
• CI/CD pipelines for the landing zone itself

The day-to-day operations of the landing zone must be minimal and highly automated. Account vending as the first touchpoint should provide a good user experience.

Getting this milestone right gives the team the freedom to take the next steps in the evolution of the platform.

#3 Marketing is crucial

The success of your platform is not measured by the slickest technical solution. You need to attract users / customers and create value for them.

Added value can be, for example:

• Faster delivery
• New possibilities to be more innovative
• Less cognitive load
• Less friction
• Compliance by design

Go to the organization’s offices and talk about the benefits and opportunities of your platform to engage users. A bit of consulting for early adopters can’t hurt either, it helps the company and there’s no better feedback channel.

Another target group for your “marketing” should be the producers of important services. But more on that in the next point.

#4 Producers matter

Offering valuable services on top of your platforms makes the platform itself more valuable (that’s how platforms work). The platform team alone is not able to integrate all the services needed, you need buy-in from the producers of the services your customers need.

That can be a win-win-win:

• Interesting services are offered on your platform, which in turn attracts more users
• The producers of the services can benefit from the advantages of the platform and deliver their services more effectively
• The customers of the platform can continue to focus on their core business and find a consistent experience

Some consulting from the platform team will be necessary to ensure that the integration succeeds with little effort for the producers. But it is worth it.

A recent article by Cat Morris confirmed my personal experience:

When I worked with platform builders, we focused almost entirely on the application teams that consumed platform services. We rapidly became the blocker to those teams, just like the SRE and DevOps teams that came before us. We couldn’t onboard capabilities and features fast enough, meaning we were supporting the old ways while trying to build the new.

Source: https://thenewstack.io/the-missing-piece-in-platform-engineering-recognizing-producers/

#5 Deliver first tangible artifacts quickly

Delivering the first tangible artefacts quickly and iterating in small cycles with rich opportunities for feedback is a common practice in agile frameworks. But there is another, not so well-known, benefit of early results:

It’s good to show your sponsor and stakeholders why it’s worth the investment. This transparency builds trust for your further development. The trust from your stakeholders and sponsors will also result in the intrinsic motivation of your team.

But don’t overthink the first steps, it’s OK if your demo artifact is built on a lot of technical debt. Think of that great-looking picture on the Lego box; you buy it because of it, but the work to build it is still waiting for you.

Creating technical debt for the sake of moving fast is fine, as long as you have a plan to pay it back. Overthinking every corner case and possible problem in your first iterations or releases unnecessarily delays the value of your platform to the business, and also delays the opportunity for customer feedback.