01. The Problem: Balancing Speed and Control in Engineering
As engineering organizations scale, the tension between speed and control becomes increasingly sharp. At 100 engineers, a monolithic team might function well with informal coordination. But at 1,000 engineers, this approach fails. The problem isn't just about scaling—it's about maintaining velocity while preserving reliability. Dedicated platform teams and lightweight RFC processes represent two competing strategies to solve this.
Dedicated platform teams, like AWS's internal infrastructure teams or Kubernetes's SIGs, offer centralized control. They standardize tooling, enforce best practices, and reduce fragmentation. However, they create bottlenecks. At Microsoft, the Azure team handled 10,000+ engineers through a centralized platform, but it required years of investment and a dedicated org. This works when the platform is stable and the team is large enough to justify the overhead. But for smaller teams or rapidly changing domains, the delay in platform updates can stifle innovation.
Lightweight RFC processes, like those used at Google or Meta, prioritize agility. Engineers propose changes via RFCs, which are reviewed by a small group. This reduces bureaucracy but risks inconsistency. At Google, 90% of RFCs were approved within a week, but without a dedicated team, maintaining quality became a challenge. The tradeoff is clear: faster decision-making but higher operational risk.
The real challenge lies in the middle. At 500 engineers, a hybrid approach might work—dedicated platform teams for critical infrastructure and RFCs for experimentation. But even then, alignment becomes difficult. At Datadog, the team standardized monitoring tools but still faced 30% of engineers bypassing the platform due to friction. The solution wasn't more control—it was better tooling and clearer ownership.
Ultimately, the problem isn't about choosing one over the other. It's about finding the right balance. Dedicated teams provide structure but slow down change. RFCs enable speed but require discipline. The best organizations, like those at Amazon or Microsoft, iterate on both. The key is recognizing that neither approach is a silver bullet—it's about adapting the process to the scale and context of the team.
02. Key Cost Factors: People, Process, and Platform
The economics of platform teams versus RFC processes hinge on three critical cost factors: people, process, and platform. Each approach has distinct tradeoffs that manifest in headcount, cycle time, and operational overhead. I evaluated these factors based on real-world examples from AWS and Microsoft, where both approaches have been deployed at scale.
People Costs: Headcount and Specialization
Dedicated platform teams require significant headcount to build, maintain, and scale infrastructure. At AWS, the internal service teams that support AWS services like Lambda or EKS typically have 10-20 engineers per service, including SREs and platform engineers. This specialization comes with a $1M+ annual cost per service, assuming an average engineer salary of $150K. The ROI on these teams is often measured in years, as the platform must first mature before delivering value. In contrast, lightweight RFC processes distribute decision-making across existing teams, avoiding the need for dedicated roles. Microsoft’s internal RFC process, for example, reduces headcount by 20% by leveraging existing engineers rather than creating new platform teams.
However, this approach shifts the cost to process overhead. RFCs require time from engineers to review, iterate, and document decisions, which can slow down delivery. At Microsoft, RFCs take an average of 3-5 days to complete, including review cycles. This delay is acceptable for foundational changes but becomes a bottleneck for time-sensitive projects. The tradeoff is clear: dedicated teams reduce process friction but increase fixed costs, while RFCs reduce headcount but introduce variable delays.
Process Costs: Cycle Time and Governance
Process costs manifest in cycle time and governance overhead. Dedicated platform teams can reduce cycle time for infrastructure changes by 30-50% because they own the tooling end-to-end. AWS’s internal teams for services like DynamoDB have achieved this by embedding engineers in the product lifecycle. In contrast, RFC processes add 1-2 weeks to deployment timelines due to review cycles. For example, Kubernetes’s SIG Architecture process for major changes can take months, which is acceptable for foundational work but impractical for agile teams.
Governance is another process cost. Platform teams act as gatekeepers, ensuring consistency but sometimes slowing innovation. Microsoft’s internal platform teams for Azure services enforce strict SLAs, which reduces downtime but requires additional QA cycles. RFCs, while more permissive, risk inconsistent implementations if not rigorously enforced. The cost here is either slower innovation (with teams) or higher operational risk (with RFCs).
Platform Costs: Tooling and Maintenance
Platform costs include tooling and maintenance. Dedicated teams build and maintain platforms like AWS’s internal CI/CD pipelines or Microsoft’s Azure DevOps. These platforms cost $500K-$2M annually to operate, including cloud infrastructure, monitoring (e.g., Datadog), and security tools. The ROI is realized over 2-3 years as teams adopt the platform. RFCs, by contrast, rely on existing tools like GitHub or Confluence, which have lower upfront costs but require ongoing maintenance. For example, maintaining an internal RFC template and review process costs $20K/year at scale.
The tradeoff is between upfront investment and long-term flexibility. Platform teams provide a polished, scalable solution but require significant initial investment. RFCs are cheaper to start but may not scale as teams grow. At AWS, the internal platform teams for services like S3 have paid off with 10x higher adoption rates than externally built tools. RFCs, while cheaper, often lead to fragmented solutions that require consolidation later.
03. Worked Example: Cost Comparison for a Mid-Sized Engineering Team
Consider a team of 50 engineers working on a cloud-native application. They currently use AWS services directly, with ad-hoc tooling and manual processes for infrastructure management. Two approaches are being evaluated: (1) forming a dedicated platform team, or (2) adopting a lightweight RFC process with self-service tooling.
Option 1: Dedicated Platform Team
The platform team would consist of 5 engineers (20% of the total team) focused on building and maintaining internal tooling. I evaluated this because it centralizes expertise and reduces duplication of effort. However, this approach requires significant upfront investment and may not scale efficiently for all use cases.
Cost breakdown:
- Platform team salaries: $150,000/year × 5 = $750,000 annually
- AWS infrastructure costs: $20,000/month × 12 = $240,000 annually
- Tooling maintenance: $50,000 annually
Total annual cost: $1,040,000. This includes the cost of maintaining consistency across the organization but may not fully address all pain points, such as onboarding new engineers or handling edge cases.
Option 2: RFC Process with Self-Service Tooling
Instead of a dedicated team, the organization could adopt a Request for Comments (RFC) process with self-service tooling. This approach leverages existing engineers' bandwidth and reduces overhead. I evaluated this because it aligns with the team's current structure and avoids the need for additional hires.
Cost breakdown:
- RFC process maintenance: $20,000 annually (documentation, meetings, tooling)
- Self-service tooling (e.g., Terraform, Kubernetes): $10,000/month × 12 = $120,000 annually
- Engineering time for RFCs: 20% of 50 engineers × $150,000/year = $150,000 annually
Total annual cost: $290,000. This approach is more flexible but requires discipline to avoid process decay. It also assumes engineers have the capacity to contribute to the RFC process without impacting feature work.
Comparison
The dedicated platform team costs $1,040,000 annually, while the RFC process costs $290,000. The platform team offers more control and standardization but requires a larger investment. The RFC process is cheaper but relies on engineers' willingness to participate.
Key tradeoffs:
| Factor | Platform Team | RFC Process |
|---|---|---|
| Initial Cost | High (hiring, infrastructure) | Low (existing resources) |
| Scalability | Limited by team size | Scales with engineering capacity |
| Time to Value | Longer (build vs. buy) | Faster (leverage existing tools) |
For this team, the RFC process offers a more immediate and cost-effective solution, but the platform team may be justified if the organization anticipates rapid growth or complex compliance requirements. The decision should balance short-term cost savings with long-term maintainability.
04. Decision Framework: When to Invest in Platforms vs. RFCs
Choosing between dedicated platform teams and lightweight RFC processes requires balancing speed, control, and cost. The decision framework below evaluates key tradeoffs using real-world criteria. I evaluated these options against criteria like team size, tooling maturity, and organizational alignment because these factors directly impact long-term maintainability and velocity.
| Criteria | Option A: Dedicated Platform Team | Option B: RFC Process | Option C: Hybrid (Platform + RFC) |
|---|---|---|---|
| Initial Investment | High (3-5 FTEs for 6-12 months) | Low (1-2 FTEs for tooling) | Medium (2-4 FTEs for 6-9 months) |
| Time to Value | 6-12 months (platform maturity) | 3-6 months (RFC adoption) | 4-8 months (parallel development) |
| Scalability | High (platform scales with org) | Low (RFCs become bottlenecks) | Medium (platform scales, RFCs for gaps) |
| Tooling Maturity | High (AWS, Kubernetes, Datadog) | Medium (GitHub, Confluence) | High (platform + RFC tooling) |
| Change Control | Strict (platform governance) | Flexible (RFC approvals) | Balanced (platform defaults + RFC exceptions) |
| Recommendation | Best for large orgs with complex needs (e.g., 50+ engineers). | Best for small teams or early-stage startups. | Best for mid-sized teams (20-50 engineers) needing balance. |
This framework highlights that dedicated platform teams are justified when initial investment is acceptable and long-term scalability is critical. RFC processes are faster to implement but risk becoming a bottleneck. The hybrid approach combines the strengths of both, leveraging platform defaults while allowing RFCs for exceptions. I recommend reviewing this table with your leadership to align on the right approach for your team's stage and scale.
05. Action Step: Implementing a Hybrid Approach
Start with lightweight RFCs to validate demand before committing to platform investments. This approach minimizes wasted effort and aligns with the "fail fast" principle. Begin by documenting existing pain points in a shared wiki or tool like Confluence, then create a template for RFCs that includes problem statement, proposed solutions, and metrics for success. Use tools like GitHub Issues or Jira to track RFCs, ensuring visibility across teams.
I evaluated this because RFCs are low-cost to implement (no new hires or infrastructure) and provide immediate feedback. However, this works best when problems are well-defined and solutions are incremental. For ambiguous or high-risk areas, RFCs may lead to premature consensus or scope creep. Track RFC outcomes over 3 months to identify patterns—if 70% of RFCs result in platform investments, you’re validating the approach.
Once RFCs demonstrate consistent demand, prioritize platform investments using the decision framework from Section 04. Start with the highest-impact, lowest-effort platforms first. For example, if teams repeatedly request better logging, invest in Datadog or Splunk before building a custom solution. Use cost comparisons like those in Section 03 to justify investments, but include a 6-month runway buffer for unexpected costs.
I chose this phased approach because it balances speed and control. RFCs provide agility, while platforms deliver long-term efficiency. However, this requires discipline—avoid building platforms for niche problems or speculative needs. Monitor RFC-to-platform conversion rates quarterly. If conversion drops below 50%, reassess your RFC process or platform priorities.
Pull your last 90 days of RFC data and calculate the percentage of RFCs that led to platform investments. Schedule a 30-minute review with your team and bring these metrics to discuss adjustments.
Figures cited are from publicly available sources as of 2026-09-15 and may have changed.