How to work with a platform engineering team

December 11, 2024

How to work with a platform engineering team

Ready to start?

Platform engineering teams play a big role in helping developers scale, stay reliable, and use self-service tools. But working with them can sometimes be tricky, especially when their priorities don’t always match what developers need. In this article, we’ll explain what platform teams do, point out some common challenges, and share ideas for better teamwork through understanding and collaboration.

Understanding the role of a platform engineering team

Platform engineers focus on creating the internal tools, environments, and infrastructure that other engineering teams rely on daily. They work to streamline complex processes and eliminate the need for redundant configurations. While they don’t always get the same recognition as feature development teams, platform engineers play a vital role in improving developer efficiency and productivity. 

The difference between platform and DevOps teams

DevOps and platform teams work closely together while focusing on different things. DevOps might build something like a CI/CD pipeline to automate deployments. Platform teams take it a step further by making that tool easier for developers to use. They might create a dashboard for monitoring or add features to simplify how the pipeline runs.

DevOps is all about building processes and tools, while platform engineers focus on making those tools more user-friendly and effective for developers. Both roles are important, and they complement each other to help teams work faster and smarter.

Key responsibilities of platform engineering teams

Platform engineers are responsible for:

  • Creating self-service tools that allow developers to do their work without waiting for assistance. Ensuring systems are reliable and that there’s full visibility into how everything is performing.
  • Standardizing workflows to minimize operational friction.
  • Bridging DevOps practices with developer productivity goals.

For example, when platform engineers set up a good CI/CD pipeline, they help developers cut down on repetitive tasks. This gives developers more time to focus on new features. A system for logging and monitoring helps teams catch problems early before they impact users. This keeps everything running smoothly. 

As Charity Majors said in her 2023 QCon presentation, “The bottom line is that platform teams are responsible for developer productivity.” This sentiment captures the essence of platform engineering: they create systems that “just work” so that developers can focus on coding rather than configuring.

The everyday challenges of platform teams

Platform teams play a big role in supporting developers, but sometimes things can go off track, making collaboration harder. Here’s where platform teams can miss the mark—and how to fix it.

Working in isolation

When platform teams operate in their own bubble, they might build tools that don’t meet developers’ needs. Without regular feedback, they risk creating solutions that developers find confusing or unhelpful. A lack of transparency—like not sharing roadmaps or goals—can leave developers feeling frustrated by decisions they can’t influence but which directly affect their work.

To avoid this, platform teams should treat their tools like products. This means listening to feedback, being clear about priorities, and keeping developers in the loop. A great way to do this is by using a “portal as a product” approach. Think of the portal as a central place where developers can easily access tools, track updates, and give feedback.

Added bureaucracy and gatekeeping

Platform teams often put strict rules in place to keep things stable. But sometimes, those rules make it harder for developers to finish their work. Developers usually need to move fast because of tight deadlines, big goals, or the pressure to deliver quickly. It can feel like hitting a wall if they’re stuck waiting for approvals or dealing with slow processes. This frustration can lead to tension between the teams.

This is where “Ticket Ops” happens. Platform teams spend all their time processing requests, and developers are left waiting for things to move forward. It’s frustrating for everyone and slows everything down.

A better approach is to give developers more independence. Platform teams can focus on creating tools that let developers handle things on their own. By talking regularly with developers, they can build self-service options and set clear guidelines. This helps developers work faster without sacrificing quality. When both teams work this way, developers get the speed they need, and platform teams keep things stable.

Struggling with priorities

Platform teams often get requests from all over the company. Deciding what to work on first is tough. If priorities aren’t clear, it can make developers feel like they’re just “waiting around” or that they don’t have the autonomy to know where to direct their attention next, which causes disillusionment.

A better approach is to work closely with developers and set shared goals. Setting up regular check-ins and feedback loops helps make sure platform teams focus on what matters most. Platform teams can then build the tools their developers need according to golden paths or the ideal way a developer should interact with their software development stack. Clear communication about what’s being worked on and why makes a big difference in building trust.

Misaligned tools

Self-service tools are supposed to make developers’ lives easier. But, if they’re confusing, hard to use, or not well documented, they can end up causing more problems than they solve.

