When “Green” Means Nothing

It’s embarrassing, but here it is: I caught myself about to click a couple of random Teams messages—not to read or reply, just to make sure my status stayed green. This wasn’t one of those trivial background habits. I was actually aware of my own thinking: “I should click on a couple of Teams messages… just to make sure my status goes green.” There’s a particular shame in realizing you’re angling for a digital thumbs-up from the system instead of doing something useful. The moment had a weird, hollow feeling.

It made me look up from the screen and wonder: who am I performing for? Measuring engineering productivity starts by asking why busywork and that little green dot feel more urgent than the bug I’m supposed to be fixing. And, more troubling, am I the only one thinking this way, or is this some slowly spreading remote-work disease?

Embarrassing that I’ve thought this? Yeah. But why? Why does the quiet dread of “looking offline” feel worse than letting a tough bit of code sit, unsolved, for a while? There’s shame, but there’s also something systematic going on.

The best work doesn’t happen in chat windows. It happens in deep thinking, problem-solving, and learning, most of it invisible to everyone else. Shipping that tricky refactor, killing off meaningless alerts, writing the one comment that unlocks a teammate’s work. These are the accomplishments that actually matter, but the system trains us to work for a blinking status light. And if you’re honest, you know those results rarely show up as a flurry of activity or messages. They show up as code that runs better, incidents that don’t recur, maybe a teammate’s “OMG thank you” in a private channel.

That old tug toward presence—whether it’s green dots or office seats—runs deep, because proximity bias means people in power favor those physically close to them. WFH workers get judged by activity—“Are they online?”—just like people in the office get judged by how visible they are at their desk. The mode has changed, but the flawed logic is stubborn.

Let’s be clear: we should measure outcomes, not activity, because visible activity is a poor proxy for impact. You deserve better yardsticks for yourself, your team, your career. Let’s talk about what actually signals progress, and how to make it count.

Why Leaders Default to Activity—and What Gets Missed

There’s a reason leaders lean on what they can see. Hours logged, presence in meetings, that omnipresent “active” status indicator. The old norm was time-in-seat, and even now, with so much knowledge work hidden behind screens, there’s a lingering faith that busyness equals progress. The problem? A lot of truly consequential work—like redesigning a gnarly bit of backend logic or mapping a migration strategy—could take a quiet four hours and still leave zero outward signals. In the absence of tangible proof, staring at dashboards and status lights becomes the stand-in for real results. No one set out to make this the system, but it’s a habit loop that’s hard to break.

Look at the signals we actually track. Hours on the clock, ping-ponging between Microsoft Teams, Slack, and inboxes, now averaging 126 messages a day and checking every six minutes, plus attendance at every meeting possible. We get credit for answering threads and showing up, not for clearing the technical debt that’s been stalling delivery for months. Meanwhile, the work that moves a project forward—the kind you’re proud to talk about—doesn’t leave anywhere near as many traces in the chat log.

But here’s the tradeoff. When you start measuring productivity by how busy you look, deep work loses out. The temptation to chase visible signals is real, but every hour spent defending your availability is an hour taken from true progress. This is where the metrics start betraying us, prioritizing status updates over stubborn solutions.

Honestly, the whole premise of status policing feels absurd when you name it out loud. If your status is away, are you even working? There’s a quick panic when that little light flicks to yellow, and I feel it too—split between the urge to show presence and the craving for focus you can actually use. The anxiety builds from the constant sense that someone, somewhere, is judging your output by mouse movement more than meaningful advances. If you’re tired of that loop, you’re not alone. The urgency to find a measurement model that values what really matters isn’t just about fairness. It’s about survival for anyone who actually wants to build things that last.

How to Measure Engineering Productivity: A Two-Part Model—Outcomes and Enablement

