Calibrated quality + the political layer

Why Week 5 is the political week

Weeks 1–4 installed the practice inside your team. Week 5 is about defending it from the surrounding org — from adjacent teams whose processes assume the old rhythm, from management whose mental model of “engineering velocity” was set before any of this existed, from external surfaces (customers, partners) where polish actually does matter and you can’t ship rough.

Four things to install this week:

1. Calibrated quality — per-surface polish, not blanket polish.
2. Cross-team independence via mocks / replicas / test harnesses, so slower adjacent teams don’t cap your velocity.
3. Pushing back on processes that assume hand-crafted code, with four weeks of evidence.
4. Trust each other to ship — the cultural shift inside the team that makes the rest survive.

None of these are mechanical installs. They’re conversations, calibration calls, and political work. If Week 4 was the technical-throughput chapter, Week 5 is the organisational-throughput chapter — and it’s where most teams discover that the constraint on their AI-native practice was never the technology.

1 — Calibrated quality per-surface

Last week installed rough-first-pass into your team’s reflexes. Without Week 5, the rough-first-pass habit bleeds into surfaces where it shouldn’t — customer-facing UI, partner-facing API contracts, public release notes, investor demos — and damages the external perception of the team’s output even while internal velocity is up.

The discipline this week: calibrate the polish bar per surface, not per organisation. Different surfaces have different polish bars, set by who consumes them.

Internal surfaces — rough is fine:

• Prototype branches, exploratory PRs, internal-only tools.
• Internal-team docs, spec drafts, decision notes.
• Anything where the consumer is you or your immediate team and feedback can be informal.

External surfaces — polish bar is high:

• Customer-facing UI changes, especially anywhere the customer perceives the brand.
• Partner-facing API contracts (you can’t change them as easily as internal ones).
• Public release notes, customer-facing changelogs, marketing collateral.
• Anything an external audience sees: the polish bar is high because real-deal feedback only flows past real-deal surfaces. Rough output here teaches your customers that you ship rough.

The intermediate surfaces — case-by-case:

• Cross-team PRs to other internal teams: usually polish-leaning, especially if the other team is more traditional.
• Documentation for internal use that might later become external (READMEs in repos that may be open-sourced): polish it once when the audience shifts, not while it’s still internal.
• Operational artefacts (runbooks, incident postmortems): polish-leaning, because they get consulted under pressure.

The trap to avoid: blanket-polishing everything because the team has been criticised for shipping rough. The correct response to that criticism isn’t “polish more on average,” it’s “polish the right things, and leave the internal surfaces rough so the iteration speed compounds.”

An agent helps here too: a Claude Code skill that runs on every PR and asks “what’s the consumer of this change? does the polish level match?” surfaces the calibration questions for the human reviewer.

2 — Cross-team independence

The most common organisational ceiling on AI-native velocity isn’t your team. It’s the upstream team your team depends on — the platform team that’s still on quarterly cycles, the data team whose pipeline takes weeks to update, the design system team that ships once a sprint.

The pattern: spin up copies of what slow upstream teams provide, iterate against your copies, integrate with evidence.

What this looks like:

• Need a new endpoint from the platform team? Build a mock that returns the response shape you want, code against the mock, ship the feature behind a flag. When the real endpoint lands, swap the mock for the real one. You weren’t blocked.
• Need a new design pattern from the design system? Build a local version using your own design tokens, ship the feature, propose the pattern back to the design team as a proven case.
• Need a new data column? Build a local replica of the data flow with synthetic data shaped like what you need. Iterate against the replica. When real data lands, plug it in.
• Need a feature toggle infrastructure your platform team hasn’t built? Use a local config file as a flag interim. Migrate to platform later.

The political dimension:

When you bring the integration request back to the upstream team, you arrive with concrete evidence: “we already tried this on our side, here’s the shape we need, here’s what works, here’s the test harness you can use to validate.’’

This is dramatically more useful than “please add this endpoint to your backlog.” The upstream team gets a worked example, you get a credible position (“we’ve done our part, we’re waiting on yours”), and the integration happens faster than it would have without the mock work.

What this isn’t: a license to fork every shared dependency. The mock / replica is interim, not permanent. When the upstream lands, you migrate. The discipline is interim work to unblock, not parallel-stack proliferation.

