The manager was convinced his remote team was slacking. "I don't know what they're doing all day," he complained. "When we were in the office, I could see them working. Now they could be doing anything."
I asked him how the team was performing. Were they shipping? Were they hitting deadlines? Were stakeholders satisfied with their output?
He paused. "Actually... yes. We've shipped more in the last six months than we did in the year before that. Customer satisfaction is up. We hit our last three milestones early."
"So what makes you think they're slacking?"
"I don't know. I just... I can't see them working."
This captures the core dysfunction in how many managers think about remote performance. Presence is confused with productivity. Being visible at a desk for eight hours is confused with producing valuable work. The manager's anxiety wasn't about actual performance—which was strong—but about the loss of the illusion of oversight that in-person work provides.
Managing performance in distributed teams requires abandoning the butts-in-seats mindset entirely. You have to define what good performance actually looks like, measure what matters, and build systems that surface problems before they become serious. This is actually better management than presence-based oversight—it focuses on real outcomes rather than theatrical productivity.
At SmithSpektrum, I've helped dozens of companies build performance management systems for distributed engineering teams[^1]. The ones that succeed treat remote work as an opportunity to develop better management practices. The ones that struggle try to recreate in-person oversight digitally—surveillance software, mandatory cameras, constant check-ins—and create cultures of distrust that drive their best people away.
Why Presence-Based Management Fails
Even in offices, presence-based management was a poor proxy for actual performance.
The engineer who arrived at 7 AM and left at 7 PM might have spent the day in unproductive meetings, context-switching between Slack channels, and looking busy while accomplishing little. The engineer who worked focused hours from 10 to 5 and went home might have produced twice the actual value. But in a presence-based culture, the first engineer looks like a hero and the second looks like they're not committed.
Remote work simply made this dysfunction visible. Without the theater of presence, managers who had been using presence as a proxy for performance suddenly had no proxy at all. Their management muscle had atrophied—they'd never actually developed the skill of assessing performance based on outcomes because they'd always had presence to fall back on.
The response for some was to try to recreate presence virtually. Always-on video calls. Surveillance software that tracks keystrokes and takes screenshots. Mandatory responses to messages within minutes. These approaches don't measure productivity—they measure presence in a new form—and they create toxicity that pushes away exactly the high performers you most want to keep.
The high performers who leave are the ones with options. They can find companies that treat them like adults, that focus on outcomes rather than surveillance. What's left are the people who either can't leave or don't mind being watched—neither of which selects for the kind of autonomous, driven engineers you want on your team.
Defining What Good Looks Like
The foundation of remote performance management is explicit definition of what good performance looks like.
For engineering teams, performance typically breaks down into several dimensions: delivery (shipping work that meets requirements on reasonable timelines), quality (work that's well-designed, well-tested, and doesn't create problems), collaboration (working effectively with others, communicating clearly, unblocking teammates), and growth (improving skills, taking on new challenges, developing expertise).
| Performance Dimension | Office Signal | Remote Alternative | Measurement Approach |
|---|---|---|---|
| Productivity | Visible activity | Output delivered | Ship velocity, PR metrics |
| Collaboration | Hallway conversations | Async engagement | Comment quality, availability |
| Growth | Overheard learning | Self-directed | 1:1 discussions, skill tracking |
| Leadership | Meeting presence | Written communication | Influence on decisions |
| Culture fit | Social observation | Intentional assessment | Peer feedback, values alignment |
Each dimension needs to be made concrete for your context. What does "good delivery" look like for a senior engineer on your team? Shipping one major feature per quarter? Closing twenty tickets per sprint? The specific expectation depends on your work, and making it explicit is essential—both so you can evaluate fairly and so engineers know what they're being evaluated against.
Level matters. A senior engineer should deliver more, with higher quality, and contribute more to others' success than a mid-level engineer. Your expectations should scale with level, and those scaled expectations should be documented and shared.
The exercise of making expectations explicit often reveals that managers have never actually thought carefully about what good looks like. They've relied on gut feel and presence as a proxy. Forcing explicit definition improves management quality regardless of whether the team is remote.
Measuring What Matters
Once you've defined good performance, you need ways to measure it.
Delivery can often be measured directly. What shipped? What's the scope and quality of what was completed? How does actual delivery compare to commitments? These aren't perfect measures—shipping a lot of low-value work isn't better than shipping less high-value work—but they're directionally useful.
Quality can be measured through multiple signals: production incidents attributable to code someone wrote, bugs found in code review or testing, technical debt created versus resolved, architecture decisions that enabled or hindered future work. No single metric captures quality, but the combination of multiple signals paints a picture.
Collaboration is harder to measure but not impossible. Peer feedback captures how well someone works with others. Pull request review quality and responsiveness is observable. Documentation produced, questions answered, and mentorship provided are all visible if you look for them.
Growth shows up in expanded scope over time, new challenges taken on, and skills developed. It's the dimension most dependent on manager observation and judgment.
The goal isn't perfect measurement—that doesn't exist. The goal is having enough signal to identify strong performers, surface problems early, and make fair decisions. Some subjectivity remains, and that's fine as long as the subjective elements are acknowledged and calibrated.
Regular Check-In Structure
Remote performance management requires more deliberate communication than in-person management.
One-on-ones become more important, not less. In an office, managers pick up information through casual observation—they see when someone seems frustrated, notice when someone's missing meetings, observe interactions. Remotely, this ambient information disappears. The one-on-one has to carry more weight in understanding how someone is actually doing.
Weekly one-on-ones for direct reports is the right frequency for most situations. Thirty to sixty minutes focused on how things are going, what's blocking progress, how the person is feeling, and what support they need. This isn't status reporting—you can get status asynchronously—it's relationship maintenance and problem surfacing.
The content of one-on-ones should include project status (briefly), blockers and needs, feedback in both directions, career development, and personal wellbeing. The balance varies week to week, but all components should get attention over time.
Skip-level meetings—meetings between managers and their direct reports' direct reports—help managers understand team health without filtering through intermediate management. These should be less frequent (monthly or quarterly) but consistent.
Team meetings serve different purposes than one-on-ones. They're for coordination, shared context, and connection. They shouldn't be status meetings where everyone reports what they did—that's waste. They should be discussions of blockers, decisions that need making, and information that benefits from real-time exchange.
Feedback Frequency and Quality
Remote work often degrades feedback frequency if not deliberately maintained.
In offices, feedback happens in small doses constantly. A quick comment after a meeting. A note while reviewing code together. A reaction to something someone said. This ambient feedback helps people calibrate and course-correct before small issues become big ones.
Remotely, feedback requires more deliberate effort. The casual opportunities don't exist. If you don't create structured moments for feedback, feedback doesn't happen—and then small problems accumulate into big ones.
Real-time feedback on work product should happen through async channels. Code review comments, document feedback, Slack reactions to good ideas—these can all deliver feedback without requiring synchronous conversation.
Broader feedback about performance trajectory, working style, and development areas requires synchronous conversation. The one-on-one is the natural venue. Managers should be delivering substantive feedback in most one-on-ones, not just asking "how's it going" and accepting "fine."
Peer feedback should be collected systematically. Quarterly peer feedback processes where colleagues share what someone does well and could improve surface information that managers don't have. This is particularly important remotely where managers observe less directly.
Feedback should be specific and actionable. "Your code quality needs to improve" is useless. "The last three PRs had significant bugs caught in review—let's talk about what's happening and how to improve" is actionable. The specificity comes from actually observing work, which is possible remotely if you're paying attention.
Identifying Problems Early
Remote work can hide problems longer than in-person work if you're not watching for warning signs.
Delivery slowdown is the most obvious signal. If someone who used to ship consistently starts missing expectations, something is wrong. It might be external circumstances, burnout, unclear requirements, or actual performance issues—but the slowdown is a signal to investigate.
Communication pattern changes can indicate problems. Someone who was responsive goes quiet. Someone who was engaged in team discussions withdraws. Someone who was proactive starts just doing assigned tasks. These shifts are harder to notice remotely but are real warning signs.
Quality degradation shows up in code review, in production incidents, in feedback from stakeholders. If work that used to be high quality starts having issues, something has changed.
Peer signals matter. If other team members mention concerns about someone's collaboration, responsiveness, or work quality, take it seriously. Peers often see things managers don't.
The key is not ignoring signals because "people are just adjusting to remote work" or similar excuses. Early investigation of warning signs lets you address problems while they're small—providing support if someone's struggling, addressing performance if that's the issue, making changes before the situation deteriorates.
Handling Underperformance Remotely
When you do identify performance problems, addressing them remotely requires deliberate communication.
Start with curiosity, not accusation. There may be context you don't have—personal circumstances, unclear expectations, missing skills that weren't identified. The first conversation should surface what's happening, not deliver a verdict.
Be explicit about the gap. Vague feedback like "I need you to step up" doesn't help. Specific feedback like "You've missed the last three sprint commitments, and the code you shipped had significant bugs that caused production incidents" is actionable.
Collaborate on a plan. If the problem is skill gaps, what learning is needed? If it's personal circumstances, what accommodations might help? If it's motivation, what would re-engage them? The plan should have concrete actions and a timeline for improvement.
Document everything. Remote performance management creates less natural documentation than in-person conversations. Make sure expectations, feedback, and plans are written down. This protects everyone—the employee has clarity on expectations, the manager has records if things don't improve, and the company has documentation if decisions become contentious.
Follow through on the timeline. If you said you'd check progress in two weeks, check progress in two weeks. If you said continued underperformance would have consequences, deliver consequences if performance doesn't improve. Inconsistent follow-through teaches people that stated expectations don't matter.
Building Trust at a Distance
Trust is the foundation of remote performance management. Without trust, every interaction becomes adversarial.
Trust is built through consistency. Doing what you say you'll do. Following through on commitments. Being predictable in how you respond to situations. Over time, consistent behavior creates trust that enables more autonomous work.
Trust is built through transparency. Explaining the reasoning behind decisions. Sharing context that helps people understand priorities. Being honest about challenges the team faces. Secrecy breeds suspicion; transparency breeds trust.
Trust is built through competence. Demonstrating that you know what you're doing. Making decisions that work out. Providing useful guidance. People trust leaders who seem to know what they're talking about.
Trust is damaged by surveillance. Installing monitoring software, requiring constant presence verification, treating people like they're probably slacking—these all communicate distrust. And distrust begets distrust. If you treat people like they can't be trusted, they'll behave accordingly.
The goal is to create an environment where trust is the default. Assume people are working in good faith. Verify through outcomes, not surveillance. Address problems when they surface rather than preemptively treating everyone like a problem.
The manager who was convinced his remote team was slacking despite excellent results? He had to confront the uncomfortable truth that his anxiety was about control, not performance.
His team was actually performing better remotely—fewer interruptions, less time in unnecessary meetings, more focused work. The outcomes showed it. His discomfort was about losing the feeling of oversight, not about actual problems.
He learned to focus on the work itself. Regular one-on-ones that went beyond "what did you work on" to "how are you feeling about the project" and "what do you need from me." Clear expectations set at the beginning of each quarter. Trust that people were working unless outcomes suggested otherwise.
A year later, his team's performance was even better. And his own anxiety had largely resolved—not because he'd found a way to watch his team work, but because he'd stopped needing to.
References
[^1]: SmithSpektrum remote work advisory, performance management systems, 2020-2026. [^2]: GitLab Handbook, "Performance Management." [^3]: Harvard Business Review, "What It Takes to Run a Great Virtual Meeting," 2020. [^4]: Gallup, "Remote Work Performance Management," 2024.
Building remote performance systems? Contact SmithSpektrum for distributed team strategy and management training.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum