Overemployment - one person quietly holding two or three full-time remote jobs at once - is real, and you spot it by reading output and ownership, not by watching people work. The tell is in the deep work. Someone ships the small, safe tasks on time and then goes missing on the architecture call, the roadmap fight, the ugly problem that needs an owner. Define contribution in observable terms and the pattern surfaces without detective work.
I have started at nine or ten companies, and as a fractional product leader I walk into a new org every few months and have to read the team fast. I do not get six months to form a gut feeling. Within a couple of weeks I need to know who is carrying weight and who is coasting, because the engagement is short and the client is paying for judgment.
I also work across several companies at once. Surround Insurance knows I am also inside Arkadium, and Arkadium knows about Surround. That disclosure is the whole deal, and it is where the line between fractional work and overemployment sits. The overemployed person runs the same split without telling anyone. So the useful question is whether the work is getting owned, not how many hours someone logs.
What signals an overemployed remote worker?
The clearest signal is a person who reliably does the shallow work and disappears from the deep work. They close tickets and post status updates, then become unavailable the moment a problem needs an owner.
The pattern looks like a spotless activity log: commits every day, standup notes filed, Slack green. Then a hard design question comes up - how to restructure a core flow, who owns the migration - and the same person takes the note and never comes back with a point of view. The output is fine and the ownership is missing. Someone fully present in the work has opinions about where it is going. Someone whose attention is split protects their bandwidth by playing defense, shipping what is asked and nothing more, because the second job needs the other half of their brain.
The overemployed person is rarely the one who misses standup. It is the one who never owns the hard problem.
In a fast-moving product, it also shows up as latency on the decisions that matter. A person who is all in pushes back on a bad call in the moment. A person stretched across two roles lets it slide, because engaging costs energy already spent somewhere else. You feel it as an odd quiet from someone who should have skin in the game.
Why watching calendars is the wrong way to catch it
Availability is noise. Missed meetings and slow replies come from childcare, chronic illness, a bad week, or an async work style. None of that is overemployment, and treating it as a signal turns you into a surveillance manager who erodes trust with everyone doing honest work.
Leaders who reach for login times and Slack response speed end up punishing the single parent while the overemployed engineer, who is disciplined about looking busy, sails through. People holding two jobs are usually good at optics; that is how they hold two jobs. What survives scrutiny is contribution: what got owned, what got moved, what got decided.
It is the same reason I do not run a team on response time. Fast Slack replies are the easiest thing to fake and say nothing about whether the roadmap is moving. I would rather someone go dark for a day and come back with a real answer.
How to confirm it without spying
Make expectations explicit, then read the gap between full contribution and what you are getting. Most teams never write down what a role is supposed to produce - deliverables, reasonable responsiveness, meeting quality, decisions owned - and that vagueness is exactly what an overemployed worker exploits.
Use one-on-ones for signal. I do not ask anyone whether they have a second job; it is easy to deny and it poisons the relationship. I ask what they are driving this week, where they are stuck, and what they would take off their plate if they could. Someone overloaded from juggling two roles will often say they want to shed work, which is a more useful thread to pull than an accusation.
Peers see it before metrics do. The team already knows who goes quiet mid-week and who skips the moments that need a seat at the table, which is why I treat accountability as a team sport. If you already use GitHub or ticket data in the normal course of work, look for shape - solo commits at odd hours, going dark through a sprint - and hold it loosely. Data without context falsely accuses good people.
What to do once you know
There are two clean options, and the choice depends on whether the person is recoverable and how early you caught it.
If someone is holding two full-time jobs without disclosure, that usually breaks their employment agreement. Have the conversation, document it, and exit calmly. No public shaming. Leaders talk, and the story of how you handled the exit travels further than the exit. The other option, a reset, is rarer than people want. If the person is high-output and you caught it early, the second job may have started because structure or purpose slipped on your side. Lay out unambiguous expectations, reconnect them to the mission, and make clear that transparency matters more to you than punishment. If they recommit, keep them. If not, separate.
Either way, name a directly responsible individual for the work in question. Diffuse ownership is half of what lets overemployment hide; with one name on an outcome, coasting has nowhere to go. Expect the performance conversation to get tricky once the person feels cornered, and stay on observable facts: what was owned and what was not.
The pattern rarely shows up in a single behavior. It shows up in ownership over time, which is what separates it from burnout and ordinary life:
| Observed behavior | Points to overemployment | Could just be burnout or life | What separates them |
|---|---|---|---|
| Recurring missed meetings | When paired with silence on deep work | Often | Burnout usually comes with an apology and context |
| Ships tasks, dodges architecture and roadmap calls | Strong signal | Rare | Deep disengagement from ownership is the tell |
| Commits only at odd hours, always solo | Frequent | Sometimes | Burnout work still tends to show real quality |
| Reuses the same async status updates | Frequent | Rare | Burned-out people explain the missing pieces |
| Slow to respond | Weak signal on its own | Very often | Only matters as a pattern beside the others |
Build a team where it cannot hide for long
Make the work legible by default, so contribution is visible to the whole team without anyone being watched. Be specific in hiring and onboarding about what success in the role looks like; overemployment feeds on cultures that never define anything. Use shared roadmaps, async progress snapshots, and standups where it is easy to see who is stuck. Visibility is a property of the work, not a camera on the person. And protect motivation, because people reach for a second job when they stop feeling connected to what they are building.
The best remote teams I have worked with hold real trust and real standards at the same time. They do not police hours and they do not pretend everyone is fine. On those teams, the person quietly running two jobs decides the risk is not worth it, and everyone else does their best work.