3 — Pushing back on processes that assume hand-crafted code

By Week 5 you have four weeks of evidence about what your team is shipping at AI-native velocity. That evidence is the lever for the conversations with adjacent functions / managers / process owners about processes that no longer fit.

Processes commonly worth pushing back on:

• Story-pointing every PR. At 5× the PR volume, story-pointing becomes pure overhead. The estimates aren’t useful at this granularity.
• Two-week sprint planning ceremonies. Compressed-cadence planning (NEXT-STEPS.md, weekly rolling) makes sprint planning redundant. Often the right replacement is a 15-minute Friday cohort planning slot, not a 1-hour Monday sprint kickoff.
• RFCs for changes that can be tried in an afternoon. The cost of RFC ceremony scales with PR volume. Reserve RFCs for genuinely architectural decisions where multiple teams need to weigh in — not for every cross-cutting tweak.
• Per-PR security review by humans. Reserve human security review for PRs touching the security-sensitive surface (auth, secrets, data boundaries). Automate everything else.
• QA sign-off as a release gate. If you have agent-driven release verification (Week 3), QA sign-off becomes a quality-design role, not a per-release gate.
• Quarterly OKRs at the team level. Compressed-cadence makes quarterly OKRs feel six months stale. Some orgs need the quarterly OKR for org-wide alignment — if so, keep the once-a-quarter ceremony but don’t let it drive team-level planning between quarters.

How to push back well:

• Lead with evidence, not opinion. “Our team shipped N PRs last month under the new process; here’s the throughput trend; here’s what the process is now costing per PR; here’s what we’d propose instead.”
• Frame as proposal, not demand. The ask is “can we try X for two months and measure?” not “we’re no longer doing Y.”
• Acknowledge what the process was solving for. Story-pointing wasn’t invented for no reason. Show that your proposed replacement still solves the underlying need (predictability, estimation, cross-team coordination), just differently.
• Be patient. Process change in established orgs takes months, not weeks. The conversation in Week 5 is the start; the resolution is usually a quarter or two later.

4 — Trust each other to ship

The cultural shift that has to land inside the team for everything else to compound: PR-merging each other’s work without re-litigating direction.

Old pattern: every PR is a conversation about whether the approach is right, whether the abstraction is correct, whether the test coverage is appropriate. Code review as design review.

New pattern: design decisions are made before the PR (in NEXT-STEPS.md, in async cohort discussion, in the Week 1 planning ritual). Code review checks that the PR implements the agreed direction correctly, not whether the agreed direction was the right one.

The mechanism: the team agrees that direction-setting happens upstream of PRs. Once a direction is agreed (in whatever lightweight forum the team uses), PRs that implement it are merged with brief review, not re-debated. If a PR reveals that the agreed direction was wrong, that goes back to direction-setting — and the PR either gets revised or shelved — but the re-litigation happens in the appropriate forum, not in the PR’s comments.

This shift is mostly conversation and worked examples with the team. It’s also the place where senior-engineer-as-gatekeeper identity has to soften — because if every senior is re-litigating every direction in PR review, the throughput gains evaporate.

This week’s assignments

Self-check — did this week land?

• Can you articulate, per-surface, which polish bar applies to which work in your team’s current flow? Or are you applying one polish bar to everything?
• Have you spun up at least one mock / replica that unblocked your team from a slower upstream team?
• Have you formally proposed pushing back on at least one process that assumes hand-crafted code? And had the conversation with the relevant decision-maker?
• Is the team starting to PR-review each other’s work without re-litigating direction? Or are direction debates still happening in PR comments?
• Friday demo + weekly planning still running. By Week 5 the team should be visibly shipping at higher velocity than Week 1 — even if the dip from Week 4 hasn’t fully cleared yet.
• You’re noticing where the org friction lies. That noticing is the input to Week 6’s graduation demo and the post-bootcamp playbook.

Why the political work is half the bootcamp’s value

Engineers often discount the political layer as “not real work.” The whole-bootcamp experience usually convinces otherwise: technical throughput gains that aren’t defended politically get reverted within a quarter, either by adjacent-team pushback or by management discomfort with the visible change.

Week 5 isn’t a digression. It’s the half of the practice that determines whether the technical work compounds beyond the team’s walls or stays a siloed experiment that gets walked back.