Building a platform team from one engineer: know why, and know what you skipped

When Platform joined my scope in November 2025, there was no platform team. There was one engineer, reporting to the CTO, picking up work as it came. Nobody had decided what Platform should own, how big it should be, or what it should build first.

I had to make those decisions. Most advice about platform teams assumes the team already exists and has a backlog. This post is about the step before that, and about a second team where the problem was different: integrations that kept getting built as one-offs.

The lesson from both is the same. Understand the problem and where it repeats. Value what compounds. Then write the plan. When your leadership asks why you are building something, you need a clear answer. When they ask what you skipped, you need to know that too.

Start with the repetition

I did not start with a list of platform features. I started with where the same pain kept coming back.

Four inputs shaped the first version of the plan:

• Repeated pain: Where did product teams keep losing time, rebuilding the same thing, or breaking production in the same way?
• What was coming: What would enterprise customers and AI features need in the next year that the system could not give them today?
• Reliability: What threatened production right now? That had to come before anything new.
• The written plan: I wrote the charter before I hired anyone or built anything.

Repetition is the signal that matters most. One team hitting a problem once is a ticket. Three teams hitting it every quarter is a missing platform capability. The cost of a repeated problem grows every time someone solves it again. The value of a shared solution grows every time someone uses it. That is compounding, and it works in both directions.

Write the charter before you ask for people

The charter was the most important thing I produced in the first months. It set three pillars in order: reliability and performance first, then shared engineering leverage, then enterprise and AI readiness. Each pillar had a named owner and success metrics.

The order was the decision. Reliability first meant some exciting work waited. Enterprise and AI readiness last meant those items needed the foundation underneath them, so they were sequenced on purpose. Identity, access, and tenant ownership turned out to be the shared blocker behind several product bets. Writing it down made it obvious they belonged together.

The charter also made the headcount case. I did not ask for people in the abstract. I showed what was at stake, what the team would deliver, and in what order. Then I built the team two ways: I moved engineers in from other teams, and I hired for the platform skills we did not have.

Without the document, every headcount request would have been a negotiation about opinions. With it, the conversation was about whether the plan was right.

Protect the roadmap from the queue

A new platform team attracts requests immediately. Every team has a problem that looks like platform work. If you say yes to all of it, you rebuild the same ad hoc function you started with, just with more people.

I used two defenses.

First, I protected roadmap time. A protected share of the team’s capacity went to charter work, whatever the inbound load looked like. Requests still got handled. They did not get to consume the whole team.

Second, I pushed toward self-serve. When a request came up repeatedly, the answer was to build a reusable piece that product teams could use without Platform in the loop. That turns a support cost into a capability. It is also the clearest test of whether a platform team is working: fewer people need to ask it for things over time.

Integrations: the same problem in a different shape

Strategic Integrations was a different situation. The team existed and shipped. The problem was that each customer integration was built bespoke, so every new one meant building most of it again.

The architecture fix was a reusable automation model. Salesforce Reverse Sync became a trigger-condition-action framework instead of a hardcoded sync, so later automations could reuse it. Around that, we built shared building blocks that new integrations had to start from. A new integration stopped being a new project and became configuration on top of parts that already existed.

In March 2026 I proposed merging Strategic Integrations and Custom Integrations into one team. Three reasons drove it:

• Custom, customer-specific work kept surfacing patterns that should have become product features. In one team, those patterns move into the product instead of staying in a customer’s workflow.
• One team can move people to wherever the load is.
• Customers and other teams get one owner for anything integrations.

The merger and the platform team came from the same instinct. Find the work that repeats. Build it once. Make the next instance cheaper than the last.

How I knew it was working

I looked for two signals on Platform.

The first is that the team plans its quarters against its own charter. Inbound requests do not set its priorities anymore. That sounds small. It is the difference between a function that reacts and a team with a direction.

The second is that engineers on the team own major areas and make the calls without me. A platform team that needs its manager for every design decision has only moved the bottleneck. The goal was a team that could run the charter, argue with it, and change it.

What I would do differently

First, I would protect long-running bets earlier. One initiative stalled because I did not defend it clearly enough when priorities shifted. Platform bets pay off slowly, and that makes them easy to defer. Next time I would name them at the start and defend them before priorities move.

Second, I would communicate more. Platform work is invisible when it works. I explained the why to stakeholders, but not often enough. A team that only shows up in conversation when something breaks loses its budget arguments.

Third, I would start narrower. I took on more themes at the start than a new team could finish. Fewer themes, finished, would have built trust faster than many themes in progress.

Know why, and know what you skipped

If I had to compress this into advice for someone inheriting a team like either of these:

1. Understand the problem first, and find where it repeats.
2. Value the work that compounds over the work that only closes this week’s ticket.
3. Then write the plan or vision, and put it in order.
4. For every item, be able to say why you are building it.
5. For every item you left out, know that you skipped it and why.

The last two are the test. Leadership will ask why you are doing something, and a vague answer costs you trust. They will also ask what you are not doing. If you cannot answer that, you have a list of work, not a strategy.