Building a Product Platform Engineering Team

You must help yourself before helping others

Dec 17, 2025

This is the last email for 2025.

I usually take the last two weeks of the year to get rest, and I want to take this moment to thank you for this exciting year 2025 and your support along the ride.

Seriously, thank you. I wish you the best for the coming year.

You will receive my next email in the first week of January 2026.

If you have read my newsletter for a while, you know that I’ve been deeply immersed in the Product Platform Engineering world for the last 8 years. In case you want to go deep into what a Product Platform Engineering Team is, I recommend the following reading 👇🏻

What is Product Platform Engineering?

Marcos F. Lobo 🗻🧭

November 20, 2024

Read full story

In today’s email, I go one step beyond, and you will learn the technical principles on which a Product Platform Engineering Team should be based.

The main idea of today’s email is this:

You need to define a way of working so your team can release their applications, libraries, and frameworks quickly.

Otherwise, the DEV teams will find a way to achieve the same on their own.

To achieve this, you must focus on the following steps, in order:

1. Programming language and framework to use

This is extremely important to me; it can be the difference between taking half a day or a full week to deliver a new feature to teams using the framework.

You have to pick up a language and framework/libraries that enable your team to deliver fast.

A Product Platform team must be pragmatic from day one. The language should let you achieve high performance with minimal code. Likewise, the framework must offer transparent support for observability: logging, metrics, and tracing should be first-class citizens.

How to choose it? I recommend that you make the decision based on:

What is the most common language/framework used in the Engineering organization?
Are there enough people in the market knowledgeable about that language/framework?
Is the language/framework mature enough to provide an easy way to have things like observability out of the box?

☝🏼 Crucial: the team must be proficient in the chosen language and framework. Don’t pick a language that only one person in the company understands.

2. Avoid pointless debates that don’t help the development teams

Some people will argue tabs vs spaces, others will push Google’s linter, and others want a custom rule set. Some prefer squash merges, others don’t.

These are details that add no value to your real customers: the development teams. Why waste time opening debates about it?

☝🏼 Let’s focus on the business value and the priorities.

Development teams want new features or ways to deliver those features, the same goal as your end users.

3. Use the same CI/CD as the development teams

Be close to the development teams’ pain.

☝🏼 Their pain must be your pain.

If they struggle with the CI/CD system, you should experience the same constraints because that alignment will make your platform more useful and realistic.

If you implement CI/CD functionalities for development teams, your team should use them as well.
If your team uses something else, you have to use it too.

You have to understand their struggle so you can propose solutions for them.

4. Hold yourselves to the same standards as the development teams

You might not be running business traffic, but that’s not an excuse to lower standards.

Best practices, such as:

Pair Review / Programming
TDD
Software Architecture that speaks (Screaming Architecture mentioned in the Clean Architecture book)
Security updates
Among others that are demanded for development teams, so they can deliver high-quality products.

☝🏼 Apply the same level of scrutiny for support, monitoring, and reliability to the Product Platform team as you do to the development teams. That closeness helps you understand their perspective and provide better support.

Some examples of this are:

Monitoring: development teams have monitors and alerts when services fail, then your QA Enablement team should too.
Support: development teams rely on a support network to help each other, then build the same for your team.

Those are the minimal commitments to reach in any Product Platform team.

☝🏼 Ensure you put in place a way of working as a team before implementing solutions for the DEV teams.