PE Apprenticeship

A product engineer apprentice is an engineer in training, grown from intern to mid. On the ladder the climb is intern, junior, mid, each rung defined by how much ambiguity you take on. This is the model for that apprenticeship, day to day.

It rests on one split. Your senior, a senior engineer or the CTO you pair under, owns the judgment: the architecture, the hard technical calls, the bar for done-right. You own the execution that makes it real, and by doing it you learn the judgment. Over the first months the line moves: the senior hands you more ambiguity as you show you can absorb it.

Day to day, you do not just write code. You take a scoped piece and own it end to end: understand it, build the smallest thing that solves it by directing AI, verify the output is right, ship it small and safe, and own it in production.

The split, stage by stage

Product work runs a loop: Discover, Define, Build, Launch, Learn. At each stage the senior owns the call and you own the work that makes it real.

Discover, you understand before you build

The problem is framed by the senior and PM. Your job is to understand it before a line is written: read the system it touches, ask what is actually being asked and what it will cost. The instinct to resist is jumping to code. The fastest engineers are the ones who understood the problem first.

Define, you surface the constraints

Engineers must be in the room in Define, not handed a spec at the end. You see what PMs and designers cannot: the constraint, the simpler approach, the thing that is cheap now and expensive later. You help turn the problem into a definition doc precise enough to build against.

Build, you drive AI and verify

Development is AI-first: the target is 80% or more AI-generated code. Your job is not to type, it is to direct the AI against the definition doc and to make sure the output is right, correct structure, readable, maintainable, and to catch what it gets wrong. You ship in small PRs behind flags. This is where the craft compounds.

Launch, you ship it safely

The plan was made in Define. You ship behind a flag, instrumented and watched, mitigate before you investigate, and confirm it landed. You own it in production, not just the PR.

Learn, you reason about what happened

A short, honest retro, done together. You bring what broke and why, reasoned from first principles rather than the first guess. That reasoning is the difference between fixing a symptom and fixing the cause.

How we actually build

The craft you are here to learn, in four habits. They hold from day one.

You are not measured by lines written. You are measured by whether the smallest right thing shipped and stayed up. The fundamentals underneath, how systems run and talk, data and complexity, directing AI well, are what make the loop fast, and they do not expire.

The apprenticeship arc

The split moves as you earn it. That movement is the apprenticeship.

• Intern: given a clear problem, solution, and guidelines, you execute the task and ship it.
• Junior: you own a scoped task without step-by-step direction.
• Mid: you turn a symptom into a problem and a Build-ready definition. That is the step where you start doing the senior’s half.

You are hired at intern because the craft is learnable, and the fastest way to learn it is to do the real work right next to someone who already has it.

The first 180 days

What you can do unsupervised by each date, not a checklist to race through. The day-90 checkpoint is where we make an honest call together.

• Day 7, first prod ship. One small, real change is live behind a flag, verified. Small, but you have gone once around the loop: understand, build, verify, ship.
• Day 30, you own a task. You take a scoped task end to end without step-by-step direction, direct AI and verify its output, and ship small PRs behind flags by default.
• Day 90, the checkpoint. You are starting to turn a vague ask into a plan. The honest call together: on track for junior, extend the runway, or stop. Never a surprise.
• Day 180, you clear junior. You own scoped tasks unsupervised and are on track to mid, where you start turning symptoms into Build-ready definitions.

What you walk away with

Succeed here and you can succeed almost anywhere, because the apprenticeship builds what does not expire:

• Fundamentals, how systems run and talk, data and complexity, decomposition, debugging from first principles.
• The craft of directing AI and owning the output, not accepting whatever it produces.
• Ownership of production, not just the pull request.
• The habit of understanding before building, which is most of what separates a strong engineer from a fast typist.

None of these belong to one company or one framework. Frameworks expire; these compound. That is the point of the apprenticeship: not to fill a seat, but to grow an engineer who could run this themselves.

Guardrails

These hold for the whole apprenticeship. They are what make it safe to hand someone prod access on day seven. Walk them on day one.

