Case studies.

The problem

Setting up a new hire took about two and a half hours. Someone ordered a laptop, imaged it by hand, then copied another person's permissions because that was quicker than working out what the role actually needed. It worked. It also meant access quietly spread to people who were never meant to have it, and every new hire cost someone an afternoon.

What I changed

I made the HR system the starting point instead of a place someone remembered to check. A hire there fired an automation that told me who was joining and what role they were in. Hardware was ordered against that, and because Miradore was tied into Apple's enrolment, the machine configured itself before it ever reached the person. Okta provisioned their access from the role, not from whoever sat nearby.

Zero-touch describes the device, not the whole process. Nobody in IT touched the laptop. One person in IT did approve the account, from a Slack message, before it was created, and that was deliberate: an HR record can be wrong, and a wrong laptop is a return label while a wrong account is access. The approval took seconds and it stayed in.

What it gave back

About thirty minutes instead of two and a half hours, and most of that is waiting. More than 250 people went through it. Nobody imaged a laptop again, and access matched the job description instead of an accident of seating. The same machinery ran in reverse when people left.

The problem

Onboarding gets attention because somebody is waiting and visibly unhappy. Leaving gets none, because the person who would complain has gone. So access lingers. A resignation on Friday becomes a live account on Tuesday, still holding a session, still inside the applications, waiting for someone to remember to file the ticket.

The uncomfortable version of the question is this: if someone left badly this afternoon, how long would they keep their access? Any answer measured in days is a real answer, and it is not a good one.

What I built

HiBob was already where HR recorded the truth about who worked at the company, so it became the trigger at both ends. When HR marked someone as terminated, that change flowed into Okta and access was revoked across everything at once. IT did not need to be told, because IT was not the one who knew first. HR was.

That is the whole idea. Every slow offboarding I have seen was slow because it waited on a human relay: HR knows, HR tells a manager, a manager files a ticket, a ticket reaches someone with the right permissions. Cut the relay and the delay goes with it.

Proving it, not just believing it

Automation you cannot audit is a story you tell yourself. SOC 2 asks you to demonstrate periodically who has access to what, so I ran access review campaigns against Snipe-IT, which held the record of what had been issued to whom. Reviews are only answerable if something has been keeping score, and that was the thing keeping score.

The reviews paid for themselves twice. They confirmed that leavers were genuinely gone, and they surfaced the quieter problem: people still holding tools they had stopped needing a role change ago. Those licences came back too, which turned a security control into a line of recovered budget.

Why I wrote the HR half myself

Okta already did the downstream work well. Once an account existed, SCIM pushed it out to Google Workspace and the rest of the applications, and I left that alone. The part I built sat upstream of Okta: a scheduled job on a small AWS host, stood up with Terraform, that watched HiBob for a new hire or a termination and created or suspended the Okta account to match. A new account waited in Slack for a person to approve it before anything was created, and the message carried what you need to judge it and to find it again later: name, position, location, start date.

The off-the-shelf route would have been to let Okta import from HiBob directly and lean on its lifecycle rules. That would have created the account. It would not have paused for approval, and it had no idea that the same hire needed a laptop record in Snipe-IT. A cron job with an approval step in Slack was a defensible choice for a six-person IT team that needed both, and once it was set up it rarely needed touching.

What I would do differently today

I would start from Okta's own HiBob import and Okta Workflows, and keep custom code only where they fall short, which is a shorter list now than it was then. The licence parity check between Snipe-IT and HiBob would stay a script regardless, because that is asset data, not identity, and SCIM has nothing to say about it.

What the automation assumed

Both halves of the lifecycle worked. HR hired someone and the accounts appeared; HR marked someone as leaving and the accounts vanished. I was pleased with it. It handled every case I had thought of, which turned out to be the problem, because I had drawn the lifecycle as a line with a beginning and an end.

What actually happened

Someone left, and about three months later they came back. Nothing in the pipeline knew what to do with that. They already existed in HiBob, so there was no new person to create, and HiBob had no way to express the idea that a previous employee was an employee again. It could hire and it could terminate. It could not restore. Workflows broke, and the automation I had built to remove human effort quietly handed the work back to a human.

