Blog
/
/
How to build a platform engineering team
Platform engineering

How to build a platform engineering team

Download PDF
Aug 27, 2024
Platform engineering

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.

{{cta}}

Book a demo right now to check out Port's developer portal yourself

Book a demo
{{jenkins}}

It's a Trap - Jenkins as Self service UI

Read more
{{gitops}}

How do GitOps affect developer experience?

Read more
{{ebook}}

It's a Trap - Jenkins as Self service UI. Click her to download the eBook

Download eBook
{{cyberark}}

Learning from CyberArk - building an internal developer platform in-house

Read more
{{dropdown}}

Example JSON block

{
  "foo": "bar"
}

Order Domain

{
  "properties": {},
  "relations": {},
  "title": "Orders",
  "identifier": "Orders"
}

Cart System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Cart",
  "title": "Cart"
}

Products System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Products",
  "title": "Products"
}

Cart Resource

{
  "properties": {
    "type": "postgress"
  },
  "relations": {},
  "icon": "GPU",
  "title": "Cart SQL database",
  "identifier": "cart-sql-sb"
}

Cart API

{
 "identifier": "CartAPI",
 "title": "Cart API",
 "blueprint": "API",
 "properties": {
   "type": "Open API"
 },
 "relations": {
   "provider": "CartService"
 },
 "icon": "Link"
}

Core Kafka Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Kafka Library",
  "identifier": "CoreKafkaLibrary"
}

Core Payment Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Payment Library",
  "identifier": "CorePaymentLibrary"
}

Cart Service JSON

{
 "identifier": "CartService",
 "title": "Cart Service",
 "blueprint": "Component",
 "properties": {
   "type": "service"
 },
 "relations": {
   "system": "Cart",
   "resources": [
     "cart-sql-sb"
   ],
   "consumesApi": [],
   "components": [
     "CorePaymentLibrary",
     "CoreKafkaLibrary"
   ]
 },
 "icon": "Cloud"
}

Products Service JSON

{
  "identifier": "ProductsService",
  "title": "Products Service",
  "blueprint": "Component",
  "properties": {
    "type": "service"
  },
  "relations": {
    "system": "Products",
    "consumesApi": [
      "CartAPI"
    ],
    "components": []
  }
}

Component Blueprint

{
 "identifier": "Component",
 "title": "Component",
 "icon": "Cloud",
 "schema": {
   "properties": {
     "type": {
       "enum": [
         "service",
         "library"
       ],
       "icon": "Docs",
       "type": "string",
       "enumColors": {
         "service": "blue",
         "library": "green"
       }
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "system": {
     "target": "System",
     "required": false,
     "many": false
   },
   "resources": {
     "target": "Resource",
     "required": false,
     "many": true
   },
   "consumesApi": {
     "target": "API",
     "required": false,
     "many": true
   },
   "components": {
     "target": "Component",
     "required": false,
     "many": true
   },
   "providesApi": {
     "target": "API",
     "required": false,
     "many": false
   }
 }
}

Resource Blueprint

{
 “identifier”: “Resource”,
 “title”: “Resource”,
 “icon”: “DevopsTool”,
 “schema”: {
   “properties”: {
     “type”: {
       “enum”: [
         “postgress”,
         “kafka-topic”,
         “rabbit-queue”,
         “s3-bucket”
       ],
       “icon”: “Docs”,
       “type”: “string”
     }
   },
   “required”: []
 },
 “mirrorProperties”: {},
 “formulaProperties”: {},
 “calculationProperties”: {},
 “relations”: {}
}

API Blueprint

{
 "identifier": "API",
 "title": "API",
 "icon": "Link",
 "schema": {
   "properties": {
     "type": {
       "type": "string",
       "enum": [
         "Open API",
         "grpc"
       ]
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "provider": {
     "target": "Component",
     "required": true,
     "many": false
   }
 }
}

Domain Blueprint

{
 "identifier": "Domain",
 "title": "Domain",
 "icon": "Server",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {}
}

System Blueprint

{
 "identifier": "System",
 "title": "System",
 "icon": "DevopsTool",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "domain": {
     "target": "Domain",
     "required": true,
     "many": false
   }
 }
}
{{tabel-1}}

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

{{tabel-2}}

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.

Check live demo

No email required

Contact sales for a technical product walkthrough

Let’s start

Open a free Port account. No credit card required

Let’s start

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start

Check out Port's pre-populated demo and see what it's all about.

(no email required)

Let’s start

Contact sales for a technical product walkthrough

Let’s start

Open a free Port account. No credit card required

Let’s start

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start

Let us walk you through the platform and catalog the assets of your choice.

I’m ready, let’s start