Augmented Mind · Course · For engineering leaders

Cross-org political layer + team composition

A supplement to the six-week course for tech leads and engineering managers. Two things bite once your team is internally AI-native, and neither is covered in depth inside the main weeks: operating inside a non-AI-native organisation, and the team-shape / hiring-filter question.

Read this after the course (or alongside Week 5 if you’re already noticing the cross-org friction starting to bite).

Why this is a supplement, not a week

The six-week course is scoped to the team’s own practice. That’s deliberate — you can’t change the surrounding org until your own team is actually shipping at AI-native cadence. But once you are, two things become the new bottleneck. Both of them sit above the team-internal work the course teaches, and both are mostly tech-lead and EM problems rather than IC problems.

The two halves of this supplement:

  1. Beyond the team — operating inside a non-AI-native organisation. Once your team is internally great, your bottleneck moves outside it.
  2. Team composition + the hiring filter. The team-shape question that doesn’t surface until you’re already running.

Part 1 — Beyond the team: operating inside a non-AI-native org

Where the new bottleneck is

The first six months of installing AI-native practice inside a team feels like the whole problem. It isn’t. Once your team is shipping at 5× the old cadence, four kinds of friction surface that weren’t visible before:

  • Inflow funnel can’t feed delivery cadence. You’re shipping faster than product / design / discovery can hand you the next thing to build. The team idles, the velocity gets invisible, leadership wonders if the practice is even working.
  • Dependencies sit in teams that still plan in quarters. Your team needs a new endpoint / a new design-system pattern / a new data column from an adjacent team. They’re on the old cadence. Your work blocks waiting.
  • Every cross-team integration becomes a friction surface. The speed differential between your team and adjacent teams becomes visible to people who didn’t see it before. Some of them feel threatened. Some feel exposed. Some try to slow you down.
  • Defending the practice with skeptics in positions of power. Procurement, security review, architecture review boards, change advisory boards — the gates that traditional engineering funnels through. None of them were designed for the cadence you’re operating at.

The cross-org work is what determines whether the practice you installed inside the team actually gets to compound at the organisation level. Skip this and the throughput stays trapped inside the team boundary.

Technique 1 — Share agent-level access with adjacent teams

The fastest way to neutralise the speed-differential friction: give adjacent teams the same agent-level tools your team has been using. Not training, not evangelism — just access.

Concrete examples:

  • The design system team that ships once per sprint gets access to a Claude Code session pointed at their repo, with your team’s skill library accessible. They start shipping daily instead. Your dependency on them shrinks.
  • The QA team that’s on a one-week review cycle gets your release-verification skills. They start using them on PRs they review. Their cycle time drops.
  • The platform team that takes two weeks per endpoint gets your scaffolding skills + your test harnesses. Their per-endpoint cost drops.

This isn’t altruism. It’s removing the external bottleneck your own team is now hitting. The faster the adjacent teams move, the less your throughput is capped by their cadence.

The objection you’ll hear: “they need training first.” Sometimes. More often, access + a worked example + 30 minutes of show-and-tell is enough. The training-first instinct is usually a delay tactic from someone who doesn’t want to lose the gating role.

Technique 2 — Replicas / mocks to stay out of human-paced critical paths

Already taught in AM Week 5 (cross-team independence) at the team-internal level. At the cross-org level, the pattern extends:

  • The data team is six weeks out on a schema change. Build a local replica of the data shape. Iterate on your features against the replica. When the schema lands, swap the source. You weren’t blocked.
  • The platform team takes a month to add a new feature flag. Use a config file as a local flag. Migrate to the platform when it’s available. You weren’t blocked.
  • The compliance team needs a new audit trail format. Build the audit-log generation locally. When the compliance tooling catches up, point the team there. You weren’t blocked.

The cross-org version of this also has a political dimension: when you bring the integration request back to the upstream team, you arrive with concrete evidence (“here’s the shape we need, here’s the harness you can use to validate”) rather than as one more ticket in their backlog. This dramatically changes the negotiation.

Technique 3 — Evidence-based selling to skeptics

Most cross-org skepticism takes one of three shapes: “you’ll ship more bugs,” “your code is unmaintainable,” “you’re burning yourselves out.” All three are answered by the same kind of evidence:

  • Production incident rate. Should be flat or down. If it’s up, the 10×-everything chapter (AM W3) didn’t fully install — revisit before defending.
  • Code-quality artefacts. Coverage, documentation completeness, ADR rate. Should be up, because agents are diligent about documentation-as-they-go in ways humans usually aren’t.
  • Per-engineer sustained throughput over months. The honest number, not the peak. At 4-engineer team scale, the F-Secure team I work with has sustained 400+ PRs/month for nine months without engineer attrition.

The pattern: don’t debate the model in the abstract. Bring the data, in the format the skeptic cares about. Process change in established orgs takes months. Evidence accelerates it; rhetoric stalls it.

Technique 4 — Defending the practice in public

