Setting Device Budgets by Role Instead of by Seniority

TL;DR

• Most companies allocate device spend by seniority because seniority is the variable HR already holds. It predicts almost nothing about what a machine has to do.
• The variables that matter are what software runs, for how long, whether the machine leaves a desk, and whether it handles large files.
• Two tiers is the right number. A third tier immediately becomes the tier people negotiate for.
• The inversion is the giveaway: a director doing browser work on a high-end machine while a junior engineer compiles on a basic one.
• You probably cannot say what people actually run, and finding out takes an afternoon rather than a project.
• Applying the tiers to executives is the only thing that makes them credible. A rule with an exemption at the top is a grade.

The Director With the Fast Laptop

A company of 140 people allocated laptops by band. Three bands, three specifications, and the mapping was explicit in the equipment policy: the more senior the band, the better the machine.

It had been written by somebody sensible and it produced a consistent outcome nobody had intended. The highest specification machines were held by people whose working day was a browser, a document editor and a video call. The engineers, who compiled code and ran containers, were mostly in the middle band because engineers at that company were mostly mid-level.

Nobody had made a bad decision, and the fleet was allocated almost exactly backwards from what the work required. The engineers had worked around it individually: three had bought their own memory upgrades, two ran builds on a cloud machine because their laptops could not, and one had quietly swapped with a colleague who was leaving.

Recommended Tools

Best tools for Device Management

B BambooHR HR management system L Lattice Performance management D Deel Global payroll & EOR

View all recommended tools

The fix took a fortnight and cost nothing in that year's budget, because it reallocated the same machines rather than buying new ones. What it required was asking a question nobody had asked, which was what each person actually runs.

Why Seniority Became the Variable

Worth understanding rather than dismissing, because the reasons are good ones and that is why the practice is so widespread.

It is the variable already in the system. Every HR platform holds a band or a grade. Nothing holds a field describing what software somebody runs all day, so a policy written from available data will use the available data.

It is easy to administer. A band-to-specification mapping needs no judgement at the point of issue, which matters when somebody has to approve forty orders a quarter.

It feels fair in a familiar way. Progression bringing better equipment matches how most other benefits work, and departing from that invites a conversation about why.

And it was closer to true, once. When the expensive machines were the ones that ran the finance system and the design software, seniority and demand correlated more than they do now. That correlation has largely gone, because the work that needs a powerful machine is now concentrated in technical roles rather than in senior ones.

So the practice is a reasonable answer to a question that changed. The replacement has to be nearly as easy to administer, or it will not survive contact with a procurement queue.

What Actually Determines the Machine

Four variables, and all four are observable.

What software runs, and whether it is local or remote. The single biggest factor. Compilers, container runtimes, virtual machines, video editors, large design files and anything doing local rendering need a different machine from a browser and a document editor. Work that happens on a server somewhere else needs very little locally, however senior the person doing it.

How many things run at once, for how long. Memory pressure under a realistic load is what makes an otherwise adequate machine unpleasant, and the shape of that depends on how somebody works rather than what they do. Twenty browser tabs plus a chat client plus a call is a real load.

Whether the machine leaves a desk. Battery and weight are requirements, not preferences, for somebody who works in three places a week. For somebody docked at one desk all day they matter very little, which means a heavier machine with more capability is a legitimate option for that person and not for the first one.

File sizes. Anybody routinely handling large media, large datasets or large repositories has a storage and transfer requirement that has nothing to do with their grade.

Notice what is absent from that table. Seniority, tenure, people-management responsibility and salary band. None of them is a bad thing to know and none of them tells you what the machine has to do.

When Seniority Is Not Worth Replacing

When you are under about thirty people

At this size whoever buys the laptops knows what everybody does, and a formal tier structure adds process without adding accuracy. Ask the person, buy the machine, move on. Writing a tier document for twenty-five people is a document nobody will read.

When the work is genuinely uniform

