Scalability is decided by the resource every part of a system waits for

A system scales as far as the resource its parts share, so I find that resource and measure time spent waiting for it apart from time spent working.

When something is too slow, the first instinct is to split it into more pieces that run side by side. Each piece gets faster, and the whole often does not, because the pieces now queue for something they share: a pool of workers, a database, a lock, a budget. That shared resource sets the wall time, and adding more pieces adds more demand on it.

So I measure two numbers before I trust any speed-up: how long the work spends waiting and how long it spends running. A change that shortens the running and lengthens the waiting has moved the bottleneck, not removed it. Automation makes this sharper, because agents produce far more work than a person, and every extra unit of work lands in the same queue. The articles below each take one case where the shared resource, not the work itself, decided how far a system could go.