The half I had not thought about

The account was the easy part. Offboarding does not only take access away, it moves things: when this person left, their data had been handed to a colleague so the work could carry on. That was correct at the time and it was now in the way. Bringing someone back meant unwinding a transfer of custody, taking data off the person who had inherited it and returning it to the person it started with.

I had built a process that assumed the handover was permanent, because when I built it, every handover had been.

What I changed

I could have patched around the one person. Instead I put a rehired state into HiBob and synced it to Okta, so a returning employee is a case the system recognises: accounts created properly, access restored to what the role calls for. Alongside it, a defined path for reversing the data handover instead of working it out from memory each time. The hiring workflow itself changed, which is the part I would point at.

What I took from it

The automation was not buggy. It did exactly what it was built to do, and it was complete for the model it was built on. The failure was in the model, which is a harder kind of mistake to catch, because everything you test passes.

People do not move through an organisation in a straight line. They leave and return, they change roles, they go on leave, they come back into a different team. Since then I design for the loop rather than the line, and I ask what happens on the way back through.

The problem

Single sign-on is a convenience and a risk at once. Put every application behind one login and you have made that login worth stealing. A password and a session cookie will let someone in from anywhere in the world, and the system has no reason to think anything is wrong.

What I built

Sign-in had to come from a device we managed. It had to come from a country on our approved list, enforced through Okta network zones, so a laptop carried somewhere we did not operate simply would not authenticate. Sessions lasted a day, after which you re-authenticated with your YubiKey rather than a code anyone could be talked into reading out. For the accounts that could reach the most, device and country were not enough on their own and the IP had to match too.

The part people forget

A policy this strict fails the moment someone flies somewhere for two weeks. So travel outside the approved list went through a review: what is this person's role, what data do they actually touch, and what do they need while they are away. The answer was either approval or a window with an end date on it.

The moment

Awareness training lowers how often this happens. It does not take it to zero, and planning as though it will is how organisations end up improvising during the one hour that matters. Somebody clicked. The interesting part is not that it happened, it is what the next twenty minutes looked like.

The sequence

Access first. Revoke it immediately, before working out how bad it is, because the cost of revoking access to someone who turned out to be fine is an apology and a coffee. The cost of waiting while you investigate is measured differently.

Then the device. Quarantine it rather than trusting it, and only then start answering questions: what was the email, what did they click, what ran, what was installed. From there the wider question of whether anything else was reached, which is the one that decides whether this is an incident or an event.

The device came back to them once it was confirmed clean. Not once it seemed fine, and not once the person asked nicely, which they did.

What we did anyway

Because the company worked in the cloud rather than on the endpoint, the exposure was limited, and it would have been easy to treat the whole thing as a scare and move on. We followed the full protocol anyway.

The plan

Day one. The plan was already written and it was waiting for me: take a USB stick to each computer and upgrade it by hand. Roughly 1,500 machines across more than forty dealerships. Windows 7 was reaching end of life, so they were right that the machines had to move. They were wrong about how, and nobody had questioned it, because the person expected to do the walking had only just arrived.

The question I asked instead

Before agreeing to anything I asked what systems the company already had. The answer included Kaseya. It was installed, paid for, and reaching every one of those machines, and nobody was using it for this. I spent that first day finding out how far it could be pushed, got a rolling upgrade running, and showed them. It was the first thing I did at the company, and it replaced the plan.

Why a new hire argued on day one

Walking a USB stick to 1,500 machines is not a plan, it is the absence of one. We work in IT. Automating the tedious thing is not a luxury we earn once the real work is done, it is the job. A new person arguing with the plan on their first morning is a risk, and I knew it. The alternative was months of my life, and everyone else's, spent on something a tool the company already owned could do on its own.

The constraint that shaped it

Dealerships do not close so that IT can have a quiet weekend. Every one of those sites was selling and servicing cars while we worked, and a machine that came back wrong meant a salesperson standing in front of a customer with nothing.