A company where essentially everybody does the same kind of work on the same tools does not need tiers at all. It needs one specification and an exceptions route, which is simpler and better. Forcing two tiers onto a uniform population creates a distinction people will read as a hierarchy.

When the band mapping happens to be right

Worth checking rather than assuming it is wrong. Some companies, particularly in technical sectors where senior people remain hands-on, have a band mapping that tracks demand reasonably well. The test is the inversion: look for people on the highest specification whose work is a browser, and people on the lowest whose work compiles.

The edge case that forces the change

A visible workaround. Somebody buying their own upgrade, running work on a cloud machine because their laptop cannot, or swapping with a colleague. Each of those is an individual solving a problem the allocation created, and each is evidence that costs nothing to collect.

Five Questions People Ask First

"Will people read a lower tier as a demotion?" Some will, and the way to prevent it is the one thing most companies will not do, which is to apply the tiers to executives on the same basis. A rule where the leadership team is exempt is not a rule about work, it is a grade with a new name, and everybody will identify that within a week. Applied consistently, the framing holds: the machine matches the job, and a senior person whose job is meetings does not need a workstation.

"How do we find out what people run?" Three ways, and you probably have the data already. Software licence assignments tell you who has a compiler, a design suite or a virtual machine tool. Device management reports local storage usage. And asking works, provided you ask about tools rather than about requirements, because the second question invites everybody to ask for the best machine.

"Should the tiers have names?" Yes, and the names should describe the work rather than the person. Anything that sounds like a level will be read as one. Naming them after the workload is slightly awkward and considerably safer.

"What about people who move between roles?" Their tier changes with the role, and the machine changes at the next refresh rather than immediately, unless the new role genuinely cannot be done on the current machine. Swapping hardware on a role change is disruptive and mostly unnecessary, and saying so in advance prevents it being read as a snub.

"Does this save money?" Sometimes, and that should not be the argument. It reallocates, which usually means spending more on a third of the fleet and less on the rest, and the net can land anywhere. The gain is that the people whose work is constrained stop being constrained, which shows up as productivity rather than as a line in a budget.

Building the Two Tiers

Two tiers, named for the work, with exact figures rather than minimums.

The standard tier. For work that is a browser, a document editor, communication tools and a video call, which is most people at most companies. The fields that matter here are memory and storage, because they decide whether the machine is still pleasant in year three, and the battery, because this population is the most likely to work in several places.

The higher tier. For work that compiles, renders, runs containers or virtual machines, or handles large media or datasets. Defined by the workload, which means a junior engineer qualifies and a senior manager who does not do that work does not.

Then four rules that make it executable.

Exact figures, not minimums. A minimum produces a fleet with six configurations inside two years, which is a spares problem and a resale discount. Name the configuration.

Assign the tier to the role, and record it on the role. Not to the person. This is what makes the system maintainable, because a new hire inherits the tier from the role definition rather than from somebody's judgement on the day.

Review the tier definitions annually and the model list quarterly. The capability fields should be stable for years; the models that deliver them change constantly. Keeping them in one undated document is what produces drift.

Write the exceptions route before you need it. One place to ask, a stated turnaround, and a log of what was granted. After two quarters that log tells you whether a tier is set wrong, and that is more useful than any amount of forecasting. If most capability requests come from one role, the tier is wrong rather than the people.

And resist the third tier. The pressure for one comes from a handful of genuine edge cases, and those belong in the exceptions route. Because a third tier always becomes the tier people negotiate for, adding it converts a description of work into a status ladder and you are back where you started with extra steps.

Finding Out What People Actually Run

The afternoon that makes the rest possible. Most companies cannot answer this and assume discovering it is a project.

Start with software licence assignments. Export who has what. A compiler, a container tool, a design suite, a video editor, a statistics package or a database client each indicate a workload, and the list is usually shorter than expected. This alone will sort most of your population.

Pull local storage usage from device management. Not the disk size, the used figure. People handling large files show up immediately, and the distribution is usually bimodal rather than smooth, which makes the tier boundary obvious.

