Your company found product-market fit. Revenue is growing. The engineering team is shipping features, but the cracks are starting to show. Deployments are nerve-wracking. The CI pipeline breaks in ways nobody fully understands. Scaling requires a heroic effort from whoever happens to know the most about the servers. Every developer on the team spends some portion of their week - sometimes a large portion - fighting infrastructure instead of building product.
The instinct at this point is to hire a “DevOps person” to sit alongside the application developers and handle the plumbing - configure the pipelines, manage the servers, put out the fires. It’s the obvious move. It’s also the wrong one.
I know because I’ve spent twenty years working in small companies at exactly this inflection point. The core argument I want to make is one I first articulated in an internal memo in 2012 and have continued to refine through every role since: your first infrastructure hire should not be someone who does work for your developers. It should be someone who builds the platform that lets them do the work themselves.
Two Kinds of Work # #
To understand why, it helps to recognize that application developers and platform engineers are motivated by fundamentally different kinds of problems.
Application developers love work that is vertically aligned with the business. They want to build the feature that delights users, implement the workflow that solves a specific customer problem, or optimize the experience that drives conversion. These are point-oriented problems. They require deep understanding of the product, close partnership with design and business stakeholders, and heavy doses of business logic and creative problem-solving. The best product engineering is tightly coupled to business context.
Platform engineers thrive in a world of abstraction and generalization. The problems they gravitate toward are horizontally oriented. They’re most impactful when applied broadly: a deployment framework that works for any service, a CI pipeline that handles any application, a monitoring stack that covers everything. These solutions are deliberately light on business logic. They don’t require deep partnership with individual product verticals. They require an excellent overall understanding of how the system operates - and a talent for anticipating what other people will need before they need it.
When you hire an ops person to sit next to your developers and manage infrastructure on their behalf, you’re asking someone with horizontal instincts to do vertical work. You’re spending platform talent on point problems. It works in the short term, but it doesn’t scale, it doesn’t compound, and it doesn’t leverage either person’s strengths.
The Lego Block Model # #
The alternative is what I think of as the Lego block model. The platform engineer’s job is to design and build new blocks - tools, frameworks, services, and abstractions - that application developers assemble in creative ways to build product. The platform engineer builds the deployment framework; the developer uses it to ship a feature. The platform engineer builds the CI pipeline; the developer uses it to test and deliver their code. The platform engineer builds the monitoring and alerting layer; the developer uses it to understand the health of what they’ve built.
This is a fundamentally different posture than the traditional ops handoff. Under this model:
The platform engineer’s work is completely horizontal, focused on building technology that is broadly applicable across multiple product efforts. This maximizes the leverage of engineering output - one well-designed abstraction serves every developer on the team.
Application developers get end-to-end ownership of the work they produce. They own the feature from conception through deployment. They own the runtime behavior of their code. They can ship without filing a ticket, without waiting in a queue, without asking permission. They’re accountable for what they build - and they have the tools to meet that accountability.
The platform engineer operates as what I like to call “Tony Stark’s tailor” - building the armor that prevents developers from falling into pitfalls that yield unscalable or unreliable solutions, while never constraining what they can build inside that armor.
The key insight is this: a small company should not optimize its platform for efficiency. It should optimize for autonomy. What you’re offering is clear ownership of ideas and accountability for their delivery. These are roles that allow for quick movement, eliminate the need for unnecessary consensus, and open the door to the kind of velocity that small companies need to survive.
What This Looks Like in Practice # #
The expectation is not that application developers suddenly become infrastructure experts. Nor is it that the platform engineer will be ignorant of business logic and product initiatives. A partnership is inherent to the success of this model. In the absence of mature abstractions, the platform engineer partners with developers to create solutions - but not in the form of a handoff. The engineering challenge is to build self-service components such that developers can iterate autonomously on the product logic that delivers their ideas to users.
After the initial rollout of a solution, the ownership lines are clear. The platform engineer owns the infrastructure they build. The developers own the application code and business logic they provide. No form of tight coupling is required to iterate.
For this to work well, the platform engineer needs to be working a few steps ahead. The production from an infrastructure team deployed this way should look like magic to the developers - things fall into place because their needs have been anticipated, and the scaling and resilience concerns have already been addressed at the platform level.
This Applies Double for Data Teams # #
Everything I’ve described about the application developer relationship holds - and then some - when a company starts investing in data science.
Data scientists are, if anything, even more vertically oriented than application developers. They set out to optimize a particular process, build a predictive model for a specific use case, or reimagine how a part of the business operates. Their work requires deep partnership with business verticals, a heavy mix of business logic, and a healthy dose of creativity. The best outcome of their efforts is often an artifact meant for a machine consumer rather than a human one - an algorithm or API that fundamentally changes the operation of the business.
And yet data scientists are typically not classically trained software engineers. This is historically why ETL work, pipeline development, and production deployment have been handed off to engineers in assembly-line fashion. But all of those tasks are inherently vertical - they’re point-focused work tied to a specific data science initiative. The assembly line wastes engineering talent on work that doesn’t compound.
The Lego block model fits naturally. The platform engineer builds the ETL framework; the data scientist uses it to construct a specific pipeline. The platform engineer stands up experiment tracking and model versioning; the data scientist uses it to manage their work from notebook to production. The platform engineer configures the model serving infrastructure; the data scientist deploys against it. The data scientist should be able to develop and deploy without asking permission from engineering, be accountable for support, and be held to the same performance and reliability requirements as any other production code.
The armor just needs to be a little thicker. Data scientists need more guardrails than application developers, not because they’re less capable, but because the failure modes of data infrastructure are less visible and the consequences of unscalable solutions compound quietly. The tailor’s job is to make those guardrails feel like freedom.
The Tooling Landscape Has Caught Up # #
When I first articulated this model in 2012, the tooling to support it existed but required significant custom engineering. Today, the ecosystem makes this approach dramatically more accessible for small teams.
For application developers: Container orchestration, infrastructure-as-code, and CI/CD have matured to the point where a single platform engineer can provide a production-grade developer experience. Docker and managed container platforms handle the runtime. GitHub Actions or similar tools handle the build and deployment pipeline. Infrastructure-as-code tools like Terraform or Pulumi make provisioning reproducible and self-service. The platform engineer’s job is to assemble these into a coherent, opinionated stack that developers interact with through simple configuration and convention - not tickets.
For data teams: dbt has become the standard for analytics engineering - we were using it at Kickstarter in 2017, which was forward-looking at the time, but today it’s table stakes. Modern orchestrators like Dagster and Prefect have replaced the older generation of workflow tools with frameworks that are far more intuitive to configure and operate. MLflow has emerged as the de facto open-source platform for managing the ML lifecycle: experiment tracking, model packaging, versioning, and deployment. It’s lightweight enough to self-host on a single server backed by PostgreSQL and cloud storage, yet comprehensive enough to give data scientists a self-service path from experimentation to production. For teams already on a cloud provider, managed ML platforms like AWS SageMaker, Google’s Vertex AI, or Azure ML offer similar capabilities with less operational overhead.
Across both: Observability and monitoring tools - Datadog, Grafana, the cloud-native equivalents - have become accessible enough that a platform engineer can build a monitoring layer that serves both application developers and data scientists. The same is true for data quality tooling, alerting, and incident management.
The net effect: the Lego blocks are better than they’ve ever been. The role of the platform engineer has shifted from building everything from scratch to assembling, configuring, and operating a coherent platform from high-quality components - and then getting out of the way.
The Case for the Hire # #
If you’re a small company at this inflection point - product-market fit achieved, team growing, infrastructure groaning - the question isn’t whether to invest in platform engineering. It’s what kind of investment to make.
The ops-as-service model - hire someone to manage infrastructure on behalf of your developers, one task at a time - feels safe and incremental. But it creates dependency, limits autonomy, and spends engineering talent on work that doesn’t compound.
The platform model requires a different kind of hire: someone who thinks horizontally, who understands abstraction and leverage, who can anticipate what developers will need before they need it, and who measures their success not by the tickets they close but by the tickets that never get filed. Someone whose goal is to make themselves invisible - to build the infrastructure so well that the people using it forget it’s there.
That is the work I find most satisfying. It’s the work I’ve spent twenty years learning how to do. And it’s the work that, for a small company at the right inflection point, creates the most lasting value.