The practical lists: what to verify before, during, and after a run.
Work through these when you are about to do the thing they describe.
Verify a workload is worth distributing before you spend cluster time on it.
Work through the usual causes when a distributed run is slower than expected.
Stand up a workspace a team can actually work in, in the right order: storage and libraries before access, access before the first cluster.
Keep compute spend predictable without giving up throughput: what to check weekly, how to stop paying for idle clusters, and where to right-size.
Move a workload off hand-managed instances without losing reproducibility.
The short version of what you need, by role.
The short version of what a data scientist needs on day one: where code runs, where data has to live, and the one habit that keeps a cluster busy.
GPUs, per-call resource requests, and which optimizations the runtime applies on your behalf, plus how to confirm work actually reached the GPU.
Setup order, member roles, and the two numbers worth watching weekly: usage against plan limits, and clusters still running after their work finished.
Plans, accountability, and the questions worth asking monthly: who is spending what, which limits are close, and whether access still matches the team.