Each customer is important
One key principle of platform engineering is to optimize for your customers. Think of developers as your primary customer and focus on their needs first when deciding what development paths you want to pave and what capabilities you want to grow. Developers all use different tools to get their work done. As a first step, start small and evaluate whether you can improve existing screens and surfaces before implementing a brand new internal developer platform.
Empower developers with a customer-centric internal platform
Thinking about developers as the primary customer for your internal developer platform is essential to its success. We refer to developers as customers. Customers can be any member of what the Team Topologies model refers to as stream-aligned teams – inclusive of roles like machine learning professionals or data scientists.
A successful platform engineering practice empowers developers and operators. Developers and operators have autonomy to make decisions that deliver business value, while still adhering to established standards, governance, and security rules. Critical stakeholders, enabling teams, and experts in specific subsystems (operations, security, compliance, and architecture) work with the team building this internal platform to codify their expertise and best practices into templates and system capabilities. Moving this knowledge into a system simultaneously reduces cognitive load for developers, improves security, compliance, and quality, and better scales these other roles to tackle truly unique problems. However, it's the developer experience that ensures that your platform returns the most benefit for everyone involved.
This means following a customer-centric approach to planning and prioritizing your platform engineering efforts.
Identify optimal development paths to streamline best practices
While your organization might have various different development paths to production today, an early step in your platform engineering journey is to understand which paths you want developers to use. Making this call is important since it allows you to focus your energy on paving an efficient path through them that still meets development, operations, and governance requirements.
These paved paths represent a particular set of development and observability tools, languages, SDKs, and services that are shaped to fit what development, operations, and other stakeholders agree to as representing their best practices. Paved paths should include approaches to streamline on-boarding, moderation, and advocacy for internal reuse. You don't need to think of these paved paths as being restrictive or forced but rather reducing developer toil to the point development teams want to stay within them.
However, the trick is to understand not only which paths to focus on, but which parts of the path need to be paved first.
Meet users where they are
While it can be tempting to start with a unified portal for everything in your internal developer platform, this isn't the best starting point.
Your operations professionals, site reliability engineers (SREs), and developers all use different tools to get their work done. Coding happens in an IDE, engineering systems like GitHub and Azure DevOps use command-line interfaces, and real-time collaboration happens in Teams and Slack. Often these users are happy with these screens and are wary of yet another user interface to worry about.
Start small and evaluate whether you can improve your existing screens and surfaces. Build plugins or extensions before you start building new custom experiences. Ask yourself, will people react better to another new user experience or an improved version of something you have now? If you do decide to build a portal from scratch to start, factor in the idea that you'll likely want to support more than one interface through an API. This also unlocks options like using low-code frameworks so you don’t have to build and host a portal experience from scratch.