Look at the machines that are struggling. Device management will report devices with high memory pressure or frequent restarts if you ask it to. That list is your constrained population and it is the most direct evidence available.

Then ask, and ask the right question. Not what machine do you need. Ask which applications are open on a normal Tuesday afternoon and whether anything regularly feels slow. The first question gets you a list; the second gets you the complaint nobody has raised.

Sample rather than survey everybody. Twenty people across the roles you are unsure about is enough to place a boundary. A full survey takes three weeks, gets a 60 per cent response rate and tells you the same thing.

So the output is a short table of roles against workloads, and the tier boundary will usually be obvious once it exists. The reason this feels hard is that nobody owns the question, not that the data is unavailable.

How to Choose: Five Questions Before You Rewrite the Policy

Is the inversion present? Look for people on your highest specification whose day is a browser and people on your lowest whose work compiles. If you find both, you have the evidence and you do not need an argument.

What are the workarounds? Personal upgrades, cloud machines rented to run builds, informal swaps. Collect these, because they are the cost of the current arrangement expressed in things people did rather than things they said.

Will the tiers apply to the leadership team? Decide this first, because the answer determines whether the change is credible. If the answer is no, do not make the change; keep the band mapping and be honest that equipment is a seniority benefit.

Who owns the tier on the role definition? Somebody has to add a field to how roles are described and keep it current. Without an owner the tiers will be accurate in month one and stale by month twelve.

What does the exceptions log look like after two quarters? You cannot answer this yet, which is the point: start the log with the change, because it is the mechanism that corrects the tier boundaries and it only works retrospectively.

The Options in Practice

Keep the band mapping

Honest option, and right where the work is uniform or where the mapping happens to track demand. Easiest to administer and the one most likely to be read as fair because it matches other benefits.

Where it struggles: the inversion, and the workarounds it produces. Also the resale consequence, since three band-based specifications produce three resale batches rather than two.

Two workload tiers

The recommendation for most companies above about thirty people with mixed technical and non-technical work. Reallocates rather than increases spend, and removes the constraint from the population that has it.

Where it struggles: it needs the workload data, a field on the role definition, an owner, and the leadership team to be inside the rule. All four are cheap and the fourth is the one that fails.

One specification plus exceptions

Best for genuinely uniform populations and for smaller companies. Simplest to administer and it avoids creating a distinction people will read as a hierarchy.

Where it struggles: the single specification has to be set high enough for the hardest work, which means overbuying for most people, or low enough to be efficient, which means the exceptions route carries real volume.

Device-as-a-service by tier

Worth mentioning because it interacts with tiers neatly. A subscription arrangement priced per device per month makes a tier change a contractual adjustment rather than a capital decision, which removes most of the friction from moving somebody between tiers mid-cycle.

Workwize, Deel IT, Firstbase, GroWrk and allwhere all operate in this space and none publishes a price, so comparing them means several sales conversations before you have a figure.

Disclosure: RemoAsset is owned by the same people who publish HROpsLab. It is relevant here only because a tiered fleet needs the delivered configuration recorded against the asset rather than assumed from the policy, and that is captured at the order when the same platform buys and ships. It publishes no price and requires a demo, it is much weaker for hardware it did not supply, and it is not a certified disposal vendor.

The Comparison

The last column is the one to read. Every approach here fails in a specific and predictable way, and choosing between them is largely choosing which failure you would rather manage.

The Decision Table

The Per-Head Average That Hides Everything

One more reason the band mapping persists: the number most often reported about device spend is an average per head, and an average is the one statistic that cannot show you an inversion.

A company spending the same total on two different allocations looks identical in that figure. One allocation has the heavy workloads on capable machines and everybody else on well-specified standard ones. The other has it backwards. Same average, same budget, completely different outcomes, and no report distinguishes them.

Three figures are worth more than the average.

Spend by workload rather than by band. Group the fleet by what the machines actually run and look at the spend in each group. If the group doing the heaviest work is not the group with the highest spend, you have the inversion in a number rather than an anecdote.

