Why do you start a platform engineering team?
Platform engineering is gaining momentum as a response to growing complexity in software development. Over the past decade, DevOps transformed the industry by promoting agility, faster deployments, and greater autonomy. However, as development environments became more complex with microservices, Kubernetes, and cloud resources, developers found themselves burdened with expanded responsibilities, including feature delivery, incident management, and adherence to security and compliance standards.
These increased demands have led to challenges like:
- Lower productivity
- Lack of centralized knowledge
- Declining quality, security, and compliance
- Inefficient onboarding
- Difficulties resolving incident management
Platform engineering is trending because it prioritizes the developer experience, enhances productivity, and ensures high-quality standards. By providing reusable tools, automated infrastructure, and self-service capabilities, platform engineering empowers developers while giving engineering managers better visibility and control. Platform engineering isn’t just about serving developers - there are many other stakeholders that can benefit from the approach from leaders and managers to SREs, architects and product managers.
DevOps has changed the culture of engineering, making developers’ jobs easier by handling CI/CD, automation, IaC, and other infrastructure related tasks. Platform engineering is the next step of this evolution; providing developers with the resources they need so they can do their jobs independently. While DevOps focused on shipping code, platform engineering focuses on the way that shipping this code can be improved.
Gartner predicts that by 2026, 80% of large software engineering organizations will have platform engineering teams, up from 45% in 2022, reflecting its growing importance in modern software development.
How do you start a platform engineering team?
There’s no ‘one right way’ to build a platform engineering team. Some platform engineering teams are built from the ground up, but the majority have renamed their DevOps team to platform engineering or have merged DevOps and SRE to become a platform engineering team.
The key in shaping a platform engineering team is to understand what the existing team structure is and what the current environment is like, as well as unearthing the gaps and bottlenecks that you are hoping for platform engineering to address. Only then can you put together a plan. Many of the skills you’re seeking within this team may already be present in your organization, but others, particularly deep technical expertise, may require you to hire new members for your team. As platform engineering is a relatively new practice - much like the shortage of DevOps engineers when DevOps practices were first introduced - there is a dearth of ‘platform engineers’. And just as many developers or software engineers built up their skill sets to become ‘DevOps engineers’, many DevOps engineers, software engineers and site reliability engineers will be required to learn new skills on-the-job to become ‘platform engineers’.
It’s important, therefore, to consider whether candidates are capable of adapting to new roles, or whether their existing roles and responsibilities are suited to the platform engineering team.
Here are some examples of what a platform team as a whole are responsible for:
- Building and maintaining an internal developer platform and internal developer portal - the two cornerstones of platform engineering
- Using a product management approach - ‘platform as a product’ and ‘portal as a product’
- Driving developer experience, developer productivity and developer satisfaction
- Reducing cognitive load for developers
- Ensuring feedback loops are in place
Platform engineering team key responsibilities and skills
The number one thing is you want to have a team of varied backgrounds. Here are some ideas:
A platform engineering lead
The platform engineering lead will have a background in DevOps and is responsible for headcount and budget planning. They have to keep track of KPIs and OKRs, understand the needs of stakeholders and manage their expectations. They will either have product management experience or hire a platform product manager (see below) to incorporate a platform-as-a-product approach.
Platform product manager
The platform product manager should have a technical background in DevOps but also be able to be a product owner in their own right. They may take on a ‘technical product owner’ role. This is because to really embrace platform engineering, you need to take on a ‘platform as a product’ approach, ensuring that the platform meets the needs of many developers or users, but to really understand the platform, you need the technical know-how. This role is generally focused on the platform itself - the strategy for building and maintaining it, leading the roadmap and prioritizing features. This person will also need to implement feedback loops for all platform users, to ensure there are no issues, bottlenecks or gaps in the platform or portal.
Developer experience (DX) engineers
Developer experience engineers are the voice for developers. That means they will gain feedback from developers through surveys and meetings; they may use a portal and a developer experience platform to keep track of specific developer experience metrics, and monitor any changes. The DX engineer may be tasked with a particular focus such as focusing on platform integrations, code reviews or documentation. They will care about developers’ pain points and bottlenecks, and should be the developers’ first point of contact if there are issues that need to be addressed.
Platform engineers
Platform engineers should be able to solve platform challenges by automating workflows and abstracting away complexity for others. They should ensure that resources and infrastructure can be accessed by developers using a standardized approach that adheres to organizational policies. The idea is to give developers control over the applications they manage and deploy, as well as useful insights from numerous engineering tools, without needing to have the knowledge of the underlying resources that support these apps and tools.
The platform engineer will want to ensure that the platform doesn’t fall into technical debt, and will also have other responsibilities such as:
- Creating new platform or portal features
- Building new deployment processes for developers
- Working with observability, monitoring and logging tools
- Setup and maintain CI/CD pipelines
- Monitor, troubleshoot and improve system security, stability, reliability and performance
- Improving engineering standards, testing, tooling and processes
Just like the managers and leaders above them, platform engineers must embrace the product management approach to building a platform and portal.
Architects
Enterprise architects will want to drive platform engineering initiatives because of shortcomings with their existing enterprise architecture approach. They will be looking to ensure easier onboarding, reduction in developer complexity and easier approaches for developers to make changes. Meanwhile, infrastructure architects will be more focused on coding, cloud and automation.
Other skills
- UX
Platform engineering teams may hire someone from UX to ensure that the user experience of the platform and portal, including the UI, meets the needs of developers. - Infosecurity
There are platform engineering teams that have infosecurity specialists on their team to ensure security standards are upheld. Regardless, security will be a stakeholder that is involved in platform engineering.
Challenges in building a platform engineering team
- Transforming from DevOps to platform engineering
The biggest pitfall of building a platform engineering team is to think that by building it you will immediately reap the benefits of a platform engineering approach. In the same way that a platform and portal require a product management approach rather than a ‘build it and they will come’ approach, the team needs to be built with purpose. Merely replacing DevOps for platform engineering in name only doesn’t work. After all, the focus on DevOps is operational, while platform engineering is about developer experience. Everyone on the team needs to be aligned on what the purpose of the team is, what its goals are, how they communicate and what their individual responsibilities are.
- Stakeholder focus
To really get platform engineering to work, you can’t focus on just one stakeholder. Although the focus is on developer experience, there are many other stakeholders that need to be considered - essentially anyone that is involved in the software development lifecycle and your production status. While you can initially focus on developers, you have to seek the views and the ways in which other stakeholders will use the platform and portal. Most importantly, platform engineers should not build anything because of what they believe in.
- Handling friction between teams
There can be friction between different teams that requires some planning and thinking to help mitigate. For example, DevOps and platform engineering teams may have friction points if prerequisites are not set. This means that DevOps should establish standards to make it easier for platform engineers to create experiences via the platform and portal. Platform engineers need order and conventions for platform engineering to succeed.
- Keeping track of where you are and where you’re going
Platform engineering is meant to enable engineering teams to accomplish numerous goals. But it’s easy to get misaligned goals and plans. This is why it’s important for a lead to use a framework such as OKR, enabling them to identify pain points and objectives, define metrics to measure improvements and map use cases to a key result.
Book a demo right now to check out Port's developer portal yourself
It's a Trap - Jenkins as Self service UI
How do GitOps affect developer experience?
It's a Trap - Jenkins as Self service UI. Click her to download the eBook
Learning from CyberArk - building an internal developer platform in-house
Example JSON block
Order Domain
Cart System
Products System
Cart Resource
Cart API
Core Kafka Library
Core Payment Library
Cart Service JSON
Products Service JSON
Component Blueprint
Resource Blueprint
API Blueprint
Domain Blueprint
System Blueprint
Microservices SDLC
Scaffold a new microservice
Deploy (canary or blue-green)
Feature flagging
Revert
Lock deployments
Add Secret
Force merge pull request (skip tests on crises)
Add environment variable to service
Add IaC to the service
Upgrade package version
Development environments
Spin up a developer environment for 5 days
ETL mock data to environment
Invite developer to the environment
Extend TTL by 3 days
Cloud resources
Provision a cloud resource
Modify a cloud resource
Get permissions to access cloud resource
SRE actions
Update pod count
Update auto-scaling group
Execute incident response runbook automation
Data Engineering
Add / Remove / Update Column to table
Run Airflow DAG
Duplicate table
Backoffice
Change customer configuration
Update customer software version
Upgrade - Downgrade plan tier
Create - Delete customer
Machine learning actions
Train model
Pre-process dataset
Deploy
A/B testing traffic route
Revert
Spin up remote Jupyter notebook
Engineering tools
Observability
Tasks management
CI/CD
On-Call management
Troubleshooting tools
DevSecOps
Runbooks
Infrastructure
Cloud Resources
K8S
Containers & Serverless
IaC
Databases
Environments
Regions
Software and more
Microservices
Docker Images
Docs
APIs
3rd parties
Runbooks
Cron jobs
Check out Port's pre-populated demo and see what it's all about.
No email required
Contact sales for a technical product walkthrough
Open a free Port account. No credit card required
Watch Port live coding videos - setting up an internal developer portal & platform
Check out Port's pre-populated demo and see what it's all about.
(no email required)