Equipment When a Team Doubles in Six Months

What breaks first when a team doubles

Predictable, and in this order. Knowing the order is most of the planning.

Why lead time is first and worst

Because it is the only part of onboarding with a physical constraint. Accounts can be created the night before. A contract can be signed on day one. A laptop in another country cannot be made to arrive faster by caring more.

And lead time degrades non-linearly as volume rises, because the first few machines come from stock and the next ones come from a supply chain. A supplier quoting three days for one device may quote three weeks for twelve of the same model.

So the number to establish early is not the price per machine. It is the lead time at your expected monthly volume, per region, asked specifically.

Order against acceptance, not against the start date

The single highest-value change available, and it costs nothing.

Most companies trigger the equipment order from the start date, or worse from the onboarding checklist created a week before. That leaves the supplier less time than the lead time requires, which is why machines arrive late.

Trigger it from the offer accepted date instead. That is typically two to six weeks earlier, it is a real event in the recruiting system, and it is the moment the person becomes a near-certainty.

The objection, and the answer

Somebody will say that offers fall through and you will have bought a machine for a person who never arrived.

True, and the rate is low, and the machine is not wasted. It goes to the next hire, which in a doubling team is a few weeks away at most. The cost of being early is holding stock briefly. The cost of being late is a new person unable to work in their first week, which is both expensive and the thing they will remember.

Where the offer-to-start gap is short, the answer is a buffer rather than faster ordering. Two or three configured machines held ready removes almost all of the panic, and storage of configured devices held ready for the next hire is one way to hold it without a cupboard in somebody’s house. The limitation is honest and worth saying: holding stock costs money per device per month, so the sum works at sustained hiring and not at two hires a year.

Freeze the specification before volume arrives

Disclosure: RemoAsset, named below, is owned by the same people who publish PeopleOpsHQ. It is described with its limitations stated, on the same terms as every other supplier. This site takes no vendor money.

The second failure is specification sprawl, and it starts with a substitution rather than a decision.

A model is out of stock, somebody approves a close alternative, and six months later the fleet holds four variants of what was supposed to be one machine. Then every support question has four answers, every accessory has four compatibilities, and the standard build no longer builds.

Two decisions prevent it, both made in advance.

Name the substitute. One agreed alternative per tier, at a stated specification, approved before you need it. The person handling a stock-out then has an answer rather than a judgement call at four in the afternoon.

Write the tiers as specifications, not as models. Memory, storage and class rather than a product name, so a successor model satisfies the tier automatically when the original is discontinued.

Keep the tier count low

Two or three tiers covers almost every company under 500 people. More than that and nobody can remember which role gets what, so the tiers get applied inconsistently and the sprawl you prevented in hardware reappears in policy.

For the mechanics of setting those tiers, procurement with a standard build per role is where the specification gets fixed before anything ships. The caveat is the same one that applies to any supplier here: the tiers have to be your decision based on what your teams actually do, not a catalogue selection.

Our guide to laptop spec standardisation covers the specification question in more detail, and it is worth reading before the hiring plan starts rather than during it.

The decision table

Setup capacity is the failure nobody plans for

The third failure arrives quietly. Headcount doubles and the person who sets up machines is still one person, doing it alongside their actual job.

Setup time per machine does not fall with volume if it is done manually. Twelve machines is twelve times the work, and the person doing it starts cutting corners, which is where enrolment gets skipped and the register stops being updated.

Three ways out, in order of how much they help.

Have devices arrive enrolled. Zero-touch enrolment, where the machine registers itself with your management platform on first boot, removes the manual step entirely. This is the one that actually scales and it should be set up before the hiring, not during it.

Standardise the build. A documented, repeatable setup that somebody else can run matters more than a clever one only its author understands.

Stop doing the parts that do not need doing. Pre-installing every application somebody might want is usually unnecessary where a self-service catalogue exists, and it is often the largest single block of setup time.

And the register, which breaks last

Nobody notices this one during the growth. It shows up six months later when somebody tries to reconcile and finds that a quarter of the entries are approximate.

Three fields, captured at the point of shipping rather than afterwards, prevent nearly all of it: serial number, assigned person, and date issued. Captured later they are reconstructed, and reconstruction is where the errors come from.

Management standards such as ISO/IEC 27001, the information security management standard expect the inventory to be accurate, and growth is precisely when it stops being. The cheap control is making the register entry a condition of the shipment rather than a task that follows it.

Equally worth setting up before the growth rather than after: the UK National Cyber Security Centre device security guidance is a reasonable baseline for what the enrolled state of a new machine should look like, and agreeing that once is faster than agreeing it per hire.

Frequently asked questions

PeopleOpsHQ covers the operational side of distributed work. We describe suppliers with their limitations stated, and we take no vendor money.