Originally published on TechSaaS Cloud Originally published on TechSaaS Cloud You hired 6 platform engineers. Four of them are doing ticket work — resetting credentials, debugging CI pipelines, and answering Slack questions about why the staging environment is down again. This isn't a people problem. It's a staffing model problem. The way you organize your platform team determines whether they build leverage or become an expensive help desk. The entire platform team sits together, owns a shared roadmap, and builds platform capabilities as internal products. How it works: Platform team has its own backlog, sprint cycles, and product manager Product teams submit requests through a self-service portal or queue Platform engineers don't join product team standups or rituals Best for: Organizations with 5+ product teams Mature platforms with established self-service tooling Teams where platform work is clearly separable from product work The risk: Ivory tower syndrome. The platform team builds what they think is important, not what product teams actually need. You end up with a beautifully engineered internal developer portal that nobody uses because it doesn't solve the real friction points. Mitigation: Embed a product manager in the platform team. Their job is to interview product engineers monthly and translate pain points into platform roadmap items. Platform engineers are embedded in product teams, attending their standups and working on platform improvements within the product context. How it works: Each product team gets 0.5-1 platform engineer They work on team-specific platform needs (CI/CD, observability, deployment) Coordination happens through a "platform guild" — weekly sync, shared standards Best for: Early-stage platform teams (fewer than 4 platform engineers) Organizations where product teams have very different platform needs Situations where platform adoption is low and you need missionaries, not builders The risk: Platform engineers go native. They become the product team's DevOps person, spending 80% of their time on product-specific work and 20% on platform improvements. After 6 months, you have 4 product-team DevOps engineers and no platform. Mitigation: Enforce a 60/40 split — 60% platform work, 40% product-context work. The platform guild lead reviews allocation monthly. A small core team builds and maintains the platform. Each product cluster has a platform liaison who translates between product needs and platform capabilities. How it works: Core team (3-5 engineers) owns the platform roadmap and builds shared capabilities Liaisons (1 per 2-3 product teams) attend product standups and surface friction Liaisons route issues: simple ones they fix themselves, complex ones go to core team backlog Monthly "platform review" where liaisons present top friction points to core team Best for: Mid-size organizations (50-200 engineers) Organizations transitioning from embedded to dedicated model Teams where platform maturity varies across product areas The risk: Liaisons become bottlenecks. Product teams stop going to self-service and start going to their liaison for everything. The liaison becomes a human API gateway. Mitigation: Liaisons must have a "teach, not do" mandate. If a product engineer asks the same question twice, the liaison's job is to build documentation or tooling — not answer the question again. Factor Dedicated Embedded Hybrid Team size (platform) 6+ 2-4 4-8 Product teams 5+ 2-4 3-6 Platform maturity High Low Medium Self-service adoption High Low Growing Primary risk Ivory tower Going native Liaison bottleneck Based on industry data and our client work: Early stage: 1 platform engineer per 8-10 product engineers Growth stage: 1 per 10-15 product engineers Mature stage: 1 per 15-25 product engineers (self-service reduces load) If your ratio is lower than 1:8, you either have extraordinary platform needs or your platform team is doing product work. Most organizations go through this progression: Phase 1 (0-30 engineers): No platform team. Senior engineers do DevOps part-time. This is fine. Phase 2 (30-80 engineers): First 2-3 platform engineers, embedded in product teams. Focus: CI/CD, deployment, basic observability. Phase 3 (80-200 engineers): Hybrid model. Core team builds self-service, liaisons drive adoption. Phase 4 (200+ engineers): Dedicated platform team with product management. Self-service is the default. Skipping phases causes pain. A 40-person company with a dedicated platform team will waste cycles building infrastructure nobody uses. A 200-person company with embedded platform engineers will have inconsistent tooling across every team. Track one number: percentage of platform requests resolved through self-service. Below 30%: Your platform is a help desk. Invest in self-service tooling. 30-60%: Growing. Focus on documentation and the top 5 repeat requests. 60-80%: Healthy. Platform team can focus on capabilities, not support. Above 80%: Mature. Consider reducing platform headcount or tackling harder problems. Need help designing your platform team structure? We've helped organizations from 20 to 2000 engineers find the right model. Book a consultation or explore our platform engineering services.