How it ran

Kaseya did the upgrading, in waves, grouped by geography rather than by department or alphabetically. Each wave was a handful of dealerships close to one another. If something went wrong, the damage was concentrated somewhere I could drive to, instead of scattered across the province in ones and twos. Nobody lost a working day to the migration.

The machines that could not move

Some ran software that only worked on Windows XP. That was not a preference, it was the vendor. Upgrading them was not possible and leaving them on the network was not acceptable, so I segmented them off from everything else and kept management access through Kaseya. They stayed reachable for patching and support while losing the ability to reach anything that mattered.

What I took from it

Ask what the company already owns before accepting the plan. The tool that saved months was already on every machine; the only thing missing was someone willing to say so on their first day. I have started every job since with the same question, and it has never come back empty.

What I walked into

Twenty-five people across eight clinics, running on paper. Patient files in cabinets. Follow-ups written on sticky notes, which is fine until one falls behind a desk. If you needed to know something, you asked the person who knew, and if that person was on vacation you waited until they came back. All of it under PHIPA, Ontario's health-privacy law.

What I built

I digitised the filing system and had the paper shredded. BitLocker went on every machine, because encrypted records in a cabinet nobody locks is not a plan. The sticky notes became automated reminders on a daily, weekly, and monthly schedule, so the work arrives instead of being remembered. Payment tracking became automatic too: who still owes for their dentures, and for how long. Where the clinic software's own reporting was thin, I built on top of it rather than around it.

The knowledge base

The piece that changed the most was writing things down. Procedures, troubleshooting, onboarding, access rules, all of it in one searchable place with access matched to role, so people see what belongs to their job. An answer that used to take a day, or weeks if the one person who knew was away, now takes seconds and does not depend on anybody being at their desk.

Tracking a denture through the lab

The harder half was production. A denture passes through several stages and several pairs of hands, and the way you knew where one had gotten to was to remember the case, look at a whiteboard, or walk over and ask. When a patient called to ask how much longer, somebody had to go and find out.

So I built DentureFlow, which the labs now run on. Taking a patient's impressions opens a case. A barcode follows it through every stage, so who has it, and who had it before, is a matter of record rather than memory. Work is routed with a time estimate weighted by what the assignee already has on their bench. It syncs with the hardware that prints the dentures. Reception can answer where a case is without leaving the desk.

It has carried more than three hundred cases.

The offices that refer to us

Some of the work arrives by referral from dental offices. That used to mean collecting the same details twice, once from the office and once from the patient, and a run of calls to fill the gaps. Referring offices now have their own accounts and send the details before the first visit, so the information is there when the patient walks in. Management hands out that access.

What it says about the work

I was the whole IT department for this. No team to delegate to, no budget to throw at it, and a staff who did not sign up to learn software.

The problem with a helpful assistant

An internal wiki is only useful if people find things in it, and ours was large enough that they often did not. The obvious fix is an assistant that answers questions from the documentation. The less obvious problem is that a naive one will happily tell anybody anything it has read, which turns your access model into a suggestion.

What I built at Aiven

An assistant over the internal knowledge base that answered according to the asker's role. Someone in one team asking a question got what their role was entitled to see, and nothing from behind a boundary they were not on the right side of. It is the same role-based access control I was already running in Okta, applied to retrieval instead of applications.

The same idea under health privacy

In my current job the constraint is sharper: patient information cannot leave the building. So the automation runs on a local model rather than an API somewhere else. It reviews call recordings to find where reception can improve, with rules added as new situations come up, and checks patient records for missing or outdated details so someone can follow up before it matters. The privacy requirement decided the architecture.

The half of IT nobody lists

Identity and automation are the work I would describe first, and they leave no marks on your hands. The other half of the job has weight. Laptops arrive in boxes, displays need a desk, and an office is a room full of things that were once somewhere else. Every one of those things has to be recorded, or the records stop meaning anything. I have owned that half at two employers, and the record is the part I would defend.

