What to do with bench time before it becomes a cost

The instinct with bench time is to treat it as a loss to be minimised. That framing is wrong in a way that leads to bad decisions, because it pushes firms to fill the bench with anything at all, including work that costs more to deliver than it earns.

The money is gone either way. Salary, benefits, licences and the share of overhead that person carries are all committed. What is still open is what you get in exchange, and that is a genuine decision with a range of outcomes from very good to nothing.

So the useful question is not how to eliminate bench time. It is what a bench day should buy, decided before the day starts rather than reconstructed in a timesheet afterwards.

Compute a fully loaded daily cost per person from your own figures: salary, employer contributions, benefits, role-attached software, equipment, and the share of premises and administration that person consumes, divided by paid available days. Paid available days are calendar weekdays less statutory and contractual time off, which is a subtraction covered in capacity planning for a team that also sells.

That figure is what a bench day costs. It is also the budget for the bench day, and having it written down changes the tone of the discussion. A week of bench for two people is not a vague inefficiency, it is a specific amount of money that is being spent on something, and the only open item is what.

Do not reach for a published benchmark here. A cost per day from another firm carries that firm's salary structure, its licence stack and its overhead, none of which is yours. The derivation and its use in pricing are set out in designing a rate card you can defend.

Most bench options fall into four categories, and they return very different things. Some return cash later, some return capability, some return risk reduction, and one returns nothing at all while looking busy.

The bottom row is the default, and it is the one to name explicitly. Reading, tidying and general availability feel productive and produce no artefact anybody can point at afterwards. That is the outcome you get when no decision was made, which is why the decision has to be made on day one of a bench period rather than day five.

The top rows are not equally available at all times. Sales support returns cash soonest but only if there is pipeline to support. Capability building returns most over a year but only if the thing being learned is something you intend to sell.

Internal tooling is undervalued because its return arrives quietly. An automation that removes an hour a week from a recurring deliverable returns that hour every week for as long as the tool is maintained, and the maintenance clause is the part that gets skipped. A tool nobody owns becomes a liability inside a year, which is the whole subject of building internal tools worth maintaining.

Documentation is undervalued because it feels like admin. It is the cheapest insurance a small firm can buy, and the bench is the only time it will ever be written. Atlassian's case for a single source of truth is that it guarantees everyone in an organisation has access to the same information, and the cost of not having one is paid every time somebody is unavailable.

Both of these also convert idle time into something a buyer can see. A reporting rebuild that produces automated per-location quarterly reports across more than fifteen clinics is the kind of artefact that gets built in the gaps and then sold repeatedly.

A week between engagements is a scheduling artefact. A person who has been under-utilised for a quarter is a business fact, and the two need different responses. Treating the second as though it were the first is how a firm carries a capability it has stopped selling for a year without ever deciding to.

The test is whether the bench recurs in the same capability. If the same skill is idle across three planning periods, the demand for it has changed and no amount of internal project work fixes that. The choices are to sell it deliberately, to redeploy the person, or to stop carrying the capability, and postponing the choice is itself a choice.

Atlassian frames resource management as identifying, acquiring, allocating and managing resources so a project completes, which is the same test read forwards. If the right work never arrives for a given capability, the mismatch is in what you are selling rather than in how you are scheduling.

One trap is worth naming because it produces a real liability. Encouraging people to take vacation during a bench period looks like an elegant solution to two problems at once. It is not, because vacation is an entitlement rather than a scheduling convenience.

In Ontario, employees with less than five years of employment are entitled to two weeks of vacation time and those with five or more years to three weeks, with vacation pay set at at least four per cent of gross wages rising to six per cent at five years. Those days are owed regardless of how busy the quarter was, and spending them to absorb a bench week does not reduce the entitlement, it just moves when it lands.

The planning consequence is the point: leave and bench draw from different pools and should be tracked separately. Coverage planning around real entitlements is set out in planning leave around delivery commitments.

The practical mechanism is small. Keep a live list of bench-ready work, sized in days, each item with an owner and a definition of done. When somebody comes free, the item is picked off the list on the first morning rather than invented on the third.

Review the list at the same cadence as the capacity plan so it does not go stale. Items age badly: a documentation task written six months ago describes a system that has since changed, and an automation idea from last year may have been solved by a platform feature. Treating the list as a continuously refreshed backlog rather than a wish list is the same discipline described in Atlassian's account of continuous improvement as an ongoing process rather than a project.

Then hold one rule. Nothing goes on the list that nobody will own once it is finished. A half-built tool and an out-of-date runbook are both worse than the bench day you spent making them, and avoiding that outcome is the same scoping discipline that statement of work scoping applies to client work.