Same Company, Different Planet: Life in Platform Engineering
Some shifts in your career feel like a new chapter. Others feel like stepping onto a different planet altogether.
This photo—massive, layered, shaped by time—reminded me of what it felt like moving from a product org into a central platform team. The terrain was unfamiliar. The forces at play were deeper and slower. And while the view was expansive, the path forward wasn’t always obvious.
This piece is a reflection on that transition—what changes, what doesn’t, and what I’m still learning.
After spending the last few years in product engineering—building features, scaling teams, and helping shape how product orgs operate—I recently made the move to a platform organisation. What drew me was the scale, the technical complexity, and the chance to influence engineering across the company.
I went from working in a product org of ~50 engineers, embedded in a business unit with ~700 engineers, to a central platform org that serves ~5000 engineers across the company. Palpably different dynamics 🙂.
It’s been four months now, and I’ve had enough time to notice how different life is in platform land. Here are some early reflections on what’s distinct between product and platform organisations—through the eyes of someone still finding their footing in the shift.
Platform Complexity ≠ Product Complexity
Product complexity is very different from platform complexity. It’s not useful to compare them in terms of which one is more complex—each is shaped by a different set of forces and constraints.
Product orgs tend to be tightly coupled to the business environment. Their complexity is driven by external factors like market competition, shifting regulations, or sales pressure. This requires a certain type of engineering muscle—one that can respond quickly, adapt systems to evolving needs, and deliver value fast.
Platform orgs, by contrast, deal with complexity that’s often inward-facing. It’s buried in technical depth, large-scale infrastructure, and long-term operational stability. For example, figuring out how to decommission legacy systems and migrate workloads to modern infrastructure—without downtime—is a fundamentally different kind of problem.
Both domains are complex in their own right. But the muscles you need to flex are rarely the same.
Platform Specialists vs Product Generalists
Most of the engineering work in product orgs is pure software engineering. By its nature, much of this knowledge is transferable across technology stacks. A RESTful API is still a RESTful API whether you write it in Java or Go. An RDBMS remains conceptually the same whether it's Postgres or SQL Server. Sure, there are nuances—but these are generally easy to overcome. It’s not a huge leap for a frontend engineer who worked with Angular to become productive with React. Over time, it’s also common for engineers in product orgs to develop familiarity with large swathes of their stack.
Platform work, on the other hand, tends to demand specialists. Take observability tooling as an example: the team responsible for it needs deep expertise—not just in instrumentation, but in time series modelling, preventing cardinality explosions, building HA pipelines, and ensuring no data is silently dropped. These are not just plug-and-play skills. It’s rare (and expensive) to find engineers who can carry this kind of knowledge across stacks efficiently.
This distinction shapes how platform orgs are structured, how work flows through them, and how they think about hiring.
Platform Buy vs Product Build
Companies often categorise their software efforts into three buckets: competitive advantage, differentiator, or commodity (see frameworks like Pace Layering or Wardley Mapping). If something doesn’t add direct business value or isn’t perceived as a differentiator, it’s treated as a commodity. No surprise then—platforms, especially in non-digital-native companies, are often seen as commodities, while product work is seen as the real driver of business impact.
This has practical consequences. Product orgs are expected to move fast and retain control over how quickly they can iterate. The limiting factor is usually engineering talent density—not third-party tooling. Depending on a vendor for core product delivery would be considered an unacceptable business risk.
In contrast, platform orgs are incentivised to treat baseline capabilities as commodities and outsource them. It makes little sense for most companies to build their own time series databases, alerting systems, or container orchestration platforms when mature, off-the-shelf solutions exist. As a result, platform teams spend significant time managing vendor relationships. They need to understand hyperscaler pricing models, track their own platform unit economics, and know which levers to pull when negotiating contracts. Product teams rarely need to think about vendor lock-in—but for platform teams, it’s second nature.
One side effect of this commoditisation mindset is that companies often outsource platform engineering roles to offshore service providers rather than hiring in-house talent. But this is beginning to shift. As product orgs grow more aware of how poor platform decisions can undermine their velocity and goals, platform capabilities are starting to be recognised as differentiators. The response? A trend toward insourcing platform engineering talent.
Platforms are downstream of Business Urgency
Product organisations are directly exposed to the external business environment—and sensitive to it. Especially in mature orgs, they’re incentivised to track business metrics and respond to change quickly. Their proximity to the business makes it relatively easy to define success metrics and measure their direct impact. Both success and failure are quickly visible.
That’s not usually the case in platform orgs. They sit at least one node away in the org chart from the business, which makes it harder to connect their work to direct business value. As a result, success and failure aren’t always obvious. In the absence of clear business-linked metrics, platform orgs often adopt proxies like cost optimisation, internal adoption, or user NPS. These aren’t bad—but we can do better.
One consequence of this distance is that business pressures usually trump platform mandates. When product teams are under pressure to deliver, they’ll prioritise outcomes over alignment—even if that means bypassing platform standards. That’s why seasoned platform folks often emphasise pull over push—platforms should be adopted because they’re valuable, not because they’re mandated. When this doesn't happen, product orgs often drift away from the platform. The result? Fragmented ecosystems, higher maintenance costs, technical debt, and expensive migrations down the line. Still, when a platform isn’t ready to meet product needs, this drift is sometimes a cost worth paying.
Another consequence: business pendulum swings hit platform orgs especially hard. One year, the company’s focused on topline growth; the next, it’s all about cutting costs. Each swing asks something different of the platform. It takes a few cycles before a platform org becomes mature (and resilient) enough to navigate these shifts without constant strategic churn.
Higher Stakeholder Fragmentation in Platforms
A central platform org serves multiple business units—each with its own software engineering teams, goals, and constraints. These units often operate with vastly different expectations around risk tolerance, availability, and stability. For example, car telemetry, data platforms, factory software, company websites, and partner integration portals all place very different demands on the platform. Requirements around data integrity, uptime, and security vary widely—and so do the engineering cultures.
And it’s not just about technical demands. Each product org also carries its own business pressures. Everything is urgent. Every ask feels critical. Every stakeholder wants their needs met yesterday.
This makes stakeholder management one of the most important aspects of working in a platform org. Prioritisation becomes a zero-sum game. Saying yes to one team may mean saying not now to another. Learning to navigate this tension—to push back without eroding trust—is a skill platform teams must develop and protect.
Proximity to Users in Platforms
A recurring theme in platform engineering literature is that “your users sit right next to you—just talk to them.” This stands in contrast to product engineering, where engineers rarely have direct access to users. There, user behavior is often abstracted into dashboards, and the human connection is proxied through product designers or UX researchers.
But software engineers are a very different breed of users. Proximity doesn’t automatically translate into influence—or trust. In fact, being close to your users brings a unique set of challenges. You're exposed to social dynamics that engineers on product teams are often shielded from.
Enthusiastic product engineers often have opinions with a poor signal-to-noise ratio. A seasoned Staff+ engineer may offer valuable feedback—if you're lucky, it's delivered constructively. More often, you're fielding vague complaints, navigating comparisons to platforms at previous employers, or addressing escalations from product leadership based on perceived shortcomings. It can take multiple iterations just to clarify the underlying issue.
Still, empathy is essential. You're collaborating with fellow humans, not just servicing requests. Trust is hard-earned and easily lost.
This nuance is worth keeping front and center—for both platform and product leaders. Building mutual respect and a collaborative mindset is what ultimately makes progress sustainable.
Lack of Product Mindset & Execution Muscle
Because of their proximity to the business—and the pressure that comes with it—product orgs are attuned to making hard prioritisation calls, running experiments, and reasoning about value and viability risks. This mindset often extends into engineering and design functions as well. Over time, product orgs develop strong delivery muscle: they get good at making high-integrity commitments and following through.
Coordinating across teams, running customer research, planning launches, tracking adoption and retention, measuring ROI, making data-informed decisions—these are core operating capabilities in a mature product organisation. Product orgs also tend to be aware of Conway’s Law and its impact on user experience. This drives intentional architecture and org design choices aimed at reducing team coupling and improving execution efficiency.
Platform orgs, by contrast, don’t usually face the same kind of business pressure. If the platform is unstable or immature, most of the team's time gets consumed by support requests and operational toil—leaving little capacity for delivering incremental value.
Many platform orgs are now realising the need to embed product thinking—to better understand user needs, assess viability, and make focused prioritisation decisions. But in digitally non-native companies, it's still rare to find platform teams that combine deep technical specialization with strong product and architecture instincts. Familiarity with software architecture, domain-driven design, or team topologies—tools that help optimise for execution—is often lacking. And the specialised nature of platform work makes it harder to attract or grow such hybrid talent.
The result: platform teams often struggle to establish predictable, value-driven delivery at scale.
I’m still early in this journey, and I don’t claim to have all the answers. But these first few months have made one thing clear: platform work isn’t just technically challenging—it’s organisationally, socially, and emotionally complex in ways that are easy to overlook from the outside. The shift from product to platform feels less like changing jobs and more like switching disciplines. Same company, different planet
If this resonated, I’d love to hear your perspective—especially if you’ve walked this path yourself.
.