Stop Wishing for “20% Time.” Make Innovation a Budget You Can Ship Against.

You don’t have 20% time. You have a budget problem.

If you’ve tried “Google-style 20% time” inside a bank, insurer, or Fortune 500, you already know the punchline. The calendar says 20%, the sprint board says 140% WIP. Ops calls about a Sev2, finance wants a reforecast, and your auditors want evidence you didn’t let an engineer SSH into prod. I’ve watched three different orgs announce 20% time and end up with developers doing experiments nights and weekends, followed by a reorg that “re-centers on delivery.”

Here’s what actually works in enterprise land: treat innovation like a budget with hard caps, calendarized windows, and measurable outcomes. No slides about “innovation culture.” Just constraints you can automate and inspect.

Allocate on a calendar, not in a slide deck

Make innovation a scheduling primitive, not a slogan. What’s worked for teams I’ve led and rescued at GitPlumbers:

• Budget ranges: 10% for core product teams, 15% for platform/infrastructure, 5% for compliance‑heavy units. Adjust quarterly.
• Cadence: a weekly 90‑minute micro‑slot for exploration tasks + a 4‑day spike week every 6 sprints. Friday reserved for demos/retros.
• Guardrails:
  • Tie eligibility to SLO health: if a service is burning >30% of error budget, its innovation budget pauses until recovery.
  • Max concurrent experiments per team: 2. Everything else queues.
  • No stealth work: experiments must have a ticket, label, and one‑page RFC.

Example budget file checked into the repo so CI can enforce it:

# .org/innovation_budget.yaml
version: 1
quarter: 2025Q4
teams:
  checkout:
    innovation_percent: 10
    max_concurrent: 2
    slo_gate:
      error_budget_burn_threshold: 0.3
  platform:
    innovation_percent: 15
    max_concurrent: 3
    slo_gate:
      error_budget_burn_threshold: 0.4

This isn’t theater: CI reads this file, checks current burn, and blocks over‑budget PRs labeled exp.

Rituals that keep it honest

You don’t need a big‑bang “Innovation Day.” You need small, boring, repeatable rituals tied to the work.

• Friday Demos (25 min, time‑boxed)

  • 5 min per experiment, max five slides or a terminal. Goal: show learning, not polish.
  • Attendees: product, engineering, security (rotating), support (optional).

• Monday Kill/Continue (15 min)

  • Every experiment gets one of: kill, continue, graduate (ship behind a flag), or archive (document + shelve).
  • Decisions recorded in a public decision log.

• RFC‑lite (one page)

  • Context, hypothesis, success metric, blast radius, rollback, budget ask.
  • Lives in the repo as rfc/exp-<slug>.md.

GitHub issue template to standardize the ask:

---
name: Experiment RFC-Lite
about: One-page experiment request
labels: [exp, rfc]
---

## Context

## Hypothesis

## Success Metric
- Primary (e.g., +10% search success, -15% MTTR)
- Guardrail (no >2% latency regression on p95)

## Blast Radius
- Env: `sandbox` | `staging` | `limited-prod` (flagged)
- Max users: <1% behind `feature_flag`

## Budget Ask
- Time: 4 days
- People: 2

## Rollback Plan

## Decision Log
- 2025-10-12: Continue for 1 week (reason...)

Slack reminder for demos (works with an incoming webhook):

curl -X POST -H 'Content-type: application/json' \
  --data '{"text":"Friday Demos in 15 min. Post links to RFCs in #exp-reviews. Agenda auto-generated from `exp` tickets opened this week."}' \
  https://hooks.slack.com/services/T000/B000/XXXX

Leadership behaviors: what you tolerate is what you get

When leaders waffle, innovation time becomes a guilt‑ridden side quest. Behaviors that have worked for me and clients:

• Protect the calendar publicly. If legal demands the spike week, you move legal, not the spike. Reschedule in the open, never silently cancel.
• Tie to business bets. Every quarter, publish 3–5 investment areas (e.g., “faster cold starts,” “privacy‑preserving analytics”). Experiments must map to a bet.
• Kill rate target. Aim to kill 50–70% of experiments. If everything continues, you’re not picking hard problems or you’re afraid to say no.
• No pet projects. Directors and above pitch like everyone else; the same RFC‑lite and demo rules apply.
• Incident gate. If Sev1/Sev2 rates spike, innovation pauses for affected teams until SLOs return to green. Announce the pause and the resume criteria.
• Promote visible learnings, not heroic hacks. Reward the team that killed a doomed idea after 3 days with a crisp write‑up.

Make it measurable (and boringly inspectable)

Skip vanity metrics like “number of ideas.” Track things you can query across tools.

• Conversion rate: graduated_experiments / total_experiments rolling 90 days.
• Time to decision: median days from RFC opened → kill/continue decision.
• Adoption: % of target services/users behind a flag after 30/60/90 days.
• SLO impact: error budget burn, MTTR deltas for services touched by exp.
• Cost guardrails: sandbox spend per experiment with a fixed cap.

Jira JQL to pull the last 30 days of experiments shipped:

project in (PLATFORM, CHECKOUT) AND labels in (exp, spike) AND statusCategory = Done AND resolved >= -30d

Prometheus to watch error budget burn for experimental traffic (assumes label track="exp"):

sum(rate(http_requests_total{track="exp",status=~"5.."}[30d]))
/
sum(rate(http_requests_total{track="exp"}[30d]))

A simple SQL model for conversion and time to decision if you log RFC events:

-- table: innovation_log (id, rfc_id, event, ts)
-- events: opened, continued, killed, graduated

