Platform thinking for smaller teams

Platform work is easy to caricature. Teams either overbuild internal abstractions too early or wait until delivery is visibly on fire.

The better question is not whether you need a platform team. It is whether you need platform thinking.

If engineers repeatedly solve the same problem in slightly different ways, you already have the raw material. The issue is not headcount. The issue is duplicated cognitive load.

I work on systems that make the product and engineering organization more scalable: platform architecture, public APIs, enterprise capabilities, automation, integrations, reliability, observability, and developer infrastructure. I tend to look for repeated pain and ask whether it should become a reusable capability rather than another one-off.

That habit is useful long before you have a dedicated platform organization.

Platform thinking starts with repeated pain

In smaller teams, friction feels normal because everyone is still close to shipping. Local workarounds accumulate. One engineer writes a script. Another invents a different setup path. A third team keeps a private checklist. Nothing looks catastrophic. The organization is still paying the same tax in multiple places.

Platform thinking asks: where are we asking people to repeatedly solve a non-differentiating problem?

Those problems are not glamorous:

• local development setup
• deployment for a class of services
• test scaffolding
• API documentation that currently lives in someone’s head
• observability defaults
• integration mappings that get rewritten per customer

If those experiences vary too much, the cost is not only time. It is inconsistency and a growing set of unofficial experts.

Reverse Sync was a platform decision disguised as an integration

Salesforce reverse sync could have been a customer-specific implementation. That would have been the fastest Salesforce version. It would also have taught the organization the wrong lesson: integrations are bespoke jobs.

We chose a reusable automation architecture — triggers, conditions, object mappings — instead of optimizing only for the first CRM.

That is platform thinking at product scale. You accept some extra design cost so the next integration is not a rewrite. Later native work on surfaces such as HubSpot, Coupa, and Slack is easier to reason about if the underlying idea is “automation primitive” rather than “Salesforce special case.”

The trap is waiting for a platform team to exist before you are allowed to make that call. By then the one-offs are already the architecture.

Developer experience is platform work

Developer productivity often breaks down because engineers repeatedly pay the same coordination or tooling cost.

I try to identify those patterns and turn them into better defaults. I am particularly interested in the point where developer productivity stops being an individual habit and becomes an engineering system.

Concrete surfaces I have worked toward:

• Developer Portal and self-service developer experience
• public API experience and API documentation
• deployment automation for integrations
• reusable engineering workflows
• observability and operational tooling

The broader goal of the developer-platform work was reducing the amount of developer context that had to travel through Support, TPMs, or individual engineers. If a partner or an internal team needs a human to explain the API every time, you do not have a platform. You have a queue.

Avoid platform theater

Platform theater often begins with good intentions. Teams see genuine friction and decide to build something comprehensive. Because the scope is too abstract, the platform optimizes for internal elegance rather than adoption.

That usually shows up as:

• internal tools nobody asked for
• custom abstractions that hide useful details
• high migration cost for unclear value
• roadmap language that sounds mature and feels disconnected

Engineers are right to resist this. A platform should make the right path easier than the custom path.

Good early platform work is narrower:

1. Remove recurring friction from a common path.
2. Improve safety for a change that happens often.
3. Reduce the number of bespoke decisions people need to make.

Sometimes that is a paved deployment path. Sometimes it is API docs and a portal. Sometimes it is an automation model instead of a hardcoded sync. It does not require a vision deck.

Reliability and culture are part of the same instinct

I have also worked on treating reliability as an operating system: dashboards, ownership, incident follow-through, on-call, platform improvements — rather than a sequence of incidents that senior people absorb.

And for the last two years I have helped organize SpotDraft’s company hackathons. Legal Intake started there. Good engineering organizations need space for ideas that do not begin on the quarterly roadmap. Some of those ideas should become products. Some should become internal platforms. The common thread is reusable capability.

I like creating reusable things. Sometimes that is an internal mechanism. Sometimes it is a public repository or template so thousands of people do not solve the same problem again. Platform thinking is that instinct applied to how the company builds software.

If a problem keeps requiring exceptional individual effort, look for the missing system. That is true for developer setup, for integrations, and for the way teams operate.