Remote Teams Doubled to 58% of Tech—But We Can't Lead With 'Presence' Anymore. What Actually Replaces It?

[system]

I spent eight years at Google learning to lead by walking the floor. I knew who was blocked by the coffee they grabbed at 3pm. I built trust through hallway conversations. I could see when someone was struggling.

Then I became VP of Engineering at a fully remote EdTech startup. And literally every leadership instinct I had built became useless overnight.

Here’s the thing that’s not being said loudly enough: Remote work isn’t the problem. Our outdated leadership models are.

The Numbers Don’t Lie

58% of tech roles are now fully remote—that’s doubled in just three years. Meanwhile, 74% of HR professionals report that return-to-office mandates are causing leadership conflicts.

We’re fighting the wrong battle. The question isn’t “how do we get people back to the office?” It’s “how do we lead without visibility?”

Because here’s the uncomfortable truth: You can’t lead with presence anymore. And that’s terrifying for leaders who built their careers on it.

What Doesn’t Work

Let me be blunt about what I tried that failed spectacularly:

• “Management by wandering around” - Doesn’t work when everyone’s in their homes
• Visual cues of productivity - Can’t see who’s “working hard” on Slack
• Impromptu check-ins - Feels like surveillance, not support
• My calendar full of 1:1s - Killed my strategic time and didn’t scale

I was essentially trying to force an office-based leadership model into remote work. It was exhausting, ineffective, and honestly? My team could tell I didn’t trust the process.

What Actually Replaces Visibility

After two years of trial, error, and some very honest feedback from my team, here’s what works:

1. Lead with Trust and Outcomes, Not Activity

I stopped asking “what are you working on today?” and started asking “what outcome are we trying to achieve this sprint?”

We measure deployment frequency, incident response time, feature delivery cadence, and user impact. We don’t measure hours logged or Slack response time.

When metrics are clear and visible, you don’t need to manage through constant check-ins. Trust increases because progress is measurable.

2. Create Clarity at Scale

The highest-value skill I’ve developed as a remote leader is making the invisible visible:

• Priorities are public - Everyone knows the top 3 company goals
• Decisions are traceable - We document the “why” behind every strategic choice
• Status is readable without meetings - Weekly async updates in Loom + written doc
• Ownership is undeniable - Clear DRIs on every project

This isn’t micromanagement. It’s macro-transparency.

3. Go Async-First, Sync-Strategic

My team has a meeting budget: 3-5 hours per week, maximum. That constraint forces us to ask: “Is this worth everyone’s synchronous time?”

Async is the default:

• Product specs shared in Notion, feedback via comments
• Architecture decisions in RFCs with async voting
• Demos recorded and shared, not presented live

Sync is reserved for:

• High-stakes problem-solving
• Sensitive performance conversations
• Quarterly strategy alignment

This isn’t about eliminating human connection. It’s about being intentional with it.

4. Documentation as Infrastructure

One stat haunts me: Fortune 500 companies lose $12 billion annually due to poor documentation.

Remote teams can’t rely on tribal knowledge. So we treat docs like code:

• Review process for critical docs
• Versioning and change logs
• Ownership and update cadence
• Searchability as a priority

If it’s not documented, it doesn’t exist. That mindset shift has saved us countless hours.

The Real Question We’re Not Asking

Here’s what keeps me up at night: If 30% of organizations are planning to pull back remote work in 2026, is it because remote doesn’t work… or because their leaders haven’t evolved?

I suspect it’s the latter. And that’s a solvable problem.

I want to hear from this community:

• What metrics do you use to prove that trust-based leadership is working?
• How do you train managers to lead remotely, not just “allow” remote work?
• What’s one thing you lost in remote work that you genuinely can’t replace?

Because if we’re serious about remote work being a permanent shift (and the data says 67% of tech workers think it is), we need to have honest conversations about what leadership looks like when “presence” isn’t an option.

Let’s talk about what actually works—and what doesn’t.

[cto_michelle]

This hits hard, Keisha. The shift from activity metrics to outcome metrics is the single biggest mind-shift I’ve had to make as CTO—and the hardest one to get our exec team comfortable with.

The Invisible Work Problem

At my previous company (when we were still hybrid), executives loved seeing engineers at desks. It felt productive. It felt safe.

