| 13 min read

The Company Installed Monitoring Software. Your Team Thinks It Was Your Idea.

Your company rolled out monitoring software on your remote team. You did not choose it, but your team will judge you by how you use it. What to do first.

The email came from IT on a Tuesday afternoon. Starting next month, every company laptop will run a new productivity tool. It records active time, the applications in use, and, on some settings, periodic screenshots. Managers will get a dashboard. Within an hour, two people on your team have messaged you privately, and underneath the different wording they are asking the same thing: did you ask for this? Our guide to managing remote teams has a whole section on trust, but it is written for the manager who is tempted to reach for monitoring. This page is for the manager who did not reach for it and got it anyway, because somebody above you decided.

That difference changes almost everything about the job. You cannot uninstall the tool. You can decide what it means on your team, and your team will judge you entirely by that decision, whether or not you make it on purpose.

What this article is not about

Two pages here own the neighboring problems, and this one stays narrower than both.

Whether monitoring works. The trust section of the remote team guide makes that case, with the research behind it. Here the tool is a given. The question is what you do inside a decision you did not make.

Watching your people more closely to be fair to them. Our piece on proximity bias on hybrid teams covers why extra attention aimed at remote people reads as surveillance even when you mean it kindly. This page is about software the company chose, not attention you chose.

One more boundary. What an employer may monitor, and what it has to disclose, differs by country and by state. Nothing below is legal advice. If a question turns on what is allowed, it belongs with HR or legal, and the most useful thing you can do is ask it early.

Your team’s first question is not about the software

When people ask whether you requested the tool, they are not asking about features. They are asking two things: who decided, and what you will do with what it shows. If you leave either question unanswered, they will answer it themselves, and the answer they reach for is the worst one available. You asked for it, and you will use it against them.

So answer both, quickly, and in that order.

The first answer has a trap in it. Our guide to managing up as a new manager has a rule for the squeeze between your boss and your team: never throw your boss under the bus. Even when you disagree with a decision, you own it, and you do not say “they are making us do this.” That rule still holds here. But owning a decision is not the same as claiming you made it. Pretending the tool was your idea, to look loyal upward, is a lie your team will eventually see through. Disowning it with a sigh, to look loyal downward, is the bus the rule warns about. The honest version sits between them: state where it came from as a fact, without commentary, and then take ownership of the part that is genuinely yours.

Something like this, sent the same day the announcement lands:

“You will have seen the email about the new tool. It is a company-wide rollout, not something requested for our team. I do not know yet everything it collects or who can see it, and I have asked. Here is what I can tell you now: how I will use it on this team, and how I will not. I will follow up as soon as I have the answers.”

That message does three things. It removes the suspicion that you requested it. It does not criticize the people who did. And it promises the one thing that is actually in your control, which is how you will behave.

Get four answers before you promise anything

You cannot tell your team how you will use the tool until you know what the tool is. Before your follow-up message, get answers to four questions, in writing if you can:

  1. What exactly is collected? Active time, applications, websites, screenshots, keystrokes, location. These are very different tools that often share one product name.
  2. Who can see it? Only you, HR, IT, your own manager? Individual records or only team totals?
  3. How long is it kept? A week of data and two years of data are different promises to the people being recorded.
  4. What is it allowed to be used for? Security, capacity planning, performance reviews, discipline? If the answer is “anything,” ask whether that is a deliberate decision or one nobody has made yet.

These are not bureaucratic questions. They are the ones that decide how monitoring lands with the people being monitored. In a study of people working under different levels of computer surveillance, Bradley Alge found that monitoring activities relevant to the job, and giving the monitored people input into the process, reduced their sense that their privacy was being invaded and raised their sense that the process was fair (Alge, Journal of Applied Psychology, 2001). Relevance and participation are exactly what these four answers let you talk about honestly.

Do not promise your team anything that depends on an answer you do not have yet. “Nobody will see screenshots” is a promise you can only keep if you know who can see them. If you do not know, say you do not know.

Decide what you will never use it for

This is the most important decision on the page, and it is entirely yours. Write it down before the first dashboard arrives, because once you have seen a number next to someone’s name, it is much harder to decide not to care about it.

A workable version has two parts:

  • Activity data will never be the first thing you raise with someone. Every conversation about work starts with the work.
  • Activity data will never be the evidence in a performance conversation or a review. Performance is judged on the outcomes you agreed, the same way it was before the tool existed.

Then tell your team that rule, in those words, and keep it even when it would be convenient not to.

The reason to make the rule explicit, and to apply it evenly, is that how fair people find the whole arrangement turns out to matter a great deal. Across a field study and an experiment, Chase Thiel and colleagues found that monitoring can lead to more rule-breaking rather than less, because it weakens people’s sense of agency and makes it easier for them to displace responsibility for their own behavior. Where employees saw their organization as fair overall, that effect was weaker (Thiel et al., Journal of Management, 2023). You cannot change the software. You have a lot of say in whether your corner of the organization feels fair.

Fairness here is mostly consistency. If one person’s quiet afternoon gets a question and another’s does not, the tool has become a way of expressing who you already trust. If you are not sure you apply the same standard to everyone, the Am I Playing Favorites? quiz is a quick, private check before your team runs that check for you.

