A common pattern when a manager feels uncertain about a team's productivity is reaching for more granular measurement — more detailed reports, more frequent check-ins, tighter monitoring. This instinct is understandable and often counterproductive: granular measurement is good at surfacing activity, and comparatively poor at surfacing the things that actually distinguish good work from busy work, which tends to make the underlying uncertainty worse rather than better, dressed up in more confident-looking data.
Measuring outcomes where they exist, before reaching for activity proxies
Most roles have some genuine outcome signal, even if it's less immediate or less granular than an activity log — completed projects, resolved tickets, closed deals, shipped features. Where a real outcome signal exists, it's almost always a better productivity measure than an activity proxy, because it measures the thing that actually matters rather than a correlate of it. Activity data is most useful specifically where outcome signals are weak, delayed, or hard to attribute to an individual — as a supporting diagnostic, not a replacement for outcome measurement where outcomes are actually visible. For broader context, BLS productivity data offers additional guidance.
The uncertainty that prompts a manager to reach for more measurement in the first place is worth interrogating directly before choosing a response. Sometimes the honest answer is that the outcome signal exists but hasn't been looked at carefully — in which case the fix is reviewing the existing outcome data more deliberately, not collecting a new category of activity data. Other times the honest answer is that the role genuinely lacks a clear outcome signal at all, in which case activity data may be one of the only available proxies, but it's worth naming that limitation explicitly rather than treating the resulting activity-based picture as equivalent in reliability to a genuine outcome measure.
A specific example: the manager who feels uncertain without being able to say why
One of the more common, harder-to-address versions of this pattern is a manager who reports a vague sense of unease about a team's productivity without being able to point to a specific missing outcome or a specific concerning pattern. This vague unease is worth taking seriously as a signal, but it's a signal about the manager's own visibility, not necessarily about the team's actual output — and the appropriate response is often improving the manager's access to whatever outcome signal already exists, or having a direct conversation with the team about workload and priorities, rather than defaulting to more granular activity monitoring as a way of resolving a discomfort that may have nothing to do with actual underperformance. A related practical example is available this link.
- Identify the genuine outcome signal for a given role before reaching for activity-level proxies — most roles have one, even if it's slower or coarser-grained than activity data.
- Use activity data as a diagnostic layered under an outcome metric (why is this project behind, where is time actually going) rather than as a stand-alone measure of how hard someone is working.
- Review productivity signals at the pattern level (weekly, monthly, aggregate) rather than continuously — connecting to the monitoring-vs-micromanagement guide in this site's Employee Monitoring Software section.
- Ask whether a specific measurement change would survive being explained honestly to the team it applies to — a useful, if informal, test for whether a measurement approach has drifted toward surveillance for its own sake.
- When uncertainty about productivity has no specific, nameable cause, consider whether the issue is actually the manager's visibility into existing outcome data, rather than a genuine gap in what's being measured.
- A direct conversation with the team about workload and priorities often resolves a vague sense of unease faster, and more accurately, than an additional layer of quantitative measurement.
This is the more general version of a point made specifically about engineering and IT teams elsewhere on this site: the roles where activity-based measurement is weakest tend to be exactly the roles where the temptation to reach for it is strongest, precisely because their output is otherwise harder to see at a glance.