Building a Product Platform Engineering Team

You must help yourself before helping others

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?

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:

1. What is the most common language/framework used in the Engineering organization?

2. Are there enough people in the market knowledgeable about that language/framework?

3. 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.

Building a Product Platform Engineering Team

Hope you find this email useful, and I would like to hear your vision about how to build Platform Engineering teams. I read you in the comments.

---

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