When the dashboard flags someone

At some point the tool will tell you that somebody had a low-activity day, or spent two hours in an application that has nothing to do with their job. What you do in the next ten minutes is the real policy, whatever the written one says.

Work through it in this order:

  1. Check the work, not the activity. Is the thing they own on track? If it is, you have learned nothing you needed to know.
  2. If the work is fine, let the flag go. Do not mention it. A tool that records keyboard and mouse activity will misread anyone whose job involves reading, thinking, phone calls, or whiteboards, and the most useful people on a team are often the worst-measured by it.
  3. If the work is not fine, have the conversation you would have had anyway. About the work.

The difference shows up in the first sentence.

Opening with the data: “I noticed your active time dropped to under four hours on Wednesday.”

Opening with the work: “The draft was due Wednesday and I have not seen it yet. What got in the way?”

The first version teaches the whole team, within a week, that the dashboard is what you manage. People will optimize for the dashboard, and you will have built exactly the behavior the tool was supposed to prevent. The second version is a normal management conversation that would have happened with or without the software. If the reason turns out to be something the tool can see, it will come up on its own.

Give the team the parts of the process you can

You do not control the tool, but you usually control more of the process around it than you think. Alge’s finding is a practical guide here: participation reduces the sense of intrusion, so offer what participation you genuinely can.

  • Collect the questions. Ask the team what they want to know about the tool, and take those questions to HR or IT as a list.
  • Ask what it misreads. Every role has work the tool cannot see. Get specific examples, because “it does not capture my work” is easy to dismiss and “I spend Tuesday mornings on customer calls from my phone, which the tool logs as idle” is not.
  • Close the loop. Report back what changed and what did not. A request that disappears into HR without an answer does more damage than not asking.

Be careful not to promise outcomes. You can promise that their questions will reach the people who decide, and that you will tell them what came back. That is a promise you can keep.

Push back upward without turning it into a fight

If you have concerns about the tool, raising them is part of the job, not disloyalty. How you raise them decides whether anything changes.

The managing-up rule about advocating with data rather than emotion does most of the work. “My team is upset” gives your boss nothing to act on. These give them something:

  • “Two of my people do most of their work in calls and reading. The tool logs that as idle, so its reports on them will be wrong. Can we exclude call time or turn off individual activity scores for roles like this?”
  • “The announcement does not say who can see individual records. People are assuming the worst. Can we publish who has access and what it is used for?”
  • “Screenshots are the setting people are most worried about. Is that setting needed for what the company is trying to achieve?”

Each of those asks for something specific and small. That is deliberate. “Please remove the tool” is a request you will lose, and losing it costs you credibility for the next one. A narrower request that makes the tool more relevant to the job and more transparent is far more likely to land, and it is the version the research above actually supports.

Then, whatever the answer, do not take your disappointment back to the team. You can tell them what you asked for and what happened. You cannot tell them you think the decision is stupid without breaking the rule you started with.

What not to do

A few moves feel natural and quietly make everything worse.

Do not joke about it. A “Big Brother is watching” line in a team meeting tells people you think it is sinister and are going along with it anyway. That is the worst of both positions.

Do not become the activity police. If you find yourself checking the dashboard every morning, notice that it is now a daily oversight task competing with your actual job. The micromanagement cost calculator puts a rough number on what that kind of oversight time costs, and it is usually more than people expect.

Do not say one thing and do another. If you told the team you will not look at individual activity, do not look. If your organization requires you to review it, say so, and say what you will do with it. People can work with a strict rule. They cannot work with a rule that turns out to have been untrue.

Do not help anyone defeat the tool. You may privately think it is a bad idea, but advising someone to get around a company policy puts their job at risk, not yours. Argue for changing the policy instead.

Do not punish questions. The person who asks the awkward question in the team meeting is doing the rest of the team a favor. Treat it that way.

At thirty days, check what changed

The tool will produce plenty of numbers. The ones that matter will not be in it. A month after rollout, check the things that tell you whether trust survived:

  • Are problems still reaching you early? If the first you hear of a slipping deadline is the deadline, people have started managing their image instead of their work.
  • Do your 1-on-1s still contain bad news? A month of 1-on-1s with nothing difficult in them is not a calm team. It is a careful one.
  • Has anyone gone quiet? Your strongest people have the most options and the least patience for being measured badly. The Am I About to Lose My Best Employee? quiz is a fast way to look at the early warning signs one person at a time.

It also helps to make sure the tool is not your only view of the work. The three-question weekly check-in from the async section of our remote 1-on-1 guide (top priority this week, anything blocking you, anything to discuss) shows you what people are working on and where they are stuck, in their own words. Once you have that, the activity data has very little left to tell you.

The one-line version

You did not choose the tool, but your team will judge you by how you use it, so decide what it will never be used for, say it out loud, and keep saying it.

Toolkits

The Scripts and Templates, Ready to Use

Guides tell you what to do. The toolkits hand you the wording: scripts for the conversations you are putting off, a first 90 days playbook, one-on-one kits and cheat sheets you can print and keep on the desk.

Browse the Toolkits →