Origin
Pranay, one of our founders, was on a call with an IT manager three new hires deep into a week with her senior engineer out on leave. She walked through her onboarding process, stopped about halfway, and said the word process was doing a lot of work in that sentence.
It's the Tuesday after a long weekend.
Three people start this week: one yesterday, two on Wednesday. Your senior IT person is out until Thursday. The contractor who normally handles the GitHub org is between engagements. And somewhere in the queue is a role change from last Friday, a sales rep who moved into a director seat and needs different Salesforce permissions before a customer call at 2pm.
This isn't an unusual week. This is a Tuesday.
The ticket exists. That much is true.
When the Monday hire's manager filed the request last Thursday, a ticket was created with a due date, an assignee and a set of checkboxes. Salesforce, NetSuite, Confluence, the LIMS the lab team runs on, the analytics dashboard marketing lives in, the project management tool that predates your Jira migration by two years and still holds three active projects.
The ticket is real. What it isn't, and was never designed to be, is a guarantee.
A guarantee means the new hire has their access on day one. Same outcome every time, for every role. It doesn't matter who's on the team this week. It doesn't matter how many other tickets are moving at once, or whether the request landed on a Thursday before a long weekend.
That's a process. What most teams have is a queue with a process name on it.
The difference shows up the moment anything applies pressure.
Your senior person goes on leave and the queue slows down. Not because everyone else is worse at the job, but because the knowledge of which AWS account, which GitHub org, which Tableau project lives in one head. The ticket says add to GitHub. It doesn't say which org. Your backfill knows enough to close the ticket. They don't always know enough to close it correctly.
Three hires in a week is a full provisioning job three times over, across every app that doesn't provision itself, landing on a team that also has a permissions change, two review deadlines, and an SSO config that's been throwing errors since last week's update.
Something moves to the back. It's whatever isn't actively blocking a person yet. The Tableau access. The contractor's repo permissions. The role change filed late Friday that assumed it would be handled by Monday.
Then Monday arrives and someone asks where it is.
Onboarding failures call you. Within the hour, the new hire pings their manager, the manager pings you, and the gap closes. Loud, and self-correcting. Nobody has to remember to check.
Offboarding failures don't call anyone. No former employee files a ticket saying they can still see the finance drive. No app sends a note when an account survives a termination. Those failures don't get louder over time, they get quieter, and they accumulate in the same queue as everything else while the loud ones keep jumping ahead of them.
So the queue isn't just slow. It's sorted by volume of complaint, which is close to the opposite of sorted by risk.
Tickets are a reasonable response to an unreasonable situation. They create accountability where there'd otherwise be none, and they make the work legible to people outside it. What they don't do is change the shape of it. A tracked problem and a solved problem look the same on a dashboard.
The instinct at this point is better ticket hygiene. Priority fields, SLA timers, escalation paths. The queue gets tidier and stays exactly as long.
The better question is which of these tasks belong in a queue at all. Provisioning and offboarding aren't judgment calls. They're a role, a department, a start date and an end date applied to a consistent set of rules. When employment is the trigger, and access propagates from the HRIS across the apps behind your SSO and the ones that will never be behind it, there's no queue to fall behind on. Nothing to reprioritize when a senior person takes leave. Three hires in one week stops being a capacity question.
The ticket doesn't get closed faster. The ticket doesn't get filed.
Calling a queue a process is understandable. It's what you have, and it's what almost everyone has. Where it starts costing you is when the rest of the company believes it too, because then a bad Tuesday reads as a staffing problem and the fix goes in the wrong direction. More hands on a queue is still a queue.
We'd take one of your recent onboardings and show you what it looks like with no queue behind it. No deck. Just the product.