Two offices, one of them in a suitcase

Aiven's US office started in Boston, and I set it up without going there. A colleague in the area became my hands, I walked them through it over Slack and a video call, and the office came up. Every employee already had their own laptop, so what an office needed was displays, peripherals, and a backup 5G connection for the day the building's internet failed. I tested that fallback when it first went in, because a backup nobody has tried is a hope.

In early 2023 the company closed Boston and opened Austin, and I led the move. There was no overlap: one office packed, the other opened. I flew to Boston, packed everything, and recorded the condition of every item before it went into a box, so that whatever arrived could be checked against what had left. It shipped by UPS. I flew on to Austin, set it up myself as it arrived, tested the 5G fallback again, and went home.

Across town

Toronto moved too, from one office to another, and I led that one with my own car, with Uber filling in for the loads that would not fit. The new space had nothing in it, so I built the IT closet: UniFi at the core, access points I mounted and configured myself with ethernet run through the ceiling, and Google Meet rooms with the Logitech cameras and screens set up so the first meeting in the new office was a meeting and not a troubleshooting session.

When the pandemic moved everyone at once

At Performance Auto Group the move nobody planned for arrived with COVID. We pulled equipment from several offices into the head office in Brampton, chosen because it was open enough to seat people far apart. The company had never needed remote meetings, so there was nothing to fall back on. I set up Zoom so people could talk to each other, handed out laptops, and put a VPN in place so each person connected to their own office or dealership from wherever they were.

Phones for a company that had none

Little of this existed when I arrived at Aiven, and it was mine to build. Company phones meant researching the major Canadian carriers, comparing plans, asking each what they could do on price, and choosing on two things: what would work best for the people carrying the phones, and what would be easiest to administer from the IT side. Telus won in Canada and Verizon in the US. I ordered 25 phones for Canada up front and shipped each one to its employee; in the US I ordered them one at a time as people started.

Behind the phones sat the accounts nobody sees: the ISP, and business accounts with Apple, Lenovo, Amazon, and UPS. Most of those vendors had no single account that worked on both sides of the border, so each got a Canadian account and a US one, every one of them invoicing the right mailbox, with the invoicing automated so it stayed that way. Internet was the one thing I did not get to choose, since the first Toronto office came with its own and the second offered a single building provider. All of it was done from my house, because COVID restrictions were still on. A lot of trust was placed in me at that stage, and I made sure to live up to it.

Keeping score

None of this stays tidy on its own. At Aiven the IT closet was reconciled against Snipe-IT, so the shelves and the records said the same thing, and that same record answered SOC 2 access reviews later. A leaver's laptop went straight to a joiner or back to the shelf, and out again by role. Ordering became role-based: I scoped the machine each role needs, wrote it down, and saved it as a pre-configured list in the vendors' own stores, so a laptop for a new hire is ordered as-is with nothing to re-specify. At Aiven that was about five profiles, with overlapping roles folded into general ones, a refresh cycle timed to Apple's hardware releases, and the HR record's role pointing at the right list, so the zero-touch pipeline and the ordering standards were the same system seen from two ends. Every new hire got the equipment list before their start date, so anyone who needed a particular peripheral, or an accommodation, could say so while there was still time to order it. The same lists cover the mouse, display, keyboard, and camera, so they go out without anyone deciding again. I have built that set of standards at three employers now, because it pays for itself within the first few hires. When Apple's supply chain slipped, the record was what told me how much slack we had. I also wrote the device buy-out policy: three years' tenure and the laptop, monitor, or phone is yours to keep; leave earlier and you can buy it at a calculated price or send it back.

What I took from it

Logistics is where IT meets people on a hard day. A new colleague who had just moved to Canada had a pile of equipment waiting at the Toronto office and no car, so I drove them home with it and set it up in their apartment. After a Toronto event I drove new colleagues to the airport rather than let them fight expense claims that had not been set up yet. I asked in Slack whether anyone needed help, and automated the small tasks people mentioned. None of that is on a resume, and all of it is the job.