Stop Firefighting: How to Balance Ops and R&D in Platform Engineering Teams

Every platform engineering leader has the same conversation with their CTO, roughly quarterly: "We need more headcount." The CTO's answer is always the same: "Show me what the current team is delivering."

The honest answer is uncomfortable: 60-70% of your team's time goes to firefighting. Incident response, urgent patches, "can you just fix this one thing," unplanned work that devours the roadmap. The remaining 30-40% goes to building new capabilities — but it's fragmented across interrupted sprints, context-switching engineers, and half-finished projects.

The result: your ops-focused engineers are burned out from constant firefighting. Your dev-focused engineers are frustrated because their projects keep getting shelved for emergencies. Both groups feel like the other doesn't understand their reality. And the CTO sees a team that's always busy but never delivers strategic outcomes.

This isn't a headcount problem. It's a strategy and structure problem. One strategy, executed across what feels like siloed teams.

The Silo Pattern

Most platform teams naturally split into two informal groups — even if the org chart says they're one team:

• The Firefighters (Ops/SRE-leaning): They know every production quirk. They're on-call. They fix things at 2am. They have 47 Slack notifications right now. They're essential, exhausted, and resentful that the "dev side" gets to build shiny things while they keep the lights on
• The Builders (Dev/Platform-leaning): They're designing the self-service platform, building golden paths, evaluating new tools. They have a beautiful roadmap. They're frustrated because every sprint gets disrupted by "just one urgent thing," and their projects take 3x longer than estimated because they keep losing context

Both groups are right. Both are necessary. And without deliberate structure, they'll drift further apart — different priorities, different definitions of success, different relationships with the rest of engineering.

The Unified Strategy Framework

One strategy doesn't mean one team doing everything. It means both groups working toward the same outcomes with explicit allocation, boundaries, and feedback loops.

Step 1: Quantify the Split

Before you can fix the balance, you need to know the current state. Track time allocation for 4 weeks (not self-reported — use ticket data and calendar analysis):

Platform Team Time Audit (4-week snapshot)

Most teams are shocked when they see the data. "We knew firefighting was bad, but 55%?" The number makes the conversation concrete. You're not asking the CTO for more headcount — you're showing them that 55% of existing headcount is consumed by reactive work, and here's the plan to cut it to 25%.

Step 2: Reduce Firefighting (Not Just Manage It)

The goal isn't to get better at firefighting. It's to have fewer fires. Every hour invested in fire prevention returns 5-10 hours of freed capacity over the following quarter.

• Top-5 incident analysis: Look at your last 20 incidents. You'll find that 5 root causes account for 60-80% of firefighting time. Fix those 5 things. Not "we should improve our monitoring" — specific, actionable fixes with owners and deadlines
• Automate the ticket queue: Your top-10 ticket types are probably: namespace creation, secret rotation, certificate renewal, access grant, resource quota change, DNS record, new environment, log access, deployment rollback, config change. Automate the top 5. That's 50% of your ticket volume eliminated. Self-service tiers turn tickets into API calls
• Runbook automation: For incidents you can't prevent yet, automate the response. A 45-minute manual incident response that follows the same 10 steps every time should be a script. AI coding tools can generate runbooks from your service manifests
• Error budgets: SRE-style error budgets make the tradeoff explicit. "We have 43 minutes of downtime budget remaining this quarter. Spending it on a risky deployment means no more deployments until next quarter unless we invest in reliability." This gives the builders permission to say no to risky feature requests

Step 3: Protect R&D Time

Reducing firefighting frees capacity. But freed capacity gets immediately consumed by new requests unless you protect it structurally:

• Dedicated R&D sprints: Every 4th sprint is R&D only. No tickets, no incidents (unless P1). The on-call rotation covers production. Everyone else works on strategic projects. This is non-negotiable — if leadership cancels R&D sprints, you lose the team's trust and eventually the team
• 20% time (structured): Every engineer gets 1 day per week for research, experimentation, or tooling improvements. Not "when you have time" — a specific day, blocked on the calendar, respected by the team. Friday is common. Track what people build. Share results in Monday standup
• Innovation backlog: Maintain a separate backlog for R&D ideas. Source it from: incident post-mortems ("if we had X, this incident would have been prevented"), developer feedback ("we keep asking for Y"), industry trends ("Z is solving this problem at scale"). Prioritise quarterly
• Proof-of-concept budget: Allocate 10% of compute budget for experimentation. Engineers should be able to spin up a test cluster, try a new tool, or benchmark an alternative without filing a business case. Kill experiments that don't work after 2 weeks. Scale the ones that do

Step 4: The Rotation Model

The most effective pattern for breaking silos: structured rotation between firefighting and building.

Team Rotation Model (8 engineers)

The rotation model eliminates the "us vs. them" dynamic. When builders spend 2 weeks firefighting every 2 months, they understand why reliability matters. When firefighters spend 6 weeks building, they see why platform investment prevents future fires.

The Heart Team: Shared Identity

Strategy and structure aren't enough if the team doesn't feel like one team. The "heart" of the team — its shared identity, values, and purpose — needs deliberate cultivation:

• Shared mission statement: Not corporate fluff. Something real: "We make it easy and safe for every engineering team to ship to production." Both firefighters and builders serve this mission
• Shared metrics: Don't measure ops and dev separately. Shared OKRs: "Reduce mean time to recovery by 40% AND ship self-service namespace provisioning." Both are platform outcomes. Both require both groups
• Weekly demo: Every Friday, one person demos what they worked on. Could be a new feature. Could be an incident post-mortem with a clever fix. Could be a research finding. Equal status for all types of work
• Blameless post-mortems: Incidents are learning opportunities, not blame games. When the team sees incidents as interesting engineering problems rather than someone's fault, the stigma of "ops work" disappears
• Shared on-call compensation: If only some engineers are on-call, they should be compensated fairly. If everyone rotates through on-call, the compensation is equitable by design. Nothing breeds resentment faster than unequal burden without acknowledgement

Measuring the Balance

Track the balance quarterly with a simple dashboard:

Platform Team Health Dashboard (Q2 2026)

Time Allocation:
Firefighting	28% (target: 25%) ⚠️ Slightly high
Maintenance	14% (target: 15%) ✅
New capabilities	38% (target: 40%) ✅ Trending up
R&D	11% (target: 10%) ✅
Documentation	9% (target: 10%) ✅
Outcomes:
Incidents	12 this quarter (down from 19 last quarter) ✅
MTTR	23 min (down from 41 min) ✅
Ticket volume	340 (down from 580 — automation working) ✅
Features shipped	7 (up from 3 last quarter) ✅
Platform NPS	+34 (up from +18) ✅
Team Health:
Rotation adherence	100% (all engineers rotated as planned) ✅
R&D sprint protected	3/3 (no cancellations) ✅
20% time usage	78% (target: 80%) ✅
Burnout risk	1 engineer flagged (addressed) ⚠️

This dashboard tells the whole story. Show it to the CTO. The conversation changes from "we need more headcount" to "here's how we're getting more from the team we have — and here's the specific investment that would accelerate it further."

What Open Empower Delivers

• Platform team assessment: Time audit, silo analysis, and firefighting quantification. Understand where your team's time actually goes
• Unified strategy design: Single roadmap covering reliability, capabilities, and R&D. Shared OKRs that align ops and dev outcomes
• Rotation model implementation: Shield/Build rotation structure, on-call design, and knowledge transfer processes
• Firefighting reduction: Top-5 incident root cause elimination, ticket automation, runbook automation
• R&D protection: Sprint structure, innovation backlog, experimentation budget, and measurement framework
• Team health monitoring: Dashboard design, quarterly review process, and burnout prevention

One team. One strategy. Protected time for both keeping the lights on and building the future. Let's design your balance.