When we went fully remote during our Series B scaling phase, that safety net disappeared. And suddenly, every leadership gap we’d been papering over with “presence” became glaringly obvious.

What We Changed

We completely rebuilt our engineering effectiveness metrics around outcomes:

• Deployment frequency - How fast can we ship value to customers?
• Incident response time - How quickly do we detect and resolve issues?
• Feature delivery cadence - Are we hitting our quarterly commitments?
• Cycle time - From commit to production, how long does it take?

The shock? Our Q1 2026 team hit goals two weeks early with zero office time. The metrics didn’t lie. The exec team had to confront the fact that “seeing people work” was never actually correlated with results.

The Real Blocker: Middle Management

Here’s what I’m struggling with now: We’ve convinced the C-suite. But middle managers are still floundering.

They haven’t been trained to lead remotely. They’ve been allowed to manage remote workers. Those are very different things.

The managers who are succeeding? They’ve shifted from:

• “Let me see what you’re doing” → “Let me see what you’ve accomplished”
• “Hop on a quick call” → “Can you document your question so others benefit?”
• “I need to be in all the meetings” → “I trust you to make decisions and tell me what I need to know”

The ones struggling? They’re scheduling more 1:1s, demanding camera-on for everything, and essentially trying to recreate office surveillance remotely. And their teams are burning out.

The Question I’m Wrestling With

How do you train managers to lead remotely at scale?

We’ve tried:

• Remote leadership workshops (check-the-box exercise, minimal behavior change)
• Manager coaching cohorts (better, but time-intensive and doesn’t scale)
• Async leadership guidebooks (great reference material, but no one reads them)

What’s actually working for us now: Manager shadowing.

New managers spend 2 weeks observing how our best remote leaders run their teams. They see the async updates, the decision documentation, the strategic use of sync time. They watch the behaviors, not just hear the theory.

It’s slow. It doesn’t scale perfectly. But it’s the only thing that’s actually changing leadership patterns.

My question back to you: At your EdTech company, how are you identifying which managers can’t make the transition? Because I suspect not everyone will. And that’s a hard conversation to have.

[eng_director_luis]

Keisha, I’m leading 40+ engineers across 3 time zones in financial services, and “visibility” is literally impossible. If I tried to “see” everyone working, I’d need to be online 18 hours a day. That’s not leadership—that’s insomnia.

What Actually Works at Scale

Here’s what we’ve implemented that keeps us sane and productive:

1. Weekly Async Updates (Standardized Format)

Every Friday, each engineer posts a 5-minute Loom video + written summary:

• What shipped this week (with links to PRs/deployments)
• What’s blocked (with specific asks, not vague complaints)
• What’s next week’s focus (one sentence)

I can watch at 1.5x speed during my Monday morning coffee. The team gets practice articulating impact. And critically: Other engineers see each other’s work, which builds team awareness without meetings.

2. Public Decision Logs

We have a Notion page called “Why We Decided.” Every architectural choice, every process change, every vendor selection gets documented with:

• The decision
• Who made it (and who had input)
• Why we chose this path
• What alternatives we considered
• When we’ll revisit

New hires read it during onboarding. It answers “why are we doing it this way?” before they ask. And when we revisit decisions 6 months later, we remember our reasoning instead of repeating debates.

3. Team Handbook (Living Document)

This isn’t HR boilerplate. This is our handbook:

• How we review code (and what “LGTM” really means)
• When to use Slack vs email vs async video
• How we handle on-call rotations across time zones
• What “done” means for different types of work

It evolves. Engineers propose changes via PR (literally). We treat it like code because it is our operating system.

4. The Meeting Budget: 3-5 Hours Max

I’ll push back on one thing, though: Some sync time is critical for culture, not just “high-value work.”

We have:

• Weekly team standup (30 min, async-friendly) - People can watch recording if they miss
• Biweekly architecture reviews (60 min) - Live debate is valuable here
• Monthly team social (60 min, optional) - Games, trivia, just human connection

Total: ~3.5 hours/week of required sync time. Everything else is optional or async.

The Hard Part: Onboarding Remote Engineers

Michelle mentioned middle managers struggling. My struggle is onboarding at scale.

