Sprinting Without the Critical Path

Ever hit every sprint goal and still miss the deadline? This episode explains why.

Many teams think they're sprinting, but they're still trapped by hidden dependencies, approvals, and late integration work. It feels fast, but the results are slow. We cover what "moving fast" actually looks like when you're dealing with complex programs—and how to track progress without pretending you can predict everything upfront.

Agile vs. FTTM

Both want speed, but they solve different problems.

Agile is about learning as you go - small chunks, constant adaptation, delivering value piece by piece. It shines when requirements are fuzzy and you need to figure things out.

FTTM (Fast Time To Market) is about hitting a date - mapping dependencies, finding bottlenecks, and attacking them. It shines when you're coordinating multiple teams, suppliers, or hardware.

The simple version: Agile helps you build the right thing. FTTM helps you deliver it sooner. They work well together—Agile within teams, FTTM across the program.

In “The Freedom Scale: A Continuum of Team Empowerment,” the conversation digs into a super-practical question: how do you build teams that can move fast and ship real outcomes without turning into chaos? Using the idea of “heavyweight teams” (teams empowered to own an outcome end-to-end) and a Freedom Scale (a clear way to define what decisions the team can make on its own vs. what needs alignment), the episode breaks down how to set decision rights, avoid death-by-handoff, and create the kind of autonomy that actually increases speed instead of risk. If you’ve ever watched a “cross-functional team” get stuck waiting on approvals, dependencies, or invisible rules, this one gives you language and tactics to redesign the system so teams can truly own delivery.

This is a discussion of a migration strategy for evolving organizational structures into high-performance, cross-functional teams. The framework transitions from basic functional hierarchies toward autonomous units that integrate engineering, operations, and marketing to increase operational speed. Central to this model is the Freedom Scale, a continuum of empowerment that defines the level of managerial control—ranging from "wait until told" for trainees to "act with routine reporting" for self-directed experts. Core team roles are clearly defined, including a Program Director for executive leadership, a Systems Architect for technical vision, and a Steering Arm of senior executives to provide strategic resources. Ultimately, the sources emphasize that project ownership and dedicated membership are essential for achieving rapid, successful product development.

In Part C of Episode 5 of the “FTTM is not Project Management” debate, the conversation gets practical: the hosts dig into where the line actually is between “FTTM” work and traditional Project Management work, why people keep mashing the roles together, and what breaks when you do. Expect pointed pushback, real-world examples, and a few “okay, but then who owns that?” moments, ending with takeaways you can use to clarify responsibilities, set better expectations, and stop the same arguments from looping forever.

Here are the top 3 differences (FTTM = Fast Time To Market) versus traditional Project Management:

1. The goal: “pull-in” vs “hold the plan”
   FTTM is explicitly about finishing sooner—a continuous effort to accelerate the schedule and hit the market window (“right product, right time”). Traditional PM is usually about delivering to the baseline (scope/schedule/cost), and a lot of the machinery is built around managing variance once it appears.
2. How the schedule is used: driver vs reporting artifact
   In FTTM, the schedule is the driver of behavior: it’s built to show the gap between the target date and the “real” finish date early, and it’s used to create urgency and action. In traditional PM, the schedule often degrades into a status/reporting tool (updated for governance, not to actively change how the team works day-to-day).
3. Cadence + ownership: daily team refresh vs PM-centric coordination
   FTTM emphasizes full team involvement, daily refresh planning (update → break down → pull-in), and trend tracking so the team can react before the slip (not after). It also pushes cross-silo integration (“lateralized” workflows tied to customer deliverables) rather than functional handoffs. Traditional PM more commonly runs on periodic updates, hierarchical decision-making, and coordination across silos.