Study critical path and longest-path in DAGs (scheduling with weights), which builds directly on topological order.
Your PE-Backed company needs to launch a new product line by Q3 to hit Revenue targets. Engineering says 8 weeks, the compliance review takes 6 weeks, and vendor onboarding takes 10 weeks. Your CFO asks why you can't ship in 8 weeks since engineering is the 'hard part.' The answer: the 10-week vendor dependency your team buried in a spreadsheet is the real constraint on delivery, and nobody is managing it.
The critical path is the longest chain of dependent tasks through a project - it sets the minimum calendar time to completion, regardless of how fast everything else goes. Shorten it or you delay the whole thing.
A critical path is the longest sequence of dependent tasks from start to finish in a project, where each task has a duration (weight) and some tasks can't start until others complete (dependencies).
If you've seen a [UNDEFINED: directed acyclic graph] (DAG) in software - nodes with edges, no cycles - a project schedule is exactly that. Each node is a task with a duration. Each edge means "this must finish before that can start." The critical path is the longest weighted path from the first node to the last.
The total duration of the critical path equals the minimum time to complete the entire project. Tasks not on the critical path have slack - they can slip by some amount without delaying the finish. Tasks on the critical path have zero slack. Any delay there flows directly into a delay on the whole project.
This builds directly on Bottleneck thinking: a Bottleneck constrains Throughput at a single step. The critical path constrains total duration across a sequence of steps. A Bottleneck is spatial (which step?). The critical path is temporal (which chain of steps?).
Every day your project runs past its target date, you are burning cash without generating the Revenue that project was supposed to unlock. The P&L impact is two-sided:
Operators who don't identify the critical path make a predictable mistake: they optimize the wrong tasks. They throw resources at engineering (which has slack) while ignoring the vendor onboarding (which is on the critical path). The result is the same delivery date but a higher cost - you spent on acceleration that didn't accelerate anything.
This is the operational version of resource allocation: your scarcest resource is calendar time on the critical path, and every decision should be evaluated against whether it shortens that path or not.
Step 1: Map the tasks and dependencies.
List every task, its estimated duration, and which tasks must complete before it can start. This gives you the DAG.
| Task | Duration | Depends On |
|---|---|---|
| A - Requirements | 2 weeks | - |
| B - Vendor selection | 3 weeks | A |
| C - Engineering build | 6 weeks | A |
| D - Vendor onboarding | 5 weeks | B |
| E - Integration testing | 2 weeks | C, D |
| F - Compliance review | 3 weeks | E |
| G - Launch | 1 week | F |
Step 2: Find the longest path.
Trace every possible path from start to finish and sum the durations:
Path 1 is longer. That is the critical path. The project takes a minimum of 16 weeks.
Step 3: Identify slack on non-critical tasks.
Engineering (Path 2) finishes in 14 weeks total. The project takes 16. So engineering has 2 weeks of slack - it can slip by up to 2 weeks before it affects the delivery date.
Step 4: Manage the critical path.
To deliver faster, you must shorten tasks on the critical path. Options:
Shortening engineering by 2 weeks does nothing for the delivery date. It only converts slack into idle time.
Use critical path analysis when:
Don't bother when:
You're an Operator at a PE-Backed retail company migrating from a legacy order system to a new platform. The Budget is $400K. Your team costs $50K/week. Revenue during the migration continues at $2M/month but the new platform is expected to add $300K/month in Expansion Revenue once live. You map out the tasks:
| Task | Duration | Depends On |
|---|---|---|
| A - Data audit | 1 week | - |
| B - Schema design | 2 weeks | A |
| C - Data migration scripts | 3 weeks | B |
| D - Vendor API integration | 4 weeks | A |
| E - QA and testing | 2 weeks | C, D |
| F - Staff training | 1 week | E |
| G - Cutover | 1 week | F |
Find all paths from start to finish:
Critical path is Path 1 at 10 weeks. The data migration chain (audit → schema → scripts → QA → training → cutover) determines the schedule. Vendor API integration has 1 week of slack.
Cost calculation: 10 weeks × $50K/week = $500K in Labor alone - already over the $400K Budget. Each week you shorten the critical path saves $50K in cost and gains $75K in Expansion Revenue ($300K/month ÷ 4 weeks). That's $125K of value per week saved on the critical path.
Decision: You find you can overlap schema design and data migration scripts by starting scripts on a provisional schema after week 1 of schema design. This compresses B+C from 5 sequential weeks to 4 overlapping weeks. New critical path: 9 weeks. Savings: $50K in Labor plus $75K in earlier Revenue = $125K recovered. Now both paths are 9 weeks - meaning you have two critical paths to manage.
Insight: The critical path often isn't where the team's attention naturally goes. Here, everyone worried about the vendor API integration (the 'hard' technical work), but the data migration chain was actually longer. And when you shorten the critical path, watch for a new critical path to emerge - you've just shifted the constraint.
You need to hire 3 engineers and 1 product manager before you can start a new product initiative. The initiative itself takes 12 weeks of build once the team is assembled. Your Time-to-Fill benchmarks:
You need the product live in 6 months (26 weeks) to hit Revenue targets.
Map the dependency chain:
Critical path is the PM hire at 24 weeks. You have 2 weeks of slack against the 26-week deadline, all of it coming from the PM dependency. The engineering recruiting has 4 weeks of slack (24 - 20 = 4).
Implication: Accelerating engineering hiring does nothing for your timeline. If your Full-Cycle Recruiting team is spending equal effort on both pipelines, they're misallocating. The PM search needs maximum Pipeline Volume and urgency now. Consider using an Employee Referral Program or paying a premium for a specialized recruiter to compress Time-to-Fill on the PM role.
Risk check: If the PM search slips by even 3 weeks (not uncommon for specialized roles), you blow the 26-week deadline. With only 2 weeks of slack, this is an Execution Risk you need to flag to leadership immediately.
Insight: Hiring timelines create critical paths that most Operators never visualize as a graph. The longest hiring dependency - not the hardest technical hire - determines when your team can start building. This is a direct application of Bottleneck thinking extended across time: the constraint isn't capacity at one step, it's the total duration of the longest dependency chain.
The critical path is the longest chain of dependent tasks - it determines the minimum time to deliver. Everything else has slack.
Spending resources to accelerate tasks with slack does not move the delivery date. It just increases cost. Always verify a task is on the critical path before investing to speed it up.
When you shorten a task on the critical path, a different path may become the new critical path. You're shifting the constraint, not eliminating it - just like fixing one Bottleneck often reveals the next one.
Optimizing the hardest task instead of the longest path. Teams instinctively throw resources at the most technically difficult work, but difficulty and critical-path membership are independent. A simple but slow approval process (compliance, legal, vendor onboarding) is often the actual constraint.
Ignoring that estimates are uncertain. If your critical path has 1 week of margin and your task estimates have +/- 2 weeks of Variance, you don't really have a plan - you have a hope. Identify tasks on or near the critical path and add explicit buffers, or run Sensitivity Analysis on the durations to see which estimate errors would change the critical path.
You're launching a new SaaS product. Map the following tasks into a DAG and find the critical path:
What is the critical path? How much slack does the marketing workstream have?
Hint: Trace every path from A to H and sum the durations. There are two main paths - one through engineering, one through marketing.
Path through engineering: A(3) → B(2) → D(8) → F(2) → H(1) = 16 weeks
Path through marketing: A(3) → C(4) → E(3) → G(2) → H(1) = 13 weeks
Critical path: Engineering path at 16 weeks.
Marketing slack: 16 - 13 = 3 weeks. The marketing workstream can slip by up to 3 weeks before it affects launch.
Using the platform migration example (10-week critical path, $50K/week team cost, $300K/month Expansion Revenue at stake): A vendor offers to do the data migration scripts for you in 1 week instead of 3, but charges $120K. The scripts are on the critical path. Should you take the deal?
Hint: Calculate the value of shortening the critical path by 2 weeks. Include both cost savings from a shorter project and earlier Revenue. Then compare to the $120K vendor fee. But check - does this actually shorten the critical path, or does a new path become critical?
Current critical path: 10 weeks (data migration chain).
Other path: 9 weeks (vendor API chain).
Outsourcing scripts compresses the critical path task from 3 weeks to 1 week, saving 2 weeks. New critical path duration: 8 weeks. But wait - the vendor API path is 9 weeks. So the new critical path becomes the vendor API path at 9 weeks. You only save 1 week total (10 → 9), not 2.
Value of 1 week saved:
Cost of vendor: $120K, but you also save the Labor cost of your team writing the scripts (let's say 1 engineer for 3 weeks, already counted in the $50K/week team cost).
Net value: $125K saved - $120K spent = $5K net positive. Marginally worth it, but barely. The real lesson: the second week of acceleration is wasted because a new critical path emerges. You'd need to also shorten the vendor API path to capture the full 2 weeks of value.
Your Operations team runs a monthly close process. The steps and durations are:
The close currently takes 8 business days. Your CFO wants it done in 6. What's on the critical path, and what would you change?
Hint: Find the critical path first. Then look at which dependencies are truly necessary - could any tasks start earlier or run in parallel? Consider whether 'depends on B and C' means D truly needs both, or whether partial information would let D start sooner.
Path through reconciliation: A(1) → B(3) → D(1) → E(2) → F(1) = 8 days
Path through vendor invoices: A(1) → C(2) → D(1) → E(2) → F(1) = 7 days
Critical path: Reconciliation path at 8 days. Vendor invoices have 1 day of slack.
To get to 6 days, you need to shorten the critical path by 2 days. Options:
Options 1 + 2 together get you from 8 to 6 days. But now check: the vendor invoice path becomes 7 - 0 = 7 days (you didn't shorten it), and the reconciliation path is 6 days. The vendor invoice path is now the critical path at 7 days. You'd also need to compress C or restructure its dependencies to hit 6.
Critical path extends the Bottleneck concept from a single constrained step to an entire chain of dependent steps across time. Where a Bottleneck tells you which step limits Throughput right now, the critical path tells you which sequence of steps determines total delivery time. In practice, a Bottleneck often sits on the critical path - but not always. A step can be a Bottleneck (at full capacity) yet have slack in the schedule because it's on a shorter path. Conversely, a step with plenty of spare capacity can still be on the critical path if it's part of the longest dependency chain. Operators who understand both concepts can distinguish between two different questions: 'What limits how much we can process?' (Bottleneck and capacity) and 'What limits how fast we can deliver?' (critical path and dependencies). Downstream, critical path thinking feeds directly into Capital Allocation decisions - when you're choosing where to invest to accelerate a program, the NPV of that investment depends entirely on whether you're shortening the critical path or just adding slack to a non-critical one.
Disclaimer: This content is for educational and informational purposes only and does not constitute financial, investment, tax, or legal advice. It is not a recommendation to buy, sell, or hold any security or financial product. You should consult a qualified financial advisor, tax professional, or attorney before making financial decisions. Past performance is not indicative of future results. The author is not a registered investment advisor, broker-dealer, or financial planner.