In an office, new hires absorb so much through osmosis:

• Overhearing how senior engineers debug problems
• Watching code reviews happen in real-time
• Learning who to ask about which systems

Remote? That ambient learning is gone.

What we’re trying now:

• Onboarding buddy recordings - Senior engineer records their daily workflow for a week (debugging, reviewing code, planning work). New hires watch before starting.
• Public Slack threads - We banned DMs for technical questions. Everything in public channels so juniors can learn from seniors.
• Shadowing sprints - First 2 weeks, new hire’s only job is to shadow 3-4 engineers and document what they learn.

It’s better than nothing. But I’m not gonna lie: Ramp-up time is longer. We used to get engineers productive in 2 weeks. Now it’s 4-6 weeks. That’s a real cost.

The Template I’m Sharing

I built a “Remote Leadership Scorecard” that I use in my 1:1s with managers:

Trust Indicators:

• Are engineers making decisions without asking permission?
• Are they escalating blockers early (not hiding struggles)?
• Do they challenge my ideas in public forums?

Async Effectiveness:

• Are updates clear enough that I don’t need to ask follow-ups?
• Are decisions documented before meetings, not during?
• Is status visible without me asking for it?

Documentation Quality:

• Can a new hire understand our systems from docs alone?
• Do engineers update docs when they change code?
• Are runbooks tested by people who didn’t write them?

If scores are dropping, it’s a leading indicator that trust is eroding or process is breaking.

My question: How do you handle the trade-off between async efficiency and the real human need for spontaneous connection? Because I think we’re over-rotating toward efficiency and might be losing something important.

[product_david]

Coming from the product side, I want to add a cross-functional perspective here because remote work affects eng-product collaboration differently than you might think.

The Lost Hallway Conversations

When we were hybrid, I could walk to an engineer’s desk and say “hey, quick question about this edge case…” Five minutes later, we’d have clarity. Feature shipped on time.

Remote? That “quick question” becomes:

• A Slack DM (feels intrusive)
• A meeting request (overkill)
• Or… nothing. And the feature ships with the wrong behavior.

We lost the ambient collaboration that made product-engineering work feel seamless.

What We Replaced It With

After a lot of trial and error, here’s what works:

1. Async RFC Process for Product Decisions

Before we build anything significant, PM writes an RFC (Request for Comments) with:

• The problem we’re solving
• User research / data supporting it
• Proposed solution (with mocks/wireframes)
• Open questions

Engineering comments async. We set a 3-day feedback window. Then we have one 30-min sync call to resolve any remaining debates.

Benefit: Written specs force me to think harder. I can’t hand-wave details in a doc the way I could in a hallway conversation.

2. Recorded Demos Instead of Live Presentations

We used to do weekly demo meetings where engineers showed their work. 90 minutes of sitting through features that didn’t impact my product area.

Now: Engineers record 3-5 minute Loom demos. I watch at 2x speed for features I care about. I leave comments with questions or feedback.

It’s more efficient. And honestly? Engineers give better demos when they can edit out mistakes.

3. Public Slack Channels (No DMs)

Luis mentioned banning DMs for technical questions. We did the same for product questions.

Everything in #product-eng-sync channel. Benefits:

• Designers see eng constraints early
• Other PMs learn from my questions
• Questions get answered even when I’m offline (timezone coverage)

The Uncomfortable Truth

But here’s where I’ll push back on the “remote is better” narrative: Some things are harder remotely.

Brainstorming is slower. We used to whiteboard together, riff on ideas, build on each other’s thoughts in real-time. Async brainstorming in Miro boards? It works, but it’s not the same energy.

Creative exploration feels more labored. We’re more efficient at execution but less spontaneous at innovation.

And I think that’s okay to admit. We don’t have to pretend remote solves everything.

The Two-Tier Culture Problem

Here’s the real tension I’m seeing: Sales and marketing still want office time for “energy” and “collaboration.” Meanwhile engineering and product are fully remote.

So we’re creating a two-tier culture:

• Office-preferred roles feel like “real” employees
• Remote-first roles feel like second-class citizens

Leadership says “everyone can choose where to work.” But in practice, the VP of Sales who’s in office 5 days a week gets more face-time with the CEO. That shapes promotions, strategic influence, and perceived impact.