The distribution, not the mean. How many machines are in each configuration. A fleet with 6 configurations is telling you the specification was set as a minimum, and that fragmentation has a support cost and a resale cost attached that the average cannot see.

Age by tier. The average age of the higher-tier machines against the standard-tier ones. If the heavy-use machines are older on average, which happens surprisingly often because they tend to be in teams that grew earlier, the constraint is worse than the specification alone suggests.

So report those three alongside the average rather than instead of it, because finance will reasonably want the average and it answers a budget question rather than an allocation one. Because an average per head is both easy to produce and completely silent on the thing this article is about, it is the reason most companies believe their equipment allocation is fine, and producing the other three takes one afternoon with a register export.

Putting the Tier on the Role Definition

The tiers only stay accurate if they live on the role rather than in somebody's head, and this is the maintenance question that decides whether the structure is still true in year two.

Add one field to however roles are described. Whatever you call the document that defines a role, whether it is a job description, a levelling framework or a row in a spreadsheet, it gets one extra field holding the device tier. That is the whole mechanism.

Give it an owner, and make it the same person who owns role definitions. Not IT and not procurement. The reason is that roles change, get created and get merged by whoever manages that process, and a field maintained by a different team is a field that goes stale within about 18 months.

Make it visible at the point of hiring. When a role is opened, the tier is already set, which means the order can be placed at offer acceptance without anybody asking a question. This is where most of the administrative benefit actually comes from: it removes a decision from the busiest moment in the process.

Default new roles to the standard tier explicitly. A blank field will be filled by whoever is ordering, under time pressure, and they will choose the higher tier because it is the safer error for them personally. An explicit default removes that.

Review it when the role changes, not when the person does. A role that acquires a new responsibility may genuinely move tier, and that is a role review rather than an equipment conversation.

So the maintenance cost is one field and one review in whatever process already exists for roles. Because the alternative is a tier assignment that exists only in a policy document nobody reads at the point of ordering, the field is the difference between a structure and an intention, and it takes about an hour to add to 40 role definitions.

Refreshing by Tier Rather Than by Date

Tiers change the refresh question, and most companies notice this a year later when the two arrangements collide.

A date-based refresh replaces everything bought in a given year, which is simple and treats a constrained machine and an over-specified one identically. A tier-based refresh recognises that the two tiers wear out differently, and the difference is larger than people expect.

The higher tier reaches its limit sooner. A machine running compilers, containers or large files is working harder and against a moving target, because the toolchains it runs get heavier every year. Three years is a realistic interval and sometimes less.

The standard tier lasts considerably longer than policy usually allows. A machine running a browser, a document editor and calls is often entirely adequate at year 4 and sometimes at year 5, provided the memory figure was set properly at purchase. This is where the exact-figures rule pays off: a machine specified with generous memory at the start has a materially longer life, and that one decision is worth more than any refresh policy.

So the sensible arrangement is different intervals per tier, and the budget consequence is counterintuitive. Shortening the higher tier's interval costs money on perhaps 25 or 30 per cent of the fleet. Lengthening the standard tier's interval saves money on the other 70, and the net is usually favourable while the outcomes are better at both ends.

Two practical notes.

Refresh by tier and keep the resale batches clean. Two configurations retiring in two groups sell as two clean lots. Three band-based specifications retiring on a date produce several small mixed lots at a worse rate per unit, which is a quiet cost of the band approach that nobody attributes to it.

Do not swap hardware to implement a new tier structure. Apply the tiers to new purchases and let the refresh cycle do the rest, which takes a few years, costs nothing extra, and avoids a round of visible reallocation that will be read as a judgement about people.

And record the delivered configuration against the asset rather than inferring it from the tier the role was assigned. Policies and reality diverge, substitutions happen, and a register that holds what the policy said rather than what arrived is the one that produces a surprise during a refresh.

Announcing the Change Without Starting an Argument

