By [Author Name] · [Date] · [X] min read · [Table of Contents]
TL;DR
- Equipment rarely appears in a Head of People handover and usually turns out to be partly yours.
- The first task is finding out who currently owns it, which is often nobody in particular.
- Three things are worth doing in ninety days: establish the real state, fix the day-one experience, and name an owner.
- Three situations: documented and working, undocumented but functioning, and nobody is doing it.
- Choose what to fix based on what new starters experience, not on what the register looks like.
- Done well, you leave day 90 with an owner, a baseline and a working first week.
Somebody starts as Head of People and in week two a hiring manager asks when a new starter's laptop is arriving. It's a fair question. The person who owns onboarding should know. The new Head of People has no idea, discovers that equipment is ordered by an office manager who left six weeks ago, and that the handover document covers payroll, the HRIS and the performance cycle but not this.
The variants are consistent. Somebody inherits a function where equipment is nominally IT's and IT believes it's HR's, so for eight months it has been handled by whoever noticed. Another finds a spreadsheet last updated fourteen months ago listing a hundred and ten devices for a company of ninety people. A third finds everything documented and functioning and spends three weeks auditing something that was already fine.
Best tools for HR Operations
The real issue isn't the equipment. It's that it sits between HR, IT and finance, so it's the function most likely to have no owner, and a change of leadership is when that becomes visible.
When You Don't Actually Need to Change Anything
Stage one: it's documented, owned and working. There's a named owner, an accurate register, a process new starters go through, and a refresh cycle. If you find this, say so and move on. Auditing a working system to establish your own credibility is a poor use of your first month.
Stage two: it works and nobody owns it. New starters get laptops, mostly on time, through a process that exists in several people's heads. Nothing is broken and the whole thing depends on individuals who may leave, which is how you ended up looking at it.
Stage three: it's a liability. No accurate record, devices unaccounted for, departures not recovering anything, and a day-one experience that fails regularly. Worth fixing and worth being realistic about: this is a two-quarter problem, not a ninety-day one.
Stage four: nobody is doing it. No process at all, hardware bought on expenses as needed, no register, no retrieval. More common in companies under about eighty people than anybody admits, and it needs building rather than fixing.
What a New Head of People Actually Needs to Find Out
> "Who owns this today?" > Ask three people separately and see whether the answers match. > If they don't, that's your finding, and it's the most important one.
> "What does a new starter actually experience?" > Ask the last three people who joined, not the process documentation. > The documented process and the lived one differ, and only one of them matters.
> "What do we think we own, and how confident is anybody?" > You want the register and an honest view of its accuracy, which is a different question. > "We have a spreadsheet" and "the spreadsheet is right" are not the same answer.
> "What happens when somebody leaves?" > Check the last ten departures and whether a device came back. > This is the fastest diagnostic available and it takes an hour.
> "What does it cost?" > Find the spend, which may be in three places: procurement, expenses and a vendor subscription.
A sixth question is worth asking around week six: what has been raised before and not fixed? There's usually a list in somebody's head of things they've been asking for, and a new leader who acts on one of them buys considerable goodwill for very little.
The Three Situations and What Each One Needs
Documented and working. What it is: named owner, accurate register, functioning process. What it needs: confirmation and nothing else. Spend a day verifying, then leave it alone and put the attention somewhere it's needed. Where it goes wrong: when a new leader changes it anyway. There's a real temptation to make a visible change in a functioning area because it's easy, and it costs you credibility with the people who built it.
Undocumented but functioning. What it is: things happen, nobody can explain how, it depends on individuals. What it needs: documentation and a named owner, in that order, and nothing structural. The process works; what's missing is that it survives somebody leaving. Where it goes wrong: when the documentation exercise turns into a redesign. Write down what happens now before deciding whether it should happen differently.
Nobody is doing it. What it is: no process, no record, no owner. What it needs: building, which is a bigger job than ninety days, so pick the two things that matter most. Those are the day-one experience and the departure process. Where it goes wrong: when the register becomes the first project. A full inventory is slow, invisible to everybody, and doesn't fix anything anybody is currently experiencing.
Work from the experience inward. Not from the register outward. That is what I'd recommend. A new leader whose first equipment action makes day one work is credible when they later ask for budget to fix the register. One whose first action is a three-month audit is not.
| Situation | First action | Ninety-day goal | What to resist |
|---|---|---|---|
| Documented and working | Verify in a day | Leave it alone | Changing it for visibility |
| Undocumented, functioning | Write down what happens | A named owner | Redesigning while documenting |
| Nobody is doing it | Fix day one | Day one plus departures | Starting with the inventory |
How to Decide What to Fix: Five Questions
What are new starters experiencing? Ask the last three joiners directly. Did your laptop arrive before your first day, did it work, did anybody explain it. Three conversations, thirty minutes in total, and it tells you more about the state of the operation than any process document will.
Did the last ten leavers return their devices? Pull the list and check. This single query diagnoses the whole operation, because retrieval is the first thing to fail and the last thing anybody notices.
Is there one name? Not a team, a person. If you can't get a name, that's the gap, and naming someone is the highest-value thing you can do in your first month.
What would the people doing it fix? Whoever has been handling equipment informally has a list. Ask for it. It'll be short, specific and mostly correct, and acting on a single item from it buys more goodwill than anything else available to you that month.
What's already paid for? There may be a vendor arrangement nobody is using properly, or a subscription with capabilities nobody switched on. Worth an hour of looking before you propose anything new, because a capability you already pay for is cheaper than one you have to justify.
Six Platforms Worth Knowing
RemoAsset Best for: establishing a record from the point you arrive, rather than reconstructing what happened before. Why companies choose it: procurement and retrieval across 80+ countries with each device recorded against a person and a date at the point of issue, which for an incoming leader means everything from now on is documented even if the history isn't. Published pricing from $1,499 a year on the Subscription tier for companies with 50 to 5,000+ employees, including a 60 per cent reduction on retrieval charges, and retrieval is usually the broken half of whatever you've inherited. It's our own product, so weigh that accordingly. Where it struggles: no network discovery, which matters a great deal in your situation, because the devices nobody recorded before you arrived stay invisible and finding them is a manual exercise with people. No software licence management. And only the Subscription tier publishes a figure, with pay-as-you-go quoted.
Electric AI Best for: smaller companies where IT oversight is also unowned and you want both in one place. Why companies choose it: it publishes prices, which is rare in this category: $10 per user per month on Essentials and $25 on Pro, with a free tier available. Where it struggles: cost tracks headcount rather than devices, and it's an IT management product rather than a logistics one, so delivery and retrieval are not what it does.
Workwize Best for: companies where the day-one failures are really stock problems. Why companies choose it: own warehouses, so machines can be ready rather than ordered. Where it struggles: publishes no rate card, so a budget request needs a sales conversation first. The figures on its pricing page are savings claims rather than prices. Live domain is goworkwize.com.
Firstbase Best for: fixing the procurement half quickly. Why companies choose it: strong supply side, clean subscription shape. Where it struggles: publishes nothing on price, and retrieval is the weaker half, which is probably what you inherited broken.
allwhere Best for: handing the operation to somebody else while you fix things that genuinely need you. Why companies choose it: managed service, low internal lift, which is a reasonable answer when your first ninety days have ten priorities. Where it struggles: publishes nothing, so comparison requires a conversation.
Deel IT Best for: companies already running employment through Deel. Why companies choose it: hardware alongside employment with MDM and support included. Where it struggles: publishes no price for IT, and its own page states both 130+ and 150+ countries without reconciling them.
The Decision Table: What Actually Needs Deciding
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| Named owner, accurate register | Any | Any | None | Verify and leave alone |
| Works, nobody owns it | Any | Any | Key-person risk | Document, then name an owner |
| Day one failing regularly | Any | Any | New starter experience | Fix day one first |
| Leavers keeping devices | Any | Any | No retrieval process | Build the exit step |
| No register at all | Under 150 | Any | No baseline | Sample 25, do not audit all |
| Equipment disputed between teams | Any | Any | Nobody decides | Get it assigned in writing |
Rows three and six are where your first month should go.
Week One: Ask Three People Who Owns It
Your first equipment task takes an hour and produces the finding that shapes everything else.
Ask three people separately who owns equipment: your most senior IT contact, whoever handles finance or procurement, and the manager who most recently hired somebody. Don't frame it as an audit, just ask who handles laptops.
If all three give the same name, you have an owner and your job is to find out whether they have what they need. That's a good outcome and uncommon.
If the answers differ, or if any of them is a shrug or a process rather than a person, you've found the actual problem. That's the finding. Equipment sits at the intersection of three functions and the usual failure is not that somebody is doing it badly, it's that nobody has been told it's theirs. Everything else you might find, the stale register, the missing devices, the failing day one, follows from that.
The second hour is better spent than the first. Ask the last three people who joined what their first week was like, specifically about equipment. When did your laptop arrive, did it work, did anybody tell you what was happening. People who joined recently remember all of it vividly, and in most companies nobody has thought to ask them about any of it.
What usually comes back is a gap between the documented process and the experience. The process says one thing. The laptop is ordered when the offer is signed. The experience is that it arrived on day three and nobody mentioned it beforehand, so they spent their first two days wondering whether to ask.
That gap is your first fix, and it's often not a procurement problem at all. It's that nobody tells the new starter anything, which is a communication fix costing one email template.
Days 1 to 30: Fix What People Experience
Resist the register for now. Here's why, and it's a judgement about where your credibility comes from.
A register project is slow, mostly invisible, and improves nothing anybody is currently experiencing. Three months of inventory work produces a spreadsheet and no observable change, and if you're new, that's how your first quarter gets described as administrative.
The day-one experience is the opposite: fast, visible and noticed by exactly the people whose opinion of you is forming. And it's usually broken in ways that are cheap to fix.
Three fixes are typically available in the first month. Tell the new starter what's happening, which means one email confirming what's coming, when and to which address, sent when the order is placed. Most companies don't do this and it eliminates the most common complaint, which is the uncertainty rather than the delay. Ask for the delivery address earlier, because it's frequently collected in week one of onboarding when it's needed three weeks earlier. And check whether the machine is set up before it ships, because a laptop arriving on time that then takes a day to configure has arrived late in practice.
None of those requires budget or a vendor change, and together they fix most of what new starters actually complain about.
One caution. Don't announce a programme. Fix the three things, let the next few starters have a better week, and let somebody else notice. A new leader announcing an equipment initiative in month one is spending credibility; one whose new starters quietly stop complaining is earning it.
Days 30 to 60: Find Out What You Actually Have
Now do the register work, and do it by sampling rather than by auditing.
A full inventory of a few hundred devices means contacting every holder, chasing the non-responders, and doing it while the fleet keeps moving. It stalls. Usually around sixty per cent, and the result was never accurate at any single moment anyway. Everybody who has attempted one knows this and the next person attempts it anyway.
Sample instead. Twenty-five entries from whatever record exists, chosen at random with no substitutions, each confirmed directly with the person named. One question, including the serial number, answerable in half a minute, which is why the response rate holds up where a survey's would not. Two days of work.
What you get is an error rate. That is worth considerably more than a corrected list. Under five per cent means the record is reliable and you can plan from it. Between five and twenty means it's directionally right and specifically wrong, which is the normal state and tells you to verify before acting on any individual row. Above twenty means you have a list rather than a record, and the process that maintains it needs changing rather than the data.
Those three bands lead to completely different plans, which is why a number beats an impression.
Also log why each error occurred, because the causes repeat and you'll see the pattern in one pass. Stale holders from internal transfers nobody recorded. Disposals that happened without the record being updated. Devices bought locally that never entered the system. Those three account for most of it, and fixing the biggest one is a process change rather than a data exercise.
The sample also gives you something to say. An incoming leader who can state the error rate, name the two causes behind it and describe what they're doing about them reads as competent. One who says the register needs work does not, even though it's the same information.
Days 60 to 90: Name an Owner and Fix Departures
Two things to land before day ninety, and they're the ones that outlast you.
The owner first. One named person, with equipment explicitly in their remit, written down somewhere that survives them changing role. It doesn't have to be in your team; it can sit with IT or with operations, and in many companies that's the better home. What matters is that it's a name rather than a function, because functions don't notice things.
Getting this assigned may be the hardest political task in your ninety days, because equipment is unowned precisely because three functions each have a reasonable claim to not owning it. The argument that works is the cost of the gap rather than the principle: here are the devices we can't account for, here are the departures that returned nothing, here's what it cost, and it costs that every year until somebody owns it.
Then departures. Retrieval is the first thing to fail in any equipment operation and the last thing anybody notices, because nobody internally is waiting for a returned laptop. Check the last ten leavers, find out how many devices came back, and if the answer is low, add a step to the exit process.
The step is small: a named action in the offboarding checklist, with a prepaid return arrangement the person can use without effort, initiated before their last day rather than after. Most people want to return equipment and are defeated by the logistics, so removing the logistics fixes most of it.
What you should not attempt by day ninety is a refresh policy, a vendor change, or a new system. Those need two things. The baseline you've just established, and a budget cycle you haven't reached yet. Leaving day ninety with a working day one, an error rate, a named owner and a departure step is a strong quarter, and each of those makes the next thing possible.
Where Jurisdiction Comes In
Brief, because most of this is internal process.
What you can require of people regarding equipment, what obligations exist around somebody's working environment, what may be deducted or claimed if a device isn't returned, and how any of it interacts with employment arrangements all differ by jurisdiction and by circumstance. If you're inheriting an operation spanning several markets, expect several answers and get local advice rather than applying one policy.
Anything raised on health or accessibility grounds should go to whoever handles that in your organisation rather than through an equipment process, and if that routing doesn't exist, establishing it is worth doing in your first ninety days.
The rest of this page is portable. Ask three people who owns it. Ask the last three joiners what happened. Fix the day-one communication. Sample twenty-five rather than auditing everything. Name an owner. Add a departure step. None of that needs legal advice, and all of it is doable inside a single quarter by one person with other priorities.
The Questions to Ask in the Handover, If You Still Can
Most people reading this have already started and the handover has gone. If you haven't, or if your predecessor is still reachable, five questions are worth more than anything in the documentation.
Who have you been going to for laptops? Phrased as a person rather than a process, because the answer is a name and the name is what you need. Predecessors often can't describe the process and can always name the person.
What has gone wrong recently? Recent failures are the fastest route to understanding where the weak points are, and your predecessor remembers them vividly because they dealt with them. You'll get more from this than from any document.
What were you about to fix? There's usually something on a list that never got started, and it's usually a real problem that somebody had already diagnosed. Inheriting a diagnosis is a considerable head start.
Is there anything you think I'll find out the hard way? Open enough that people answer it honestly, and it surfaces the thing nobody writes down: the vendor relationship that's strained, the register everybody knows is wrong, the arrangement that only works because one person does something manually every week.
Who should own this? Your predecessor has an opinion about where equipment belongs and probably tried to get it assigned. Their view on why that didn't happen saves you repeating the attempt in exactly the same way and getting exactly the same answer.
If the handover is gone, the same five questions work on whoever has been handling equipment informally. They'll have better answers than your predecessor did, because they're the ones doing it.
Write the answers down. In three months you'll have forgotten half of what you were told in week one, and the half you forget is usually the part about why something is the way it is, which is exactly what you'll need when you propose changing it.
Reading an Inherited Register Without Trusting It
You'll be handed a spreadsheet, and the question is what you can conclude from it before you've verified anything. More than you'd think, actually, and it takes an hour.
Compare the device count to the headcount. More devices than people is normal and the ratio tells you something. Around 1.2 devices per person suggests a modest spare pool and reasonable hygiene. Above 1.5 suggests devices that have left and never been removed. Below 1.0 means the register is missing machines rather than that people are sharing, because shared laptops are rare and unrecorded ones are not.
Look at the date distribution. If most entries cluster around one date, the register was built in a single exercise and hasn't been maintained since, which tells you its accuracy decays from that date forward. If the dates are spread evenly, something has been keeping it current.
Check the oldest entries. A register with devices from six years ago still marked active is holding machines that have almost certainly gone. That's not a small error, it's an indication that nothing is ever removed, which means the count is inflated by an unknown amount.
Count the blanks. Empty serial numbers, missing holders, no dates. The proportion of incomplete rows is a decent proxy for how much the register was used versus merely maintained, because a register somebody actually works from gets its blanks filled.
Look for the people who left. Cross-reference a handful of names against your leavers list. Devices still allocated to people who left eighteen months ago is the single clearest signal that the departure process doesn't recover anything, and you can establish it from a spreadsheet in ten minutes without talking to anybody.
| Signal | Reading |
|---|---|
| 1.2 devices per person | A modest spare pool, reasonable hygiene |
| Above 1.5 | Devices that left and were never removed |
| Below 1.0 | The register is missing machines |
| Dates clustered on one day | Built once, never maintained |
| Entries six years old, still active | Nothing is ever removed |
| Leavers still holding devices | The departure process recovers nothing |
I'd spend the hour on this before deciding where the sample should focus. On one register of 318 rows the clustering signal alone showed the file had been built 14 months earlier and abandoned, which set the expectation for everything that followed.
None of that is verification and all of it is orientation. It tells you which of the three situations you're in and roughly how big the problem is, which is what you need in week one to decide where the sample should focus.
The Things to Deliberately Not Do
A new leader's first quarter has more available actions than time, and some of the available ones are actively costly. Five worth avoiding.
Don't announce an equipment programme. It sets an expectation of visible change on a timescale you can't meet, in an area nobody was asking you to fix, and it spends credibility you'll want later for something that matters more. Fix things quietly and let the absence of complaints be the announcement.
Don't change a vendor in your first ninety days. You don't yet know whether the problems are the vendor or the internal process, and switching while that's unclear usually relocates the problem and adds a migration. Measure for a quarter first.
Don't restructure something that works. Equipment is often handled carefully by somebody who's been doing it without recognition for years. A new leader reorganising it in month two loses that person's goodwill permanently, and in the scenario where you most need an ally.
Don't attempt a full inventory. It stalls, it's invisible, and it produces a snapshot that was never accurate at any single moment. Sample instead, which gives you a defensible number in two days and a statement you can repeat to anybody who asks.
Don't set a refresh policy yet. It needs a reliable register and a budget cycle, and you have neither. Setting one on bad data produces a plan that has to be revised within months, and that costs considerably more credibility than waiting for good data would have.
What all five have in common is that they feel like leadership. They produce the least. The things that actually land in ninety days are small, specific and mostly invisible: an email template, an earlier address request, a sample, a name on a document, a step in the offboarding checklist. None of them looks like a programme and together they change what people experience.
If you want one visible thing, make it the day-one experience, because it's the only item on the list that the people forming an opinion of you will notice directly.
What to Say When Somebody Asks What You Found
Around week six or eight, somebody senior will ask how it is going, and equipment may come up. How you describe what you found shapes whether you get the owner and the budget later, so it is worth having the two sentences ready.
The weak version is accurate and useless: the register needs work and nobody really owns equipment. True, vague, and it invites the response that it has always been like that.
The strong version is the same information with numbers attached. We sampled twenty-five register entries and four were wrong, so the record is directionally right and specifically unreliable. Of the last ten leavers, three returned a device. Equipment has no named owner and the two causes behind most of the register errors are internal transfers and local purchases.
That version does three things the weak one does not. It demonstrates that you measured rather than formed an impression, which is the difference between a finding and a complaint. It gives the person something specific to react to. And it implies the fix without asking for anything yet, which means that when the ask does come it lands as the obvious next step rather than as a request.
Pair it with what you have already done, in the same breath. New starters now get a confirmation email when their order is placed, we ask for the delivery address at offer stage rather than week one, and the last four joiners had a working laptop on day one. Small, specific, already done.
The combination of a measured problem and a shipped fix is what makes the later request for an owner or a budget reasonable. A leader who arrives, measures, fixes something cheap and then asks for one thing is in a strong position. One who arrives and asks for a programme is not. Nowhere near.
Avoid naming individuals as the cause of anything. The gaps you found are structural, equipment is unowned by default in most companies, and attributing them to whoever has been handling it informally is both unfair and the fastest way to lose the person you most need on your side.
The Cost of Getting This Wrong
The cost of ignoring equipment in your first ninety days is that it stays unowned, and unowned functions don't stay still, they degrade. The register gets less accurate, retrieval keeps failing, and the day-one experience keeps being whatever whoever noticed made it.
The cost of starting in the wrong place is subtler and more common. A new leader who opens with a three-month inventory produces a document, changes nothing anybody experiences, and has spent their most credible quarter on something invisible. The register mattered; the sequencing was wrong.
The third cost is the opposite error: changing a working system to make a visible mark. Equipment is often handled informally by somebody who has been doing it carefully for years without recognition, and a new leader restructuring it in month two loses that person's goodwill permanently, usually for no improvement.
And the fourth is the departure gap. It costs continuously. Devices not coming back, written off one at a time, in a process nobody measures. For a company of two hundred with normal attrition that's a number worth knowing, and it's usually the strongest argument you have for getting an owner assigned.
So the question worth asking in your first week isn't what the equipment process should be. It's whether three people give you the same name.
When You're Ready to Move Beyond Surviving the Quarter
Day ninety-one is when the real work becomes possible, and it's worth knowing what you've earned.
With a working day one, you have credibility with hiring managers. With an error rate, you have a baseline and a defensible statement about the register. With a named owner, there's somebody to hand the next thing to. With a departure step, the biggest continuous loss is slowing. Four things. That is a position from which a refresh policy, a vendor evaluation or a budget request reads as a reasonable next ask rather than as an ambitious one.
What comes next, roughly in order: a standard build list per role so most requests stop being decisions, a refresh cycle on its own budget line so it doesn't lose to hiring every month, and a view on whether your current arrangement covers the markets you're actually hiring in. All of those need the baseline. None of them is a ninety-day task.
RemoAsset is our own product. So apply the appropriate scepticism. The part relevant to somebody arriving into an undocumented operation is narrow: everything issued from the point you arrive is recorded against a person and a date, which means your record gets accurate going forward even though the history doesn't. It has no network discovery, so the devices nobody recorded before you arrived stay invisible until somebody asks people directly, and no software licence management.
If you started recently and nobody has told you whether equipment is yours, ask three people this week. The answers are your first finding.
Frequently Asked Questions
What should I do about equipment in my first week?
Two things, both taking about an hour. Ask three people separately who owns equipment: your senior IT contact, whoever handles procurement, and the manager who most recently hired. If the answers differ, that's your main finding. Then ask the last three joiners what their first week was like, because they remember vividly and nobody has asked them.
Should I start with an inventory of what we own?
No, start with what new starters experience. A register project is slow, invisible and improves nothing anybody is currently feeling, so three months of it produces a spreadsheet and no observable change, which is how a first quarter gets described as administrative. Fix day one first, because it's fast, visible and noticed by the people whose opinion of you is forming.
How do I find out how accurate the register is?
Sample twenty-five entries at random with no substitutions and confirm each directly with the person named, one question including the serial number. Two days of work. It gives you an error rate rather than a corrected list. Under five per cent is reliable, five to twenty is the normal state and means verifying before acting on individual rows, above twenty means the maintenance process needs changing.
What is the fastest way to diagnose the whole operation?
Check whether the last ten leavers returned their devices. Retrieval is the first thing to fail and the last thing anybody notices, because nobody internally is waiting for a returned laptop, so it's an accurate indicator of whether the operation has an owner. It takes about an hour and it tells you more than reading any process document.
What should I fix about day one specifically?
Usually three things, none needing budget. Send the new starter one email when the order is placed, confirming what's coming, when and where, because the complaint is generally the uncertainty rather than the delay. Ask for the delivery address earlier than week one of onboarding. And check the machine is configured before it ships, since a laptop that arrives on time and then takes a day to set up has arrived late.
What if the system I inherited is working fine?
Verify it in a day and leave it alone. There's a real temptation to change something in a functioning area because it's easy and visible, and it costs you the goodwill of whoever has been quietly doing it carefully for years. Say that it works, put your attention where it's needed, and name the person who has been handling it.
What should I have in place by day 90?
Four things: a day-one experience that works, an error rate for the register, one named owner with equipment explicitly in their remit, and a departure step with a prepaid return. Each of those makes the next thing possible. What you should not attempt is a refresh policy, a vendor change or a new system, because those all need the baseline and a budget cycle you haven't reached.
How do I get equipment formally assigned to somebody?
Argue the cost of the gap. Not the principle. Equipment is unowned because HR, IT and finance each have a reasonable claim to not owning it, so a debate about where it belongs goes nowhere. What moves it is a specific number: here are the devices we cannot account for, here are the departures that returned nothing, and this is what it costs every year until somebody owns it.
Ask three people who owns it, and start wherever the answer leaves you.
