Hey Wranglers,
At some point in the next year, a lot of IT and HR leads are going to have a version of the same conversation with their team:
"We're going to start tracking requests more formally. Everything that comes in will go through a system. We'll be able to see volumes, response times, and who's handling what."
And the first thing at least one person on that team will hear is: they're watching us now.
How you handle that moment determines whether the rollout builds trust or destroys it.
Key Takeaways
When you introduce visibility into a team's work, the instinct is to frame it as an operational improvement. The team hears something different: performance monitoring.
The agents most likely to push back are often the ones doing the most work. They're not afraid of being watched. They're afraid the numbers won't reflect what they actually do.
Visibility that benefits the team first - recognition, workload balance, the ability to prove capacity - lands differently than visibility that benefits leadership first.
Real Talk
There is a version of tracking that is surveillance. Time-on-task monitoring, screenshot tools, keystroke logging - the category of software that became common during the remote work years and generated a lot of legitimate anger.
But most IT and HR leads aren't doing that. They're trying to make visible the work that's currently invisible - requests that come in through DMs, questions that get answered in threads and disappear, tasks that get completed with no record that they happened. That's a fundamentally different thing, and conflating it with surveillance is one of the reasons good rollouts fail.
The distinction that matters is this: who benefits from the visibility?
Surveillance is visibility that flows upward. Management can see what employees are doing. Employees get nothing from the arrangement except the knowledge that they're being watched.
Operational visibility, done right, flows in both directions. Yes, leadership gets data. But the team also gets something: a record of what they actually did. Recognition for work that was previously invisible. A number they can point to when someone asks why they need another headcount. A way to show that the volume coming at them is real, not a perception.
When you introduce tracking as something that serves the team, not just the org chart above them, the conversation changes. And it's worth acknowledging that the team's skepticism isn't always unfounded. Ticket counts and response times become harmful metrics when they're treated as complete measures of individual performance rather than partial signals about workload and service. If your rollout doesn't address that directly, the fear is reasonable.
The rollouts that go well almost always have one thing in common: someone took the time to answer that question before the tool went live.
The answer, when it's honest, usually sounds something like this:
Right now, a significant chunk of what you do every day is invisible. It doesn't show up in any report. When there's a conversation about headcount or workload or how the team is performing, this work doesn't exist as far as the data is concerned. That means you're carrying more than anyone realizes, and you have no way to prove it.
This changes that.
That is a different pitch than "we're implementing a new system for operational visibility." It's also a more accurate one.
The Setup
If you're introducing a tracking or ticketing system to a team that's likely to be skeptical, here's the sequence that tends to work:
1. Start with their problem.
Start with the problem they already have, not the problem you're trying to solve.
For example, they might feel overloaded and nobody believes them. They handle a constant stream of DMs and ad hoc requests that never show up in any report, and when someone asks about capacity or headcount, there's no data to point to.
Lead with that. The tool is the solution to their problem, not just yours.
2. Return the data to the team first.
Show them their own data before you show anyone else. In the first few weeks after a system goes live, the most powerful thing you can do is bring the numbers back to the team before they go up to leadership:
Here's what we found out
Here's how much was invisible
Here's what your actual volume looks like compared to what anyone knew
Let them sit with that first. Give them ownership of the story before it becomes a management report.
3. Define how the data will be used.
Be explicit about what you will and won't use the data for.
If you're not going to use response time data for individual performance reviews, say so directly. If ticket volume is going to inform headcount conversations but not disciplinary ones, say that too.
The fear is usually about how the data gets used, not the data itself. Address it directly.
4. Recruit a credible advocate.
There is almost always one person on the team who immediately gets it, usually the one who's been most vocal about feeling like their work isn't seen.
Get their buy-in early. Let them tell the story to their peers in their own words. A peer saying "this is actually good for us" lands differently than a manager saying it.
Ask Adam
"I'm trying to introduce a ticketing system to our IT team and I'm getting real resistance. Two people in particular seem convinced it's about monitoring their performance. I've told them it's not, but I'm not sure they believe me. How do you actually get past that?"
The fact that telling them didn't work is useful information. It means the concern isn't really about information - it's about trust. And trust isn't rebuilt with explanations. It's rebuilt with evidence.
One approach that tends to work: make the first thing the system does something that visibly helps them, not you. Take the first report it generates and use it to advocate for them: to their manager, to leadership, to anyone with budget authority. Show them that what this produces is a stronger case for their team, not a performance file on individual people.
The people who are most resistant may have been burned by tracking systems before, or may simply doubt that the numbers will capture the full value of their work. Either way, you're not going to talk them out of it. You're going to have to show them a different outcome.
Give it sixty days. By then you should have enough evidence to have a much more honest conversation about whether the system has helped or created new problems.
Let the evidence make the case you couldn't.
Adam Smith
CEO & Founder, Wrangle
PS - When you've introduced a new system to a skeptical team, what was the moment it actually turned? Curious whether it was a conversation, a piece of data, or something else entirely.