What does it mean that subordinate non-bottlenecks?

Adjust other parts of your system to support the bottleneck rather than running at their own pace.

Example: You identified deep work as your bottleneck in L-0945 and exploited it in L-0946 by eliminating distractions during your two-hour morning block. Throughput improved, but not as much as you expected. The reason: your non-bottleneck processes are still running at their own pace. Your research assistant sends you twelve articles every morning, but you can only process three during deep work. Your team schedules update meetings at 10:30 a.m., right when your deep-work block hits its stride. Your own email habit generates a backlog of half-formed commitments that crowd your attention before you sit down. Every upstream process is producing more than your constraint can consume, and the excess piles up as mental inventory — open loops, unread documents, unanswered obligations. So you subordinate. You tell your assistant to send exactly three articles, pre-filtered to your current project. You move the team meeting to 1 p.m., after deep work ends. You batch email to a single 4 p.m. session so no new inputs arrive before the constraint has finished processing. The deep-work block does not change. Everything around it changes to serve it.

Try this: Identify three non-bottleneck processes that currently feed into or interrupt your constraint (the bottleneck you identified and exploited in L-0945 and L-0946). For each one, answer: How much output does this process produce per day? How much of that output can my bottleneck actually consume per day? What is the excess? Then design one specific subordination rule for each: a limit, a schedule change, a batching protocol, or a filtering criterion that reduces the non-bottleneck's output to match the bottleneck's capacity. Implement at least one of these rules tomorrow and observe whether your constraint's throughput changes.