WITH decisions AS (
  SELECT rfc_id,
         MIN(CASE WHEN event IN ('killed','graduated') THEN ts END) AS decided_at,
         MIN(CASE WHEN event = 'opened' THEN ts END) AS opened_at,
         MAX(CASE WHEN event = 'graduated' THEN 1 ELSE 0 END) AS graduated
  FROM innovation_log
  GROUP BY rfc_id
)
SELECT
  COUNT(*) AS total,
  SUM(graduated) AS graduated,
  ROUND(100.0 * SUM(graduated) / NULLIF(COUNT(*),0), 1) AS conversion_pct,
  PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (decided_at - opened_at))/86400) AS median_days_to_decision
FROM decisions;

OKR sketch that doesn’t game the system:

• O: Improve innovation throughput without hurting reliability.
  • KR: Convert 20–30% of experiments to shipped features with <2% p95 latency regression.
  • KR: Reduce MTTR by 15% on services touched by experiments in quarter.
  • KR: Kill/continue decisions within 5 business days (median).

Tooling: bake it into GitOps and CI/CD

Operationalize, don’t sermonize.

• Label and branch conventions

# .github/labels.yml
- name: exp
  color: 0e8a16
  description: Experimental/spike work
- name: graduate
  color: 5319e7
  description: Ready to graduate behind a feature flag

Branches: exp/<team>/<short-slug>; PRs must reference a ticket and RFC.

• CI budget gate (GitHub Actions):

# .github/workflows/innovation-budget-gate.yml
name: Innovation Budget Gate
on:
  pull_request:
    types: [opened, synchronize, reopened]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Determine team budget
        id: budget
        run: |
          TEAM=$(jq -r '.pull_request.base.repo.name' <(echo "${{ toJson(github) }}") | cut -d'-' -f1)
          PCT=$(yq ".teams.${TEAM}.innovation_percent" .org/innovation_budget.yaml)
          echo "pct=$PCT" >> $GITHUB_OUTPUT
      - name: Enforce experiment labeling and SLO gate
        run: |
          # Require 'exp' label and check SLO burn via an internal API
          LABELS=$(gh pr view ${{ github.event.number }} --json labels -q '.labels[].name')
          if ! echo "$LABELS" | grep -q "exp"; then
            echo "Missing 'exp' label for experimental PR"; exit 1; fi
          BURN=$(curl -sf https://slo-api.internal/burn?team=${TEAM})
          THRESH=$(yq ".teams.${TEAM}.slo_gate.error_budget_burn_threshold" .org/innovation_budget.yaml)
          awk -v b=$BURN -v t=$THRESH 'BEGIN{if(b>t){exit 1}}' || { echo "Error budget burn too high ($BURN > $THRESH)"; exit 1; }

• Sandbox deploys with TTL (ArgoCD ApplicationSet):

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: exp-sandboxes
spec:
  generators:
    - git:
        repoURL: https://github.com/acme/experiments.git
        revision: main
        directories:
          - path: sandboxes/*
  template:
    spec:
      project: experiments
      source:
        repoURL: https://github.com/acme/experiments.git
        targetRevision: main
        path: "{{path}}"
      destination:
        server: https://kubernetes.default.svc
        namespace: "{{path.basename}}"
      syncPolicy:
        automated: {}
        syncOptions:
          - CreateNamespace=true
      info:
      - name: ttl
        value: "168h"  # auto-cleanup in 7 days

• Cost cap via OPA (Rego policy evaluated in CI or admission controller):

package budget

deny[msg] {
  input.labels.env == "sandbox"
  cost := input.estimated_cost
  cost > 100
  msg := sprintf("Sandbox cost cap exceeded: %v > $100", [cost])
}

• Tag everything in Terraform

resource "aws_instance" "exp" {
  ami           = var.ami
  instance_type = "t3.small"
  tags = {
    owner    = var.engineer
    env      = "sandbox"
    ttl      = "168h"
    purpose  = "exp:${var.slug}"
  }
}

Case study: the spike week that paid for itself

A fintech client asked us to “bring back innovation” after freezing all spikes during an incident‑heavy year. We implemented the playbook above: 10% budget for product squads, 15% for platform, weekly micro‑slots, and a 4‑day spike week every 6 sprints. We wired SLO gates into their GitHub Actions and set up an exp-sandboxes cluster via ArgoCD with a $100 cost cap per experiment.

Three quarters later:

• Throughput: 41 experiments; 11 graduated (27% conversion).
• Reliability: MTTR down 22% on services touched by experiments; error budget burn unchanged (within ±2%).
• Business impact: Two spikes became roadmap items: a feature‑flagged query cache that cut p95 latency by 18% on a noisy endpoint, and a partial replay tool for Kafka topics that shaved on‑call toil by ~4 hours/week.
• Costs: Sandbox spend capped at $2.4k/quarter; no zombie infra thanks to TTL.

The CFO liked the monthly scorecard enough to let us keep the budget through year‑end. The VP Eng liked that kill decisions were public and fast. ICs liked not doing “secret weekend hacks.”

What I’d change next time

• Start with a smaller spike cadence (every 8 sprints) if your incident rate is volatile; earn your way to every 6.
• Add a product counterpart as co‑owner of the Friday demos so adoption doesn’t stall.
• Push harder on dogfooding: graduating behind a feature_flag only counts when two teams adopt it.
• Automate the decision log ingestion; humans forget to update spreadsheets. Pipe RFC events to a table and publish a dashboard.

Innovation is not the opposite of delivery. It’s delivery with smaller blast radii and the courage to kill fast.