You already know how to break a big job into smaller parts. That move even has a name: decomposition. Say your class is running a food stall at the school fair. You would probably list the parts without thinking twice — fix the menu, buy the ingredients, cook the food. That list is not wrong. It is just not enough on its own.
A flat list like this looks like you could do the parts in any order. You cannot. Buy the ingredients before you have fixed the menu, and you do not know what to buy. Cook the food before the ingredients arrive, and there is nothing to cook. The list hides an order that is actually fixed.
Here is the fix. Beside each part, write two short notes. What does this part NEED before it can start? Call that its input. What does this part GIVE once it is done? Call that its output. Fixing the menu needs nothing to start, and it gives a shopping list. Buying the ingredients needs that same shopping list, and it gives a full basket. Cooking the food needs that full basket before it can start at all.
Look at what happened there. The output of one part is exactly the input the next part needs. That does not happen by chance. It is not your opinion about a sensible order either. The inputs decide the order, every single time. A flat list that looked like it could run in any order turns out to be a connected chain, link by link.
Two small notes — needs and gives — and a flat list stops being flat.
Two notes beside each part work well for a short chain. A real class stall has far more moving parts than that. Fix the menu. Buy the ingredients. Arrange a change-box for the cash. Set up the table. Cook. Serve. Even paint a banner for the front. Two notes each still work. But tracking seven parts in your head at once gets hard, fast.
A dependency map solves this. It draws the whole job at once. Each part becomes a box. An arrow from one box to another means one thing only. The box it leaves must finish before the box it points to can start. Fixing the menu sends an arrow to both buying ingredients and arranging the change-box — both need the menu decided first. Buying ingredients sends an arrow to cooking. Setting up the table also sends an arrow to cooking, since the two jobs share the same helpers. Cooking sends an arrow to serving. Draw the whole job once, and every wait in it sits in one picture. You no longer have to notice waits one pair at a time.
The map sorts jobs into two kinds. Fixing the menu is a HUB. Arrows fan out from it to almost everything, so nearly the whole stall waits on it. Painting the banner is the opposite. No arrow points into it. No arrow points out of it. Nothing needs it done, and it needs nothing from anyone else. Call that a FREE job. It can happen any time at all — the morning of the fair, or a week before — without touching the rest of the plan.
A hub carries the whole plan on its back. A free job carries no one, and no one carries it.
Look again at the dependency map. Several different paths run through it, from the very first job to the very last. Fixing the menu, buying ingredients, cooking, and serving is one path. Fixing the menu and arranging the change-box is another, shorter one. Setting up the table and cooking is a third.
The CRITICAL PATH is the longest of these paths — the longest chain of jobs that must happen one after another. The whole job takes at least as long as this one chain. Not the number of jobs in the plan. The chain sets the deadline.
That changes what is worth rushing. Arranging the change-box sits off the critical path. Speed it up, and the whole stall still finishes at the same time, because the deadline was never set by that job in the first place. The honest move is to shorten the critical path itself — buy ingredients faster, or cook faster — never to rush whichever job merely feels easiest to speed up.
The rule has one boundary worth knowing. Say a job's critical chain adds up to 65 minutes. A separate free job needs nothing, and nothing needs it. On its own, it still takes 80 minutes. The whole job cannot finish before that free job does. So that free job — not the so-called critical chain — becomes the one actually worth speeding up.
The chain sets the deadline, until a job standing outside it quietly runs longer than the chain does.
Try this worked case yourself. A class wall display needs five parts: choose a theme, print photos, write captions, stick everything onto the board, and paint a border around it.
Start with the arrows, not your gut feeling about a sensible order. Choosing a theme needs nothing to start, and it gives a direction for everything after it. So it leads.
Printing photos needs only the theme. Writing captions needs only the theme too. Neither job needs anything from the other. So both can run at once. That is a FORK: one finished part, the theme, frees up two others to start together.
Sticking everything onto the board is different. It needs BOTH the finished photos AND the finished captions before it can start — half the work is not enough. That is a JOIN: one part waiting on two others, not one.
Painting the border needs nothing, and nothing waits on it either. It is free. Do it the night before, the morning of, or any time at all.
Put the arrows together, and the order reads itself off the page. Theme first. Then photos and captions, together. Then stick on. Border, any time you like. No guessing was needed anywhere in that order. The arrows alone gave it.
Same shape, every time a job splits into two parts that need only one thing in common: a fork out, and a join back in.
Time the same wall display now. Choosing a theme takes 10 minutes. Printing photos takes 20. Writing captions takes 30. Sticking everything on takes 15. Painting the border takes 25.
Work through the critical path stage by stage. Stage 1: the theme, alone, at the front — 10 minutes. Stage 2: photos and captions run together, since neither needs the other. A stage that runs two jobs in parallel takes as long as its SLOWER job, not the sum of both. Photos finish at 20 minutes. Captions finish at 30. The stage ends when the slower one — captions — finishes: 30 minutes, not 20 plus 30. Stage 3: sticking on, once both are ready — 15 minutes.
Add the three stages on the critical path together: 10 + 30 + 15 = 55 minutes. That is the whole job's finish time.
Now check the border. It takes 25 minutes, a real and nonzero amount of time. But it runs alongside the other stages, off the critical path, and it tucks inside the 55 minutes already spent elsewhere. It adds nothing to the total. Add up every single job's own time instead — 10 + 20 + 30 + 15 + 25 — and you get 100 minutes. That number is wrong for how long the display actually takes. Only the three stages on the chain decide the deadline.
Fifty-five minutes, not a hundred — a parallel job's time hides inside the chain. It does not stack on top of it.
Everything so far has been a job you plan yourself. A machine has jobs too, and its jobs get broken down the exact same way — needs and gives, boxes and arrows — into what is called a PIPELINE.
Take an app that counts people waiting in a bus queue, from a single photo. Step 1: find each face in the photo, and give a list of where each one sits. Step 2: take that list, and give a count — how many faces, in total. Step 3: take that count, and give a plain yes or no answer to one question: is the queue long?
Notice what carries between the steps. Step 1 does not hand Step 2 the photo again. It hands over exactly what Step 2 needs, and nothing else — a list of positions. Step 2 does not hand Step 3 the list back. It hands over exactly what Step 3 needs — a single count. Each arrow carries exactly what the next step needs. That is the same rule from every dependency map in this chapter, now running inside a machine instead of a school stall.
Here is the part worth sitting with. The machine itself never chose to split the job this way. It does not understand "queue," or "person," or even "photo." It only ever does arithmetic on the numbers it is handed, one step at a time. Choosing this pipeline — deciding where each box begins and ends, and what should pass between them — was done by the people who built the app, before it ever ran once. Getting that decomposition right, or wrong, was their job. It still is.
A pipeline runs inside the machine. The decomposing that built it happened outside it, in someone's head, first.
Here is the whole move again, start to finish. A sub-job carries two small notes: what it NEEDS to start, and what it GIVES once it is done. Those notes turn a flat list into a connected chain, because one part's output is so often exactly the next part's input.
Draw every part of a job at once, with boxes and arrows, and you get a dependency map. It sorts jobs into hubs, which almost everything waits on, and free jobs, which nothing waits on and which wait on nothing themselves. The longest chain running through that map — the critical path — sets the deadline for the whole job. Rushing a free job saves no time at all, unless that free job's own duration outlasts the chain. Then it quietly becomes the real bottleneck instead.
A machine's own job gets decomposed the same way, into a pipeline of one-step boxes passing exactly what is needed from one to the next. But the machine never chooses that pipeline. The people who build it do, before it ever runs — and the responsibility for getting it right stays with them.
This same move returns twice more: as the very next chapter's topic, sorting sub-jobs by a repeating pattern, and later as the spine of an AI project's own lifecycle.