The conversations you’ll have repeatedly:

  • “Aren’t you concerned about copyright / IP / liability around AI-generated code?” Specific, useful answers: Anthropic’s terms, your org’s AI-use policy, the audit trail of agent activity, the security review patterns already in place. Have these answers rehearsed.
  • “Won’t this make engineers obsolete?” The framing from AM Week 3 — “you remain essential” — was written for this conversation. Use it.
  • “What happens when the AI hype cycle ends?” The practice is capability-compounding regardless of vendor cycles. The substrate (repo-as-context, compressed planning, transcription-fed decisions, parallel work-streams) is durable. The current best-of-breed agent will be replaced; the operating model won’t.
  • “Show me one team that’s been doing this for a year and is still doing it.” Increasingly easier to answer. Nine months in at F-Secure with stable headcount and growing throughput. Your team’s own track record becomes the answer over time.

Part 2 — Team composition + the hiring filter

What team shape works at AI-native velocity

The team-shape question doesn’t surface explicitly in the six-week course because the course is engineer-shaped: it assumes you’re working with the team you have. Once you’re past the install and you’re hiring or restructuring, shape matters.

From the F-Secure team and the engineering teams I’ve coached:

  • 4–8 people is the sweet spot. Below 4, cross-stream learning doesn’t compound enough to justify the team-level rituals. Above 8, the coordination cost between operators starts to grow faster than the throughput, and the daily ambient sync becomes too noisy to be useful.
  • Senior multi-disciplinary operators as the core. Engineers who can guide outcomes across two or three verticals — backend + frontend + data, or backend + DevOps + security — not single-specialist deep-stack experts. The reason is in the next bullet.
  • Five experienced people running ten parallel work-streams beats ten juniors needing guidance. The coordination cost of less-experienced operators with lots of AI agents outruns their leverage at scale. A junior engineer running 8 parallel sessions produces more brain-fry for the tech lead than they produce throughput for the team. This is the single least-intuitive shape decision for managers used to ramping juniors as the throughput lever.
  • Mix in some less-experienced people willing to learn the agent-herder role. Not zero juniors — they’re the pipeline. But the team math depends on the senior:junior ratio staying meaningfully senior-heavy during the first 9–12 months of the practice installing.

The hiring filter

What to screen for when hiring into an AI-native team. Most of these are temperament markers more than skill markers:

  • Multi-disciplinary range. Has the candidate shipped meaningful work across at least two verticals (backend + frontend, or backend + data, or full-stack + infra)? Single-vertical deep specialists struggle in the cross-discipline expansion that AM Week 4 makes default.
  • Tolerance for unfinished work in flight. Some engineers have a deep need for all their work to be polished and shippable at all times. Others are comfortable with half-finished, low-quality, rough-iterated stuff sitting around. The second group survives Week 4 (the low-quality phase); the first group bounces back to single-tasking.
  • Externalisation reflex. Do they write things down naturally? Do they keep notes, update docs, capture decisions? The whole repo-as-context pattern depends on this. Engineers whose default is to hold context in their head struggle to operate at fleet scale.
  • Comfort with being mid-debate, not mid-edit. The AI-native engineer spends a lot of time arguing with agents, re-prompting, course-correcting. Engineers who get satisfaction from typing struggle. Engineers who get satisfaction from problem-solving thrive.
  • Self-awareness about brain-fry. Ask a candidate when they last hit a cognitive wall and what they did about it. Engineers who answer with self-aware specifics (“I noticed I was looping at X PM, took a walk, came back to find I’d been over-engineering”) are the candidates who’ll survive AH Week 5. Engineers who answer “I just push through” are signaling future burnout.
  • Curiosity about the practice itself, not just the tool. “I love Claude Code” is fine but not enough. The candidates who do well are interested in how engineering work itself is changing, not just in which model is best this month.

Onboarding new hires into the practice

For new hires joining an already-AI-native team:

  • Assign the AM Course in their first 6 weeks. Not as homework on top of work — as the way you onboard them. Run the preflight in week 1, run the six weeks alongside their first real work. The course is explicitly designed to install while real work is happening.
  • Pair them with a senior operator running ~10 parallel sessions. Not for code mentorship — for fleet-orchestration modelling. Watching someone operate at 10+ streams for a few days is irreplaceable.
  • Don’t expect throughput parity in month 1. A new hire at an AI-native team ramps in 3–6 months, not 6 weeks. The first month is mostly substrate acquisition. Plan headcount accordingly.
  • Don’t skip the Friday ritual. The new hire’s first Friday demo + planning session is when the practice actually starts compounding in them. Make it non-optional.

How this connects back to the main course

Both parts above sit on top of the six-week curriculum. Read order:

  1. Run the AM Course end-to-end yourself.
  2. Get your team through it (whether via the free course or the paid Bootcamp).
  3. Then come back to this supplement when the cross-org friction starts showing up.

Reading this supplement before installing the team-internal practice produces engineering leaders who can talk about AI-native engineering but haven’t shipped at AI-native cadence. The cross-org work is meaningless without the team-internal substrate. Skip the substrate; the supplement reads as theory.