• No production data. Ship code to prod, yes. Read prod data, no. No production database credentials, no customer records, no PII. Build and test against local and staging with seed data.
• No production secrets. No prod credentials, API keys, or env access. If a task looks like it needs them, it does not; escalate to the buddy.
• Never commit to main. Every change is a branch and a PR. No exceptions.
• Small PRs, behind flags. One change per PR, small enough to review in a sitting. Anything user-facing or risky ships behind a flag, off by default.
• Every PR reviewed before merge. The buddy reviews all of an apprentice’s PRs for at least the first 60 days. CI green, no self-merge.
• Low blast radius first. Early work is reversible and contained. No destructive migrations, no infra, auth, or billing paths, unpaired.
• Ask before the irreversible. Anything hard to undo gets a second pair of eyes before it runs.

The 1:1 cadence

Two loops, tuned differently. The buddy loop is daily and tapers as autonomy shows; the manager loop is lighter and steady.

With the onboarding buddy, daily then tapering. This is where the norms transfer before the apprentice has their own sense of what good looks like here.

Daily stops being daily when the apprentice no longer needs it, not on a fixed date. The signal to step down is that they stop arriving with blockers they could have cleared themselves.

With the manager, weekly then biweekly.

• Weeks 1 to 4: weekly. Growth and fit, not task status; the buddy owns the day to day. Uses the Product Engineer radar: feed the spike, clear the one blocker holding them below the next rung.
• Week 5 on: biweekly. Same shape, run per Leading People.

Day one

The Slack messages for a new joiner’s first morning: one for the team channel, one as a direct message. Copy, fill in the brackets, and post. Post the channel message and send the DM around the same time, so the first thing they see is a friendly hello, not a task.

:wave: Everyone, please welcome *[name]* to the team!

[name] is joining as *[role]* and will be working on [team or area]. [One line on their background or something they have built that we are excited about.]

*[buddy name]* is their onboarding buddy, so you will see them pairing this week. If you cross paths, say hi and help them feel at home.

[name], welcome aboard. We are glad you are here. :tada:

Hi [name], welcome to Systeric! :tada:

Really glad to have you. A few things to get you started:

- Your onboarding buddy is [buddy name]. They are your first stop for anything, no question too small.
- We will do a quick 1:1 [today or tomorrow] to say hi properly and walk through your first week.
- Everything for the first stretch is in your onboarding plan: [link]

No pressure to hit the ground running. Take the first days to get set up and meet people. Excited to build with you.

Per-person tracker

Copy this into a fresh doc for each apprentice. It is the working record: milestones, the guardrail acknowledgement, the two 1:1 logs, and the day-90 decision.

# PE Apprenticeship Tracker

**Apprentice:** [name]
**Start date:** [date]
**Onboarding buddy:** [name]
**Manager:** [name]

## Milestones

_What they can do unsupervised by the date._

- [ ] **Day 7** ([date]): first prod ship end to end (branch, PR, review, green CI, merge, deploy, verify live)
- [ ] **Day 30** ([date]): owns a scoped task without step-by-step direction
- [ ] **Day 90** ([date]): decision checkpoint (see below)
- [ ] **Day 180** ([date]): clears the junior bar

## Guardrails

_Walked and acknowledged on day 1._

- [ ] No production data or secrets; local and staging seed data only
- [ ] Never commit to main; every change is a branch and a PR
- [ ] Small PRs, behind flags, off by default
- [ ] Every PR reviewed by the buddy before merge (first 60 days); CI green; no self-merge
- [ ] Low blast radius first; ask before anything irreversible

## Buddy 1:1 log

_Daily, then tapering._

| Date | Blocked on | Shipped | Notes |
|------|------------|---------|-------|
|      |            |         |       |

## Manager 1:1 log

_Weekly for weeks 1-4, then biweekly. Feed the spike, clear the one blocker._

| Date | Spike / focus | The one blocker | Standing | Notes |
|------|---------------|-----------------|----------|-------|
|      |               |                 |          |       |

## 90-day decision ([date])

**Decision:** on track / extend / stop

**Evidence** (one concrete moment per attribute):

_The call should not surprise them: their standing has been named in the weekly 1:1s since week 3._

Related: Product Engineer, Discover, Define, Build, Code Review, Using AI Well, Hiring & Internship