Delivery competence concentrates by default: one or two people accumulate the estate in their heads, everyone else routes around them, and the bus factor quietly becomes the biggest single risk in the stack. Training fixes it — but only training with a definition of done. This 30-day plan takes an engineer from spectator to safe pair of hands, one week per layer, ending in a sign-off checklist rather than a feeling.
What “trained” means: the competence list
Write the destination first. A delivery-competent engineer can: explain the estate’s shape from the one-pager without reading it aloud; read a CDN log line and say what happened to that request; diagnose the big three symptoms (slow, erroring, stale) to the right layer using the triage flow; execute the routine operations — a purge done right per the purge guide, a config change through the pipeline, a cert status check; and act correctly in the first fifteen minutes of the two rehearsed emergencies (CDN outage, traffic spike/attack) — meaning: find the runbook, make the first assessment, escalate to the right person. That list, adapted to your estate, is the sign-off sheet; everything below exists to get someone through it honestly.
Week 1: concepts and the estate tour
Days one and two are concepts calibrated to your stack, not a generic CDN course: how caching actually decides (keys, TTLs, the Cache-Control contract), what a request’s full path looks like through your layers, and the vocabulary the team uses daily. Days three to five are the estate tour: walk the one-pager hostname by hostname — here is what fronts it, here is its origin, here is why that oddity exists — then the guided tour of each provider console (read-only access granted day one), the monitoring dashboards with last month’s real graphs, and one storytelling session that no document replaces: the senior person narrating the estate’s three formative incidents, because institutional scar tissue is a curriculum. Homework that makes it stick: the trainee re-draws the estate diagram from memory and presents it back on day five; the gaps in the drawing are week one’s remaining agenda.
Week 2: tooling, hands-on
Week two puts hands on every tool against real (read-only or staging) systems. Logs: pull and filter real edge logs, answer five prepared questions (“what was our hit ratio on this hostname yesterday? which paths 404ed most?”) — the exercises write themselves from the logging guide. Dashboards and alerts: trace each configured alert to what fires it and who receives it, and watch one day’s traffic curve with someone narrating what normal looks like — baseline intuition is trained, not documented. Purge and config: execute both on staging hostnames end to end, including verifying the result at the edge, not just submitting the request. External verification: use curl and the synthetic tools to answer “what is this hostname actually serving, from where, over what protocol” — the habit of checking reality from outside, which underpins every diagnosis they will ever make. Each exercise produces an artifact (a query, a screenshot, a note) reviewed in a Friday half-hour.
Week 3: real changes, supervised
Week three crosses into production, deliberately and shadowed. The trainee takes three to five real, low-risk tickets from the normal backlog — a TTL adjustment, a header rule, a purge request, a new path rule — and drives each through the full change process (intent edit, review, staging, tests, production, verification) with a supervisor reviewing but not touching; per the sync discipline if you run multiple platforms, which doubles as learning why the process exists. Add two shadowing shifts: the trainee sits secondary on-call, reading along with whatever arises, and attends the week’s operational review to see how the team reasons about the graphs. The teaching point of week three is calibrated confidence: the goal is an engineer who knows both how to make a change and how much checking a change deserves — the second half being the part that prevents incidents.
Week 4: drills, sign-off, and keeping it alive
Week four is rehearsal. Two tabletop drills, run realistically from the runbooks: a CDN outage scenario (probes red, diagnose, walk the playbook’s decision tree, execute the drill-safe steps) and a spike/attack scenario against the spike checklist — trainee driving, supervisor injecting complications, both debriefing against the runbook afterward (drills also test the runbooks; expect edits). Then the sign-off: walk the section-one checklist item by item, honestly — gaps get a targeted extra week, not a shrug. Keeping competence alive afterward is cheaper than building it: the trainee joins the on-call rotation as secondary within a month (knowledge unused is knowledge on a half-life), takes a seat in the next quarterly audit or failover drill, and — the best retention trick in the book — trains the next person, because nothing consolidates an estate in a head like explaining it to the head after that.