---
title: "Shift-Left Performance: Who Owns the First k6 Script in a Product Team?"
description: "Shift-left performance with k6: DRIs, CI thresholds, and who owns the first script—SRE workbook culture meets k6 automation."
publishDate: "2026-10-08"
draft: false
keyword: "shift left performance testing"
intent: "TOFU"
cta: "Explore how Performate simplifies k6 load testing—from imports to results—so your team ships performance confidence faster."
tags: ["k6","load-testing","api-performance","shift","left","performance"]
---

Platform emails say “shift-left performance,” but the new checkout service ships without a single k6 file in its repo. Postman collections exist; CI runs unit tests; and the first production incident becomes a debate about who should have load-tested—platform, SRE, or the squad that owns the feature.

Shift-left only works when **ownership is named before scale**, not assigned after an outage. This guide defines who owns the first k6 script in a product team, what that script must cover, how it graduates to CI, and which rituals keep it from rotting when the DRI rotates.

## Why the first script owner matters more than a perf guild

Guilds and centers of excellence help with templates and training—they do not replace a **directly responsible individual (DRI)** on the squad that changes the API every sprint ([SRE workbook culture](https://sre.google/workbook/)).

- **Feature squads** know which endpoints moved and which auth flows broke.
- **Platform** provides secrets management, runner capacity, and golden templates—not every scenario.
- **SRE** defines SLO math and reviews error-budget burn; they should not be the only author of squad scripts.
- **QA** validates that reports map to acceptance criteria stakeholders already use.

The first script is intentionally small: **readiness + one golden business path** (for example login → read → write), not a whole-system simulation. Scope creep on day one is why teams never start.

### When “platform owns perf” fails

Handoffs without a squad DRI mean scripts live in a orphaned repo, thresholds reference retired URLs, and CI secrets expire silently. The fix is not more meetings—it is a smoke scenario tagged with `owner:checkout` in k6 and a name in `SERVICE.md`.

Pair ownership with [quarterly scenario health checks](/en/blog/quarterly-k6-scenarios-health-check) so the first script becomes a maintained asset, not a one-off hero run.

## Practical k6: squad-owned smoke with promotion path

The DRI ships a smoke script in sprint one, then promotes the same file to CI after two green desktop runs.

**Example script (illustrative).** Adapt routes and auth to your service.

**What this example demonstrates:**

- **Low blast radius:** `per-vu-iterations` with 3 VUs proves wiring before ARR tests.
- **Owner tags:** `owner:checkout` (via env) shows up in reports and on-call filters.
- **Readiness + business path:** `/ready` then `/api/orders` catches “up but useless.”
- **Threshold on errors only** at smoke stage—add latency thresholds when baseline exists.

```javascript
import http from 'k6/http';
import { check, sleep } from 'k6';

const BASE = __ENV.API_BASE || 'https://staging.example.com';
const SQUAD = __ENV.SQUAD || 'checkout';

export const options = {
  scenarios: {
    squad_smoke: {
      executor: 'per-vu-iterations',
      vus: 3,
      iterations: 5,
      tags: { owner: SQUAD, suite: 'smoke' },
    },
  },
  thresholds: {
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const ready = http.get(`${BASE}/ready`, { tags: { route: 'ready', owner: SQUAD } });
  check(ready, { ready: (r) => r.status === 200 });

  const orders = http.get(`${BASE}/api/orders`, {
    headers: { Authorization: `Bearer ${__ENV.TOKEN}` },
    tags: { route: 'orders', owner: SQUAD },
  });
  check(orders, { orders_ok: (r) => r.status >= 200 && r.status < 500 });
  sleep(0.5);
}
```

**Patterns that work**

- Same Postman folder the squad already maintains → import instead of rewrite ([Postman to k6](/en/blog/postman-to-k6-step-by-step)).
- Promote to [smoke/load CI profiles](/en/blog/smoke-load-stress-ci-pipeline) only after two green runs on the same commit.
- Add `p(95)` thresholds when product agrees on a number—not before.

**Anti-patterns**

- Waiting for a dedicated perf hire before any script exists.
- Platform team writing scripts without squad review—drift in auth within two sprints.
- 500 VUs on first run—use [VU and think-time sanity](/en/blog/virtual-users-think-time-ai-sanity-checks) before scaling.

## Decision framework: who does what at each maturity stage

| Stage | Squad DRI | Platform | SRE |
|:---|:---|:---|:---|
| New service (sprint 0–2) | Author smoke; run locally | Provide template + secrets | Agree SLO candidate |
| GA approaching | Add steady ARR scenario | Wire CI runner | Review threshold vs error budget |
| Shared API consumed by many | Extend platform template | Own breaking-change notice | Monitor tail across squads |
| Regulated data | Co-sign synthetic data only | Enforce no-prod-data policy | Audit trail of runs |

**Escalate to platform** when runners, secrets, or shared templates block progress—not when the squad is unsure which route matters.

**Escalate to SRE** when thresholds need error-budget math or incident correlation—not to write the first smoke for every team.

## Observability, documentation, and next steps

- [ ] Record DRI name and backup in `SERVICE.md` or team handbook.
- [ ] Link k6 workspace or repo path in the service README.
- [ ] Add smoke job to CI within two sprints of service creation.
- [ ] Archive first green export with git SHA for future regressions.
- [ ] Schedule quarterly health review of smoke + steady scenarios.

## How Performate enables shift-left ownership on the squad

**Example: checkout squad ships week-one smoke**

1. **Import** the squad’s Postman folder on day one—no waiting for platform glue code. *Problem solved:* DRI starts from requests they already curate.
2. **Create** `squad_smoke` in the visual editor with owner tag `checkout`. *Problem solved:* tags match the k6 model above without YAML typos.
3. **Run** locally against staging; fix env secrets in Performate profiles. *Problem solved:* faster loop than hand-editing `.env` per developer.
4. **Add** `http_req_failed` threshold; later add `p(95)` when SLO number exists. *Problem solved:* progressive gates without new files.
5. **Export** k6 to the service repo; platform wires CI using the same file. *Problem solved:* one artifact from desktop to pipeline.
6. **Hand off** PDF export to on-call runbooks with route tags for incidents. *Problem solved:* perf evidence lives where responders already look.

## Closing takeaway

Shift-left performance is a **named owner plus a smoke script**, not a department slogan. Nominate the squad DRI, ship readiness + one golden path this sprint, and promote to CI only after evidence—not aspiration.

Add the DRI name to `SERVICE.md` today and run the smoke once before the next planning meeting asks for “perf confidence.”

[Try Performate free](https://performate.app) | [Guides](/guides) | [Book a demo](/demo)