Enterprise analytics · Amgen · Current

Building the program behind the platform.

A $5M+ Amplitude initiative needed the governance, delivery rhythm, and decision system that would let more than 20 specialists operate as one program.

$5M+Program scope
20+Cross-functional team
0→1Operating model

Activity needed a system.

The platform was only one part of the problem. The program also needed a shared way to turn business intent into trusted, launch-ready analytics.

Strategy, engineering, analytics, QA, and client teams each owned critical work. Without common governance, decision rights, readiness criteria, and a visible route through dependencies, local progress could still produce program-level uncertainty.

My mandate was dual: lead delivery and build the program infrastructure itself—while the work was already moving.

Confidentiality boundary

Client data, internal architecture, and proprietary artifacts are intentionally generalized. The operating decisions, ownership model, scale, and working principles are represented faithfully.

One route from intent to evidence.

I designed the model around the handoffs where enterprise analytics work most often loses clarity. Every stage needed an owner, a decision, an entry condition, and a definition of ready.

01 / FrameBusiness outcome

Translate priorities into measurable scope and explicit decisions.

02 / OrchestrateDelivery path

Connect strategy, requirements, engineering, analytics, and QA.

03 / ValidateTrusted signal

Make instrumentation, testing, and acceptance visible end to end.

04 / LaunchReadiness

Surface dependencies, risks, approvals, and the next owner.

Operating artifact indexGeneralized view
01

Governance map

Forums, decision rights, escalation paths, and the altitude of each conversation.

02

Integrated roadmap

One view of milestones, dependencies, releases, and readiness across disciplines.

03

Executive signal

A concise view of outcomes, changes, decisions, risks, and intervention needed.

04

RAID & decision system

Named ownership, due dates, consequence, and a reliable closure loop.

Design for the pressure points.

The model became useful because it was built around real program friction—not around a generic methodology.

01

One program language

Align teams on shared states, milestones, risks, and readiness so status means the same thing across disciplines.

02

Decisions before updates

Design executive reporting around what changed, why it matters, and what leadership must decide—not a list of activity.

03

Explicit handoffs

Give each transition clear inputs, owners, validation, and exit criteria so quality does not depend on memory.

04

Escalation as design

Make consequence and timing visible early enough that escalation protects momentum instead of documenting delay.

Complexity became operable.

The program gained a common way to see the work: what is moving, what is blocked, who owns the next move, and what “ready” means.

The most important result was not another layer of process. It was a calmer delivery environment with clearer ownership, earlier signal, more useful leadership conversations, and a route from business requirements to trusted analytics.

$5M+One program view

Scope and dependencies made legible across a consequential portfolio.

20+Connected specialists

Disciplines operating through one delivery and decision rhythm.

0→1Reusable system

Governance, reporting, RAID, planning, and readiness built from scratch.

What this work reinforced.

Program leadership is the design of conditions under which good work can stay good at scale.

  • Complexity does not need to be flattened; it needs to be framed at the right altitude.
  • Governance earns trust when it improves decisions—not when it produces more meetings.
  • The last 10% of readiness is where operating discipline becomes customer and executive confidence.
Have a program that needs an operating system?

Let’s make it move.

Start a conversation →