What do outcomes look like in practice? This isn’t about just getting code across the line. It’s about clear, positive changes you can name. Shipping an endpoint redesign that cuts p99 latency by half. Swapping out a flaky integration so customers see fewer errors—measurable ones, not just a gut feel. Training a model until accuracy jumps enough that it unblocks new features. Cutting monthly incidents so nobody has to dread the on-call rotation. Even the smaller stuff counts.

Deleting dead scripts, pruning logs so alert fatigue drops, or making a dashboard customers actually use (and email to thank you for). If you finish a sprint and everything that matters is invisible, you’re missing out on the satisfaction and the leverage that come from naming these outcomes.

Engineering enablement metrics capture the second half, and they’re the real force multiplier. One great code review that unblocks a teammate (and teaches them a new pattern) saves hours down the line. High-quality docs mean the next person can find the answer instead of pinging you—or worse, guessing. Mentoring a junior dev so they’re shipping with confidence? That’s the fastest way to turn single wins into team momentum. You can’t automate enablement, but you can definitely spot when it’s absent. Bottlenecks, repeated mistakes, avoidable questions stacking up.

It helps to picture this like a pipeline, not a treadmill. Inputs (all the noise: pings, messages, even “but I was online!” hours) are just the raw material. What we care about is the output at the far end. Did we move quality and value forward? Optimizing for flow and throughput, not just motion.

It’s a bit like checking in at the gym just for the badge swipe. You can rack up visits all year and still not get stronger. Same with work. Activity signals mean nothing if you don’t ship value. The difference is whether you’re sweating for the mirror or pulling new personal bests.

I’d love to say I’ve completely ditched the reflex to “look active,” but the reality is messier. Even today, the urge pops up when I’m deep in something and notice my status inching toward “away.” I know what matters, but that tension never fully disappears.

Translating Impact Into Signals—and Dashboards That Work

If we want to make this shift real, the first step is tightening our focus to a handful of team-level outcome-based productivity metrics. Think about visible improvements: shipped features that tie directly to customer experience, not just “lines of code.” Consider reliability and latency SLOs, and track how they move—did p99 improve after that change? Model performance movements count when they unlock new use cases, not just a tenth of a point on a chart. Incident trends tell us if reliability is getting less painful, or if on-call still means dread. The point isn’t to drown everyone in numbers, but to spotlight what helps customers or teammates feel the difference.

Of course, you’re probably wondering if that’s fair to everyone. Roles are different, responsibilities aren’t always product-facing, and enablement work can get lost. Here’s how to counter that. Measure developer productivity by mapping outcomes and team multipliers to actual responsibilities—backend, ML, frontend, platform, QA, TPM. Then, emphasize peer-aware signals: is someone elevating quality for others, not just delivering on their own? You can’t standardize it perfectly, and that’s okay. Just be explicit about what counts for each role.

This all sounds like a lot, and yes, I know it costs time to reset dashboards. Nobody loves a big migration. Here’s what works: pilot these metrics with a willing team, agree on sunset criteria for each vanity metric you want to lose, and document the whole migration as you go. It’s tempting to overhaul everything in one big sweep, but phased rollout is how you avoid chaos and let real proof guide the next step.

Communicating Impact: Patterns That Actually Work

For leaders, you can embed better rituals that spotlight real value. Frame standups and 1:1s with outcome-first questions (“Which improvement got adopted?” “Who did you help level up?”). Regularly review enablement moves—docs, comments, mentoring moments. And get explicit. Strip status-policing prompts from your team norms. If you want to see the difference, framing cuts down back-and-forth, freeing time and pushing iteration forward instead of sideways.

Remember the moment I chased the green dot? Here’s the flip: stop chasing the symbol—make your work vivid by shipping results that are unmistakably visible.

Presence in the office used to be a proxy for commitment—“Are they in their seat?” Now, by centering remote team productivity outcomes as much as on-site results, we have the chance to shift the norm. Prioritize impact over visibility. In practice, that unlocks clearer priorities, more outstanding outcomes, and a tangible drop in burnout—wherever your chair happens to be this week.