My question: How do you maintain equity when some functions are naturally more remote-friendly than others? Because I don’t think “everyone remote” or “everyone in office” are viable options. We’re stuck in hybrid limbo.

And I haven’t seen anyone solve that well yet.

[maya_builds]

Design perspective incoming, and I’m going to be honest in a way that might be uncomfortable: Design collaboration seemed impossible remotely at first. And if I’m being real, some things still are.

What We Lost (And I Miss It)

When I was leading design systems in-office, I could:

• Pull up a chair next to an engineer and iterate on a component in real-time
• Sketch ideas on a whiteboard during a 5-minute hallway conversation
• Give immediate feedback on a UI by looking over someone’s shoulder

Remote killed all of that. And for a while, I thought remote work meant the end of good design collaboration.

What Actually Works Now

But here’s what I’ve learned works (and some of it is better than in-person):

1. Figma Async Comments + Video Walk-throughs

Instead of sitting with engineers, I now:

• Drop Figma comments with context
• Record 2-minute Loom videos explaining design decisions
• Create component specs that answer questions before they’re asked

Surprise benefit: The async feedback is often higher quality. Engineers have time to think, not just react. They catch edge cases I missed because they’re not feeling rushed in a live conversation.

2. Office Hours Instead of All-Hands Meetings

I used to be in so many meetings because “design needs to be involved.”

Now: I have 2-hour blocks twice a week where anyone can drop in for live design discussion. Everything else is async.

Result: Better use of my time and engineers get faster answers when they actually need them.

3. Stronger Design Systems (Out of Necessity)

When designers were always available to ask “what color should this be?” or “how much padding here?”, our design system stayed half-baked.

Remote forced us to document everything:

• Component usage guidelines
• Accessibility requirements
• Design tokens for every spacing/color decision

It was painful to build. But now engineers can ship UI without constantly asking designers. And honestly? The consistency is better.

The Honest Part: What’s Actually Harder

But David’s right—we can’t pretend everything is better remotely. Some things are genuinely harder:

Creative brainstorming feels slower. We’ve tried Miro boards, FigJam sessions, async idea generation… It works. But it’s not the same energy as five people riffing around a whiteboard.

Rapid iteration is more labored. In person, I could iterate on a design with an engineer 10 times in an hour. Remote? Maybe 3 iterations in a day because of async handoffs.

Junior designers struggle more. They used to learn by osmosis—watching how I give feedback, hearing how I explain decisions. Now I have to be way more intentional about mentoring.

I don’t think those things are unsolvable. But we need to stop acting like they’re not real trade-offs.

The Real Issue Isn’t Remote vs Office

Here’s what I keep coming back to: The issue isn’t remote work. It’s whether leadership trusts teams.

David mentioned the two-tier culture problem. I see it too. And here’s what I’ve noticed:

The functions that are “struggling” with remote work are the ones where leadership doesn’t actually trust their teams to work independently. So they want butts in seats as a proxy for control.

Engineering and design can go remote because leadership trusts that:

• Code gets committed and reviewed
• Designs get shipped and critiqued
• Work is visible and measurable

Sales struggles with remote because leadership isn’t sure how to measure “relationship building” or “pipeline generation” without seeing it happen.

That’s not a remote work problem. That’s a metrics and trust problem.

The Question No One’s Asking

If 30% of orgs are pulling back remote work in 2026, I genuinely think it’s because leaders haven’t evolved their leadership models.

But here’s my pushback to this whole thread: Are we in a bubble thinking remote works for everyone?

We’re in tech. We have:

• High salaries that can afford home offices
• Jobs that are digitally native
• Skills that are in high demand (so we can be picky about remote options)

What about:

• Hourly workers who don’t have dedicated workspace at home?
• Roles that genuinely require physical presence (hardware, labs, customer-facing)?
• People who want office time for social connection because their home life is isolating?

I think the future isn’t “everyone remote” or “everyone in office.” It’s flexibility with intentionality.

And that’s way harder to implement than a blanket policy.

My question: Are we optimizing for our preferences (knowledge workers who love remote) and ignoring that some people and roles genuinely benefit from office time? Because I don’t think the answer is one-size-fits-all.