As an engineer who’s worked on platform teams almost my whole career, I think the time has come for teams to fundamentally change the way we work. AI has made it easy to blow right past, rewrite, and re-invent platforms when users don’t find it helpful. Platform teams do help, and I think it’s important that we change our tack to ensure healthy, common ecosystems.

In summary, I’m advocating for:

  1. A mindset shift toward close, realtime co-design, directly with the customer.
  2. Pursuing 10x experiments to find and explore new opportunities.

Background #

Why do platform teams exist? #

When a company is founded, the number of employees is small, and they are generally mission-focused:

  • Build things to specifically address what they need.
  • Pick up only the layers of abstraction needed at the time.
  • Focus on accomplishing the organization’s goals, with long-term maintenance and priority as a secondary concern.

Traditionally, this approach hits a bottleneck as a company increases in size, products, and complexity. This is where platform teams are founded. Platform teams:

  • Build shared abstractions that reduce the complexity of a problem for the business.
  • Govern the usage of shared resources.
  • Maintain shared services, reducing the need for operational toil on product teams.
  • Identify further areas of shared problems.

Platform teams rarely accelerate the first team that encounters a problem. However, they often accelerate the second, third, and subsequent teams. They also ensure the reliability of the platform.

What has changed: almost anything can be agentically coded now #

We live in a world where almost anything, no matter how complex, can be agent-coded as a solution to a problem. For example, I work in machine learning, so these include:

  • complex data-loading and compression strategies.
  • quantization evaluation tooling.
  • fully-featured UIs with rich metadata to analyze the data.

However, this can apply to a lot of other areas, such as with web services:

  • telemetry pipelines
  • a/b testing services
  • pub/sub frameworks.

Customers of platform teams are being bottlenecked less and less by 0-to-1 offerings from platform teams. And systems that do not provide perceived value to the end user can be easily bypassed.

The short of it is: users can solve many of their own problems and build bespoke solutions that work for them, and in some ways improve on the offerings that “standard” infrastructure provides.

The perception: “Infra” is seen as slow, complex, and unreliable #

NOTE: perception is not always reality. This section serves as an honest reflection of sentiment that is worth being aware of.

Internally at GM, when talking to users about ML pipelines, the main reason given for the bypass is that shared platforms are seen as slow, complex, and unreliable. The sentiment is debatable, but the rationale is:

  • The layers of abstraction that these systems provide are difficult for agents to understand.
  • Compared to a third-party company or a software-as-a-service (SaaS) platform, internal services are perceived to have more outages.
  • The platform is slow: existing common strategies around dataloading, delays for pipeline startup time, are seen as delays that could be bypassed with bespoke, tailor-tuned code.

This is not unique: I have worked on platforms almost my whole career, and have always heard feedback mainly about speed gaps in the platform. In other words, platforms often become perceived as the exact opposite of what they are intended to be.

Where to go from here: the approach for platforms needs to change #

So where do we go from here? Given how easy it is to agentically code everything, and the general sentiment around shared platforms, how can we ensure the success of a platform?

The strategy summary #

The strategy comes down to the following:

  • Proactive customer outreach and co-design: solve the problems the customers are having now. Validate success with the customer.
  • Embed, with direct project contribution: don’t wait for customers to come to you. Join in on users’ standups and team meetings to hear about their problems.
  • Run our own 10x experiments: explore new opportunities the same way product teams do.
  • Speed, speed, speed: build platforms that are faster and more reliable than any agentically created system.
  • Minimize abstractions: build only what the customer needs.
  • Add guardrails where they matter.

Proactive customer outreach and co-design #

“If you build it, they will come” is less true now. If an agent can just code something that works, the customer may never reach out to see what the shared infrastructure can do.

Any new tool should be written with an explicit customer and use case in mind. Co-design is how one can discover the pain points and gaps.

A product should only be called complete when a customer has validated it, and can say it is providing meaningful value.

Everyone, no matter what seniority you are, should take 30 minutes out of their week to either see a customer’s workflow to understand their painpoints directly, or look at the execution chat channels to see what issues are being raised. If you see friction in someone else’s domain, start a thread and let them know!

Embed, with direct contribution #

Instead of allowing product workstreams to work by themselves, embed into those teams, join their standup and sync meetings, and directly make platform improvements that the customer is asking for: level up the platform to accelerate critical user priorities.

I had a great example of this with an internal project, where a customer decided not to use some of the libraries and abstractions we have around PyTorch to help add metadata to improve compilation to GPU-native code. We joined their meetings and had the discussion, and found the main concern was with coupling on some other legacy libraries and increased build times. From there, we moved quickly, shaved off over 30,000 dependent files, and reduced our build times by 20-30 seconds.

That engagement continues to pay dividends, with active discussion on the merit of the abstractions around aspects like the multiple classes involved in training configuration.

Run our own 10x experiments #

Product teams, being oriented toward a smaller business goal and not maintenance for others, have a little more freedom with their implementations. But that does not mean that platform teams can’t experiment in a similar fashion.

We should run 10x experiments (e.g., cleanroom implementations, rewrites to lower level languages, or complete redesigns). We could try having an agent run the experiment, see what it finds, and transfer learnings.

Speed, speed, speed #

Using the platform and its tools should be comparable to a third-party service, or the raw components. Significant overhead invites teams to skip common components altogether.

Minimize abstractions, work toward small utilities #

Agents are really good at taking small abstractions, and composing them together:

  • They can tirelessly look for methods in the right module.
  • Tests can be written to validate behavior.
  • Agents are good at writing simple, functional code.

Traditionally, abstractions have been added to attempt to reduce human cognitive load. However:

  • agents have no such limitation
  • abstractions can cause agents to introduce additional abstractions just to get the functionality they’re looking for, increasing abstractions unnecessarily.

Minimizing the layers between an agent and the functionality ensures those primitives are used more often, as they would be nearly identical to the code the agent would generate anyway.

If using the abstraction is more lines of code than just writing the unabstracted version, that is almost always an antipattern.

Add guardrails where they matter #

Platforms will always exist to provide guardrails. These are critical to ensure that the organization at large is able to stay functional, preventing a single bad actor from impacting velocity for all. These include:

  • quotas, queues, and usage limits to prioritize scarce resources like compute.
  • managing egress limits and throttling egress.
  • using common platforms when dealing with hairy, business-critical problems: billing, authorization, and security in general—domains where we need careful scrutiny, because a failure can sink a business.

Conclusion, and on to an exciting new world #

Although platform teams are less often in the critical path for innovation in this new world, this is an exciting opportunity to meet the customer where they are, and directly contribute to the organization’s most important goals!

Instead of playing a passive role waiting for adoption to drive impact, platform teams can be proactive, solve immediate blockers and problems, and continue to participate in our product wins!

To do so, we need to double down on a mindset around user value.

Platform teams are dead. Long live platform teams!

Additional details and elaboration #

The importance of validation directly with a customer #

This is a big one. I have been in several meetings where the platform team has made multiple changes to improve reliability - adding monitors, re-architecting systems, etc. But the user didn’t feel like things had changed at all.

This could be a misconception on the user’s part: they are probably doing multiple things, and they may only use your product once in a while.

But it also could be that the fundamental problem has not yet been solved. To ensure it is:

  • Meet with the customer, and show them what you’ve done.
  • Confirm that they agree the problem is addressed.