Remote Work Standards

Remote Work Doesn't Create Problems. It Reveals Them.

When teams moved remote in 2020, a lot of engineering leaders made the same mistake: they assumed the sudden drop in output was a remote work problem. It wasn't. It was a standards problem that the office had been quietly masking for years. The open floor plan, the shoulder taps, the ambient pressure of being seen — these weren't culture. They were scaffolding holding up a structure that had no real foundation.

The office creates a performance illusion. Someone who arrives at 9, looks busy, attends every meeting, and leaves at 6 reads as a high performer to most managers — even if their actual output is thin. Remote work strips that illusion completely. What's left is the work itself, and for a lot of teams, that's a confronting thing to look at directly.

The engineers who thrived remotely from day one had something in common: they already knew what good looked like for their role, they could self-direct without ambient cues, and they produced artifacts — PRs, docs, decisions — that spoke for themselves. The engineers who struggled had been operating on social proof for years. Remote work didn't break them. It just stopped covering for them.

This is why the remote work debate is often the wrong conversation. The real question is never 'should we be in the office?' The real question is: 'Do we have explicit standards for what good engineering work looks like, and can we measure it without relying on physical presence?' Most teams, when pressed, cannot answer yes to both.

Visibility: The Underperformance You Were Already Living With

Underperformance in co-located teams is expensive in a very specific way — it's expensive and invisible. You pay the salary, absorb the coordination cost, and carry the drag on team velocity, but because the person is physically present and socially integrated, the signal never crosses the threshold that triggers a real conversation. Remote work changes the signal-to-noise ratio dramatically. Suddenly the person who was 'always around' is just... not producing anything you can point to.

The pattern that emerges in remote engineering teams almost always looks the same. There's a cluster of engineers who over-communicate — who leave detailed async updates, write thorough PR descriptions, flag blockers early, and push context to their teammates without being asked. And then there's another cluster who go quiet. Not maliciously. They're often not even aware of it. They're just operating the way they always have, waiting for someone to pull work from them rather than pushing it forward.

The over-communicators in this scenario aren't just more productive. They're revealing a structural truth: remote work rewards engineers who treat their work as a shared surface, not a private one. The engineers who struggle remotely often have a fundamentally different mental model — they see their work as something they do and then hand off, rather than something they build in public, incrementally, with legible progress.

What's critical here is that this isn't purely a motivation or work ethic problem. Some of the highest-integrity engineers I've worked with were terrible at remote visibility — not because they weren't working hard, but because they had spent their entire careers in environments that never required them to make their work legible. They had the output. They just had no habit of broadcasting it. The fix there is a standards and systems problem, not a performance management problem.

The dangerous failure mode for engineering leaders is confusing quiet with underperformance and noise with productivity. Both errors are costly. The engineer who sends daily status updates but ships nothing is a different problem than the engineer who ships consistently but never tells anyone. Remote work forces you to build a measurement system precise enough to distinguish between the two — and most teams don't have that system.

Metrics: What Accountability Actually Requires

Accountability without metrics is just vibes with consequences. Most engineering teams that struggle with remote accountability aren't lacking the will to hold people accountable — they're lacking the measurement infrastructure that makes accountability fair and defensible. When you can't point to a specific, agreed-upon standard that was missed, 'accountability' devolves into managers punishing engineers for making them feel uncertain, which is a completely different thing.

The metrics that matter in remote engineering teams fall into two categories: output metrics and process metrics. Output metrics are the obvious ones — features shipped, bugs resolved, PRs merged, incidents owned. Process metrics are subtler but often more diagnostic — how often does this engineer's work require rework? How frequently do their PRs sit in review for days because the description is incomplete? How often do they surface blockers before they become blockers versus after? Process metrics tell you whether someone is operating with craft or just closing tickets.

Cycle time is one of the most underused diagnostic tools in remote engineering management. When you track the time from 'work started' to 'work in production' at the individual level, patterns emerge fast. Some engineers have consistently short cycle times because they scope well and ship incrementally. Others have long cycle times not because the work is harder, but because they take on large, ambiguous chunks and disappear into them for weeks. That second pattern is almost never about capability — it's about a missing feedback loop that the office used to provide artificially.

The mistake most teams make is treating metrics as a surveillance system rather than a calibration system. The goal of measuring engineering output isn't to catch people slacking — it's to create a shared language for what 'good' looks like so that everyone on the team can self-assess, course-correct, and grow without needing a manager to tell them they're off track. The best remote teams I've seen use metrics the way good athletes use film review: not as punishment, but as a mirror.

Accountability also requires that the standards be set before performance is measured, not after. This sounds obvious, but it's violated constantly. Engineering leaders who set vague expectations — 'I need you to be more proactive,' 'I need you to own your work' — and then hold people accountable to their own interpretation of those expectations are creating a system that is guaranteed to produce conflict and attrition. The standard has to be explicit, written down, and agreed upon before anyone is evaluated against it.