To fix this, platform teams need to design tools with developers in mind. This means keeping things simple, offering good documentation, and providing easy onboarding. Treating these tools like products, with regular updates based on user feedback, helps ensure they actually solve problems and speed up development.

By focusing on developer needs, fostering communication, and treating their tools as products, platform teams can avoid these pitfalls and create a smoother, more productive experience for everyone.

Best practices for partnering with a platform engineering team

Building a strong partnership with platform teams starts with clear communication, mutual empathy, and shared goals. By fostering alignment, both development and platform teams can bridge gaps, unlock their full potential, and work together to drive meaningful impact.

Promote transparent communication and early involvement

Getting platform teams involved early in the planning process ensures alignment from the start. Regular meetings, open communication channels, and shared documentation help bridge gaps between teams, making it easier to anticipate and resolve potential challenges. When platform engineers have visibility into upcoming features and developer needs, they can design tools and processes that provide real support.

Define clear roles and responsibilities

Clarity is critical for collaboration. By establishing clear roles, platform and development teams can understand exactly who owns which tasks, reducing confusion and ensuring smoother workflows.

Establish regular feedback loops

Consistent feedback between developers and platform engineers is essential for continuous improvement. Regular check-ins, surveys, or retrospectives give developers space to share what’s working and highlight areas for improvement. As noted in the QCon talk from Charity Majors, these interactions help bridge gaps in expectations and guide platform evolution based on real-world needs.

Invest in self-service education and support

Self-service tools are great, but they only work if developers know how to use them. That’s why investing in things like tutorials, office hours, and clear documentation is important. These resources make it easier for developers to get started and solve problems on their own.

Another helpful idea is creating "golden paths." These are simple, well-documented workflows that show developers the best way to use the tools. With golden paths, developers know exactly what to do to get their work done quickly and efficiently.

When developers have what they need—guides, support, and golden paths—they don’t have to rely as much on the platform team. That frees up the platform team to focus on improving systems instead of answering the same questions over and over.

Prioritize empathy and cross-team understanding

Platform engineers and developers often come from different perspectives—stability vs. speed. Fostering empathy between teams can help bridge this divide. Invite platform engineers to participate in developer sprint retrospectives or shadow their work to better understand their challenges. With empathy and collaboration, their differences can transform into strengths.

Why you need an internal developer portal

An internal developer portal is one way teams can simplify workflows and unite platform and development teams. Portals act as a “one-stop shop” where developers can access tools, resources, and documentation in one place.

Benefits of a portal:

  • Streamlined access: One portal for all tools and resources minimizes friction and search time.
  • Empowers self-service: Portals allow developers to manage aspects of their work without waiting for approvals or assistance from the platform team.
  • Bridges communication gaps: By centralizing information and support, portals enable more transparent, collaborative environments.

An internal developer portal can make things easier. It gives developers quick access to resources and can integrate with version control systems so they can connect their work with the tools they use. Portals can also provide real-time updates about system status and maintenance schedules, so developers always know what’s going on.

For more on how a portal can support platform engineering, check out our article on platform engineering essentials.

Final thoughts

Platform engineering and development teams can work well together without making things complicated. By understanding challenges, using best practices, and tools like portals, both teams can do their jobs better and collaborate more smoothly. The key is aligning goals and building a culture of teamwork that benefits everyone.

When platform and development teams work together closely, it creates an environment where innovation can thrive. This is not just about the tools, but about building trust and understanding. With clear communication, shared goals, and empathy, both teams can easily overcome challenges. This leads to better productivity and a more successful organization. At the core, success comes from clear communication, empathy, and respect. When these things are in place, platform and development teams can turn any friction into a strong partnership that helps drive innovation and efficiency.

For further reading on building a successful platform engineering team, check out our post on how to build a platform engineering team.

{{cta_1}}

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

Check live demo

No email required

{{cta_2}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_3}}

Open a free Port account. No credit card required

Let’s start
{{cta_4}}

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

Let’s start
{{cta_5}}

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

(no email required)

Let’s start
{{cta_6}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_7}}

Open a free Port account. No credit card required

Let’s start
{{cta_8}}

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

Let’s start
{{cta-demo}}
{{reading-box-backstage-vs-port}}

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

Starting with Port is simple, fast and free.

Let’s start