This is the part that decides whether the policy survives, and it is mostly about what you say first.

Lead with the inversion, using the evidence. Not with the new structure. Open with the finding: the people whose work is heaviest are on the lightest machines, here is how we know, here is what people have been doing about it themselves. A change presented as a correction to a demonstrable problem lands very differently from one presented as a new framework.

State the leadership position in the same message. That the tiers apply to everybody including the executive team, and that several senior people will be on the standard tier because their work is a browser and a calendar. If this is true it defuses the whole status conversation in one sentence. If it is not true, do not send the message.

Say what will not happen. Nobody's current machine is being taken away, nothing changes until a refresh, and nobody is being asked to justify their work. Most of the anxiety a change like this generates is about an immediate reallocation that was never planned, and three clauses prevent it.

Name the exceptions route in the same message, with its turnaround. A change that creates a constraint without simultaneously creating a route to ask for something different will be interpreted as a cost-cutting exercise, correctly or not.

Publish the tier definitions, not just the names. The exact figures and the workload description. A tier whose criteria are visible is a description; a tier whose criteria are held by procurement is a decision about people.

And give it a review date in the announcement. Saying that the boundaries will be reviewed after two quarters against the exceptions log tells people the structure is a working hypothesis rather than a verdict, which is both true and the thing most likely to keep the conversation calm.

What Getting This Wrong Costs

The visible cost is the complaint, and in this area there usually is not one. That is the problem rather than a relief.

The second cost is the workaround, and it is the real number. Somebody running builds on a rented cloud machine because their laptop cannot is a recurring charge nobody has attributed to the equipment policy. Somebody who bought their own memory upgrade has solved a company problem with their own money. Somebody waiting four minutes for a build that should take one, forty times a day, has lost a meaningful part of their week. Because each of these is an individual acting sensibly, none of them appears anywhere as evidence, and the policy looks like it is working right up until somebody collects the list.

The third is a recruitment and retention cost in exactly the roles where it is most expensive. Technical people compare equipment, they discuss it at interview, and a company whose engineers are visibly under-equipped relative to its managers is making a statement about what it values that no careers page will undo.

The reframing question: of the people whose work is genuinely constrained by their machine, how many have raised it, and what are the others doing instead?

When You're Ready to Rewrite It

The honest position is that the band mapping is not a mistake, it is an inherited answer to a question that changed, and replacing it is worth doing only if you will apply the replacement to everybody.

The trigger worth acting on is the inversion plus one workaround. The inversion on its own is a theoretical complaint; the inversion with somebody buying their own upgrade is evidence, and evidence is what a policy change needs.

The sequence costs an afternoon and no budget. Export your software licence assignments and your local storage usage, which together will sort most of your population by workload. Ask twenty people across the roles you are unsure about what they have open on a normal Tuesday and whether anything feels slow. Write down the workarounds you find, because that list is the business case. Then draw two tiers with exact figures, name them for the work, and put the tier on the role definition with an owner.

And start the exceptions log on day one. It is the only mechanism that will tell you whether the boundary is in the right place, it costs one line per decision, and after two quarters it is the most useful document you will have on this subject.

Two things worth holding on to if you decide not to change anything. The first is that the band mapping is a defensible policy as long as you call it what it is. Equipment as a seniority benefit is a legitimate choice, it is easy to administer, and it matches how most other benefits work; what is not defensible is describing it as matching the machine to the work when it demonstrably does not. Say which one you are doing.

The second is that the workaround list is worth collecting whether or not you act on it. People buying their own upgrades, renting compute because their laptop cannot cope, or quietly swapping machines are telling you something about the gap between the policy and the work, and that information has a short shelf life because the people who found the workarounds stop mentioning them once they are working. Ask now, write it down, and the question of whether to restructure becomes an easy one rather than an argument.

Frequently Asked Questions

HROpsLab takes no vendor money and publishes no paid placements, which is why the owner's own product is named above with its three limitations rather than its three best features.