What "5G core launch" actually means
It's not just "stand up a new network." A 5G core launch involves the standalone or non-standalone 3GPP core, network slicing infrastructure, edge compute integration, BSS / charging system updates, customer-facing service activation flows, network management and assurance, security operations changes, and regulator coordination. Eleven teams across software, network operations, product, security, and program management — minimum.
And the deadline doesn't move. Regulators set commitment dates; carriers commit publicly; Wall Street watches.
Lesson 1: SAFe-style PI cadence — pick it pragmatically
SAFe gets a bad rap from teams that have been forced into it without intent. For an 11-team program with hard interdependencies and a hard end date, the Program Increment cadence — 12-week increments with a planning event at the start — actually does the work it's supposed to do.
Three reasons it fits 5G core specifically:
- Increment-level alignment beats sprint-level alignment when teams are physically and organizationally distributed
- PI planning events force cross-team dependency conversations to happen with everyone in the room
- Executive sponsors review at PI boundaries, not weekly — keeps them informed without involving them in tactical decisions
Lesson 2: Dependency mapping in Miro, refreshed every PI
The dependency map is the single most valuable artifact of program management. We maintain it as a Miro board (or Mural — same idea), refreshed at every PI planning event. Every team's work for the next PI is on the board with explicit incoming and outgoing dependencies on every other team.
Three properties make it work:
- It's read-write live, not a slide-deck artifact updated by a project manager weekly
- Dependency lines are color-coded by risk — red for "this is blocking critical path," yellow for "this could become blocking," green for "managed"
- Every dependency has a named owner on each end — escalation path clear without an org chart lookup
Lesson 3: The 12-minute standup-of-standups
Daily standup of standups across all 11 team leads. 12 minutes, hard cap, no exceptions. Three questions per team:
- What shipped yesterday that affects another team?
- What's at risk today that another team needs to know about?
- What blocker do you need surfaced to the program lead?
The discipline matters more than the format. Anyone who can't answer in under a minute gets a follow-up sidebar. The standup is a status check, not a problem-solving session.
Lesson 4: Executive review rhythm
Executive sponsors get one weekly review and one monthly steering committee. The weekly is 25 minutes — RAG status, top three risks, next-week needs from sponsor. The monthly is 60 minutes — increment progress, financial position, regulator coordination, vendor status.
The trick: honest status reporting. We RAG-rate aggressively. If a stream is yellow or red, we say so — and we say so early. The cost of saying "actually we're behind" in week 6 is conversation; the cost of saying it in week 36 is the program.
Lesson 5: When the program is already behind in week three
This happens to every multi-team program. The honest move:
- Re-baseline the plan against actual capacity, not the optimistic plan you signed up for. Use real velocity from the first two weeks.
- Have the conversation with the executive sponsor immediately. Three options on the table: cut scope, add capacity, or move the date. The sponsor picks; you execute.
- Identify the one or two streams that are most behind and most leveraged. Pour senior bench into those for the next two PIs.
- Postpone any work that isn't on the critical path. Even good work. Especially good work that became scope creep.
The mistake program managers make: trying to "make it back" with overtime and team heroism. That doesn't work. It demoralizes the team and produces fragile output. Re-baseline honestly; deliver against the new baseline.
Lesson 6: Launch week is a separate program
The last six weeks before launch are run differently. Daily executive standups, hourly status during the launch window, dedicated incident management bridge open continuously. Every team has a launch runbook reviewed by program leadership.
For our launch: 5G core went live 6 days before the regulatory deadline. Zero customer-impacting incidents in the launch week. Three minor incidents (paged, contained, post-mortemed) but no customer impact. The cadence and runbook discipline made the difference.
The pattern that survives the program
The PI cadence and dependency mapping practices we installed are still being used at the operator three years later. Not because they're SAFe — they're not particularly orthodox SAFe — but because they're the rhythm that works for 5+-team programs with hard deadlines.
The lesson that's easy to underestimate: the operating cadence matters more than the methodology label. Pick the cadence; install the discipline; let the team find their version of it.