How a handwritten chase list became a very different operating system There is a crumpled sheet of lined notebook paper in my house that, at first glance, looks like almost nothing. At the top I wrote “CPT Chase.” Underneath it are four times: 9:00 p.m., 10:15 p.m., 2:30 a.m. and 5:00 a.m. There are destination codes beside them and a short list of things to do in preparation: start grabbing CPTs an hour in advance, re-induct before the cutoff, close out unused cells with CPTs, load dwelling CPT cages, help wherever things are backed up.
That was the operating problem in front of me at ALB1. It is difficult to look at that piece of paper now without thinking about what the operation eventually became. We went from that handful of CPTs to 21 CPT departures in a day, plus sweeper loads. The building had been built around a maximum capacity of roughly 16,000 units per day. After optimization, normal days were greater than 25,000 units and usually greater than 30,000. During our best high-volume event, we broke 60,000. The interesting part of that story is not that people worked four times harder.
They didn't. You cannot sustainably get nearly four times the designed daily volume out of a building by telling everybody to move faster. At some point there are only so many people who fit in an aisle, only so much freight that fits in a staging location, only so many trailers that can occupy doors, only so much material that can move through a piece of equipment, and only so many things an operator can keep in their head at once. The interesting question is what “capacity” actually means. That little piece of paper is where I like to start.
THE FIRST VERSION OF THE CONTROL SYSTEM
CPT means Critical Pull Time. A CPT is not simply a time printed on a schedule. Operationally, it is a promise. Freight has somewhere else to be. By the time the clock reaches the departure deadline, everything that belongs to that movement has to be identified, moved through the building, collected, staged, loaded and ready to leave. Missing that departure does not make the freight disappear. It changes the problem. Now the units have missed the movement they were supposed to make, and the consequences travel downstream. That means a CPT cannot really be managed at the CPT.
If I begin worrying about a 9:00 p.m. departure at 8:58, I am already too late. That is why one of the notes on the page says to start grabbing CPTs one hour in advance. The deadline is the visible event. The work required to make the deadline happens before it. That sounds obvious when written in an article. In an operation, it is a much more consequential idea. Once you accept it, you stop organizing the work around “what is due right now?” and begin organizing around “what has to become true before the next deadline arrives?”
Those are very different ways to run a building. The rest of the handwritten list follows the same logic. Re-induct before CPT. Close out unused cells containing CPT freight. Load dwelling CPT cages. Help backed-up areas. None of those instructions is glamorous. They are all about removing conditions that can strand freight.
A unit sitting in the wrong place is not merely a unit sitting in the wrong place. It is future work. It is future congestion. It may be a future miss. Enough small pieces of stranded work eventually become an operating condition. The first job was therefore not “go faster.” It was to stop allowing tomorrow's problems to accumulate inside today's operation.
FROM A LIST OF DEPARTURES TO A FLOW SYSTEM
Four departures can be managed with a surprising amount of human memory. Twenty-one cannot. As the number of departures increases, the relationship between them begins to matter as much as the individual departure times. Freight for one CPT is moving while another CPT is being staged, while another is being loaded, while another part of the building is generating the freight for what comes next. Then there are sweeper loads.
Then there is the physical building. Then there are people. Then there are trailers. Then there is equipment.
Then there is everything upstream that determines when the freight reaches you. A dock is where a large number of independent-looking decisions suddenly become one system. If the upstream process releases work in the wrong sequence, the dock experiences it. If labor is positioned incorrectly, the dock experiences it. If staging space is consumed by the wrong freight, the dock experiences it. If equipment is unavailable, the dock experiences it. If a trailer is not where it needs to be, the dock experiences it. And if the dock fails to convert all of those inputs into an on-time departure, the network downstream experiences it.
This is why I have always been interested in bottlenecks. The visible problem is not necessarily the problem. A backed-up area can look like a labor problem. Add people. Except sometimes adding people makes it worse. A crowded area can look like a space problem. Find more space. Except sometimes the real problem is that material is dwelling there that should already have moved.
A missed departure can look like a loading problem. Except the departure may have been lost hours earlier because the work entered the system in the wrong sequence. You cannot optimize a system by repeatedly treating whatever symptom happens to be loudest. You have to follow the work.
WHAT DOES “MAXIMUM CAPACITY” MEAN?
The building's nominal maximum was about 16,000 units per day. That number mattered. But it did not mean that at unit 16,001 the building would explode. A capacity number is the product of assumptions. It assumes a certain process. It assumes a certain sequence. It assumes particular constraints. It assumes certain relationships among labor, equipment, space, time and work.
Some constraints are physical. Those deserve enormous respect. Others are artifacts of how the operation has been designed. Those deserve investigation. If a process requires an item to be handled unnecessarily, the building may appear to have a labor constraint when it actually has a process constraint.
If freight dwells until a deadline is close, the operation may appear to have a staging-space constraint when it actually has a sequencing constraint. If departures are treated as isolated events, the dock may appear to have a loading constraint when it actually has a planning constraint. This distinction matters because “increase capacity” sounds like a capital project. Sometimes it is. Sometimes you need another building, another conveyor, another dock door or another piece of equipment.
But sometimes capacity is trapped inside the system you already have. The job is to find it. That is very different from pretending physical limits do not exist. Physical limits are real. The point is to determine which limit you are actually hitting. When our normal operation moved beyond 25,000 units and commonly beyond 30,000, we were already operating well beyond the building's original 16,000-unit daily design point.
At 30,000, we were at 187.5 percent of that number. Our best high-volume day exceeded 60,000. That is more than 375 percent of the nominal daily maximum. You do not get there with a motivational speech.
THE NUMBER OF CPTs MATTERED The 21 departures are as important to me as the volume. If the only objective had been to pile 60,000 units into a building, that would not have been an accomplishment. The units had destinations. They had deadlines. They had to leave.
Throughput without successful departure execution is inventory accumulation. That is why the growth from four CPTs on a chase sheet to 21 departures plus sweepers is such an important part of the story. We were not merely increasing the amount of work inside the building. We were increasing the number of promises the building could successfully keep. Each additional departure creates another synchronization point.
The operation has to generate the correct freight, for the correct movement, in sufficient time, without allowing that priority to destroy the next priority. The more CPTs you add, the less useful brute-force management becomes. Eventually the operating system itself has to get better. You have to see farther ahead. You have to know what is dwelling. You have to know what is approaching. You have to know where capacity is disappearing before the disappearance becomes a miss. You have to close loops.
You have to make the operation legible. That last point has followed me through almost every kind of work I have done.
MAKE THE WORK LEGIBLE
A system becomes much easier to improve once you can see what it is actually doing. Not what the process document says it does. Not what somebody remembers it doing yesterday. Not what the average says it probably does. What is happening now, what has to happen next, and what prevents that transition? The handwritten CPT sheet is a primitive example of making work legible.
There are deadlines. There is preparation. There are known failure conditions. There is an expectation that you look for dwelling work and remove it. There is an expectation that you go help the place that is becoming constrained. The paper is not sophisticated. The thinking behind it can scale. As the operation became larger, the representation of the operation also had to become larger. You cannot run 21 departures as four departures with a longer list.
The complexity is not additive. Every additional movement interacts with the others through shared resources. They share labor. They share space. They share equipment. They share time. They share upstream processes. They share the consequences of congestion. So the system has to become capable of prioritizing without becoming blind to everything it has temporarily deprioritized. That is one of the reasons I dislike optimization that looks only at a single metric.
You can make one number beautiful while quietly destroying the operation around it. A process can achieve a fantastic local rate by pushing work into somebody else's constraint. A department can look productive because it has transferred its unfinished problem downstream. A shift can look clean because it has left the next shift a disaster. None of those is optimization. It is accounting.
THE SWEEPER IS PART OF THE DESIGN
I also think it matters that I say “21 CPTs plus sweeper loads.” A sweeper can sound like an exception. It is tempting to think of exceptions as evidence that the system did not work perfectly. I don't think that is a useful way to design operations.
Real systems have variance. Freight arrives differently. Equipment fails. People call out. Trailers move. Forecasts are imperfect. Upstream processes have their own constraints. If your operating design only works when every assumption is true, you have not designed an operation. You have designed a demonstration. A resilient operation has ways to recover.
The sweeper is part of that thinking. So is chasing dwelling freight before it becomes critical. So is helping a backed-up area before the backup owns the entire shift. So is beginning the CPT an hour before the clock says CPT. Recovery capacity is capacity. That principle has become more important to me over time.
Efficiency is not the elimination of every spare minute and every spare resource. A system with no ability to absorb variation can be extremely efficient right until the instant something changes. Then it is catastrophically inefficient. The goal is not to remove all slack. The goal is to understand what the slack is for.
THE PEOPLE WERE NOT MACHINES
There is another reason I resist telling this as a “we pushed harder” story. People are part of the system, but they are not interchangeable units of capacity. A person who knows what they are looking at can prevent a problem before another person even realizes a problem exists. Someone who understands the relationship among the CPTs can make a different decision than someone who sees only the task immediately in front of them.
Training changes capacity. Experience changes capacity. Positioning changes capacity. Communication changes capacity. A good operating design lets people use judgment where judgment is valuable instead of consuming their attention with preventable chaos. That is a much better use of people than asking them to compensate forever for a bad process. When an operation is poorly designed, its best employees become human middleware.
They remember what the system does not record. They chase what the process does not route. They translate between teams that do not communicate. They rescue freight that should never have become stranded. Then management concludes that these people are exceptionally productive. They are. But the organization should also be asking why exceptional people have to spend so much of their capacity repairing ordinary work.
Some heroics are inevitable. Heroics as the standard operating procedure are a design failure.
THE 60,000-UNIT DAY
The number everybody remembers is the big one. More than 60,000 units in a building designed around 16,000 is the number that makes the story sound dramatic. I understand why. I am proud of it.
But I am more interested in the normal days. A record day can happen because everything aligns. Sustained improvement is harder. When greater than 25,000 became normal and greater than 30,000 became common, that meant the operating envelope itself had changed.
The building had learned to be something different. That is the accomplishment. A peak number demonstrates what is possible. A new normal demonstrates that you changed the system.
Those are not the same thing. And if I were evaluating an operation today, I would still ask the same question. Don't show me only the record. Show me what became ordinary.
WHAT THE CRUMPLED PAPER MEANS TO ME NOW
I kept a lot of strange artifacts from my career. Screenshots. Photographs. Notes. Plans. Old training material. Things that look meaningless if you were not there. For years I did not think much about why. Now I do.
A résumé might say that I optimized outbound operations. That sentence is almost useless. It does not tell you what I saw. It does not tell you what I changed. It does not tell you how the work behaved before the change. It does not tell you what 16,000 meant. It does not tell you what 21 CPTs meant. It certainly does not show you a wrinkled piece of notebook paper with four departure times and a reminder to go find the dwelling cages.
The artifact does. Not by itself. The paper needs the story, and the story needs the paper. Together they preserve something that a bullet point cannot.
This was the problem when it was still small enough to fit in my hand. Four CPTs. Start an hour early. Get the dwelling freight moving.
Close out what is sitting. Help the place that is backing up. Then keep following the bottleneck. Eventually there were 21 departures.
Eventually an ordinary day was bigger than the building's supposed maximum. Eventually we crossed 60,000. But none of those numbers changed the fundamental job. Find what has to leave.
Understand what is preventing it from leaving. Act before the deadline turns the constraint into a failure. Then do it again. The scale changed.
The system became more sophisticated. The piece of paper got replaced by much larger ways of seeing the operation. The underlying thinking did not. That may be why I still have the paper.