The Systems That Remote Teams Actually Need

The teams that operate well remotely have almost always done the unglamorous work of building explicit operating systems — documented norms for how work gets communicated, how decisions get made, how progress gets shared, and how blockers get escalated. These aren't bureaucratic overhead. They're the replacement for the informal, ambient coordination that the office provides for free. When you remove the office, you don't eliminate the need for that coordination — you just make it the team's explicit responsibility to recreate it.

A working async communication standard, for example, isn't just 'write things down.' It's a specific protocol: what gets written in Slack versus Linear versus Notion, what level of detail is expected in a PR description, how long is a reasonable window before a review request gets a response, what constitutes a blocker that warrants interrupting someone's focus time. Teams that have this written down and enforced move dramatically faster than teams that treat it as common sense. Common sense is not common.

Decision-making infrastructure matters just as much. In co-located teams, decisions often get made in hallway conversations that are then retroactively documented — or not documented at all. Remote teams that inherit this habit create a specific kind of dysfunction: engineers who feel constantly out of the loop, who can't trace why a technical decision was made, who second-guess their own work because the context behind their constraints is invisible to them. The fix is forcing decisions into written artifacts before they're executed, not after.

The teams that struggle most with remote work are often the ones that had the strongest in-person culture — because they had the most implicit systems to replace. High-trust, high-collaboration co-located teams often run on social capital that doesn't transfer to async. The norms that felt natural in person feel cold and bureaucratic when written down. That friction is real, but it's the price of operating at scale across time zones and locations. The teams that push through it come out with something better: a culture that runs on clarity instead of proximity.

Why Standards Fail: The Human Variable

Here's the part most engineering leadership content skips: even with perfect metrics and explicit standards, remote teams still fail in predictable ways — because the humans running them have fundamentally different relationships with accountability, transparency, and autonomy. Two engineers can be given identical standards and measurement systems and respond to them completely differently. One will internalize the standard and use it to self-direct. The other will feel surveilled, resent the overhead, and quietly disengage. The difference isn't the system. It's the person.

Some engineers are intrinsically motivated by transparency — they naturally want their work to be visible, they find satisfaction in the legibility of a well-documented PR, they proactively share progress because it aligns with their identity as a collaborative professional. Others are intrinsically motivated by the work itself, and the meta-work of making that work visible feels like friction they're being asked to absorb for someone else's benefit. Neither orientation is wrong. But managing both with the same system is a mistake.

The engineers who struggle most with remote accountability frameworks are often the ones with the highest conscientiousness — they care deeply about doing good work, but they have a private relationship with that work. They don't need external accountability structures because they hold themselves to high standards internally. Forcing them into a visibility-heavy system can actually degrade their performance by shifting their focus from the work to the reporting of the work. Understanding this distinction requires knowing something about the person, not just the process.

This is where most remote work frameworks fall apart. They're designed for the median engineer, which means they're optimized for no one. The engineers who need more structure get a system that's too loose. The engineers who need more autonomy get a system that's too rigid. And the managers trying to hold it all together end up in endless one-on-ones trying to diagnose problems that a better upfront model of the person could have predicted before they started.

Know What Good Looks Like — Before the Friction Starts

This is where LU Teams and HEXACO-based personality science become practically relevant — not as a soft-skills add-on, but as a hard engineering management tool. HEXACO measures six core personality dimensions, and several of them are directly predictive of how an engineer will perform in a remote, standards-heavy environment before you've watched them struggle through a quarter of missed expectations. Honesty-Humility predicts whether someone will self-report blockers accurately or manage up optimistically. Conscientiousness predicts whether they'll maintain output quality without external structure. Openness predicts how they'll respond to new accountability frameworks being introduced mid-flight.

The value of having this data before you build your remote team's operating system is that you can design the system for the actual humans on your team, not the hypothetical median engineer. If your team skews high on Conscientiousness and low on Extraversion, you probably need fewer synchronous check-ins and more asynchronous artifact standards. If your team has high variance on Honesty-Humility, you need more structural transparency mechanisms — shared dashboards, public PRs, written decision logs — because you can't rely on self-reporting to surface problems early.

LU Teams surfaces this data at the team level, which is where it becomes actionable for CTOs and VPs of Engineering. Individual personality profiles are interesting. Team-level friction patterns are predictive. When you can see that two of your senior engineers have fundamentally incompatible working styles on the dimensions most relevant to remote collaboration — before they've spent six months building resentment in async threads — you can intervene with structure instead of retrospective damage control.

The goal isn't to sort engineers into buckets or use personality data to make hiring decisions. The goal is to stop being surprised by friction that was always predictable. Remote work makes performance visible, but it also makes team dynamics visible in ways that are hard to unsee. The engineering leaders who build durable remote cultures are the ones who look at that visibility as information rather than inconvenience — and who build systems precise enough to act on what they see.