February 14, 2026

WFH is bad (sometimes)

Why distributed teams fail without a strong engineering core

This is based solely on personal experience. I should start by saying that Remote is great.

I’m not beefing with WFH itself. I’m a big fan of it. Everyone hates traffic and commutes, and it’s much better to have a personal corner in the house and see family more often than going to “happy hours” for corporate pizza and beer.

The Core Problem

However, companies that choose to build exclusively distributed teams often miss one crucial reality: you need to spend more energy and resources on hiring the right people (TL;DR: spend more money) than an in-office company.

I truly believe that an engineering core will either set the company on a path to success or a road to nowhere.

You can definitely write an MVP, raise some money, and get somewhere with a weaker team. But it will not move you over the finish line (Acquisition or IPO). If you are totally fine with that, great. But the reality is, unfortunately, that in the world of tech, settling is usually not okay.

The Tale of Two Startups

Example A: The Strong Core I worked in a startup with very strong engineers. These were people who actually cared about the craft. They had a high bar for what appeared in the codebase, worked unhealthy hours (not something I advocate), but the result spoke for itself: the startup was acquired in less than 2 years.

It had powerful help from investor connections, but those connections wouldn’t have helped if the product sucked. The reason this experience was successful is that by hiring very strong engineers, you are paying top dollar for talent. That difference is all that matters.

Example B: The “Cost-Saving” Distributed Team Now, let’s compare this to a company that decides engineering is the “expensive part.” They hire a few folks at the manager level in the US and offshore the rest to save money.

To be clear: the problem is not with offshoring itself. I’ve worked with offshore teams that are absolutely cracked—people who can do stuff that would be hard to find locally. The problem is hiring people who “can write code” but lack ownership.

Why Remote Magnifies Weakness

If you are not paying top dollar, you are not hiring the top of the top. If you do that while also going fully remote, it’s impossible to build strong company bonds.

• The Sync Trap: You end up creating dozens of meetings just to sync up, killing the focus flow of engineers.
• The Quality Drop: Even if you find people who work hard (often out of fear of losing their job), they aren’t elevating the codebase. They write bugs and close tickets just to satisfy a manager’s ego, rather than thinking long-term.

The “Osmosis” Problem

Here is the thing people forget: Juniors don’t become Seniors by reading Jira tickets.

In an office, growth happens by osmosis. You hear the Principal Engineer arguing about database schemas three desks away. You turn your chair around to ask a quick question and get unblocked in 30 seconds.

In a remote setup with average talent? That 30-second question becomes a 4-hour Slack thread or a “let’s sync tomorrow” invite. That friction accumulates. It kills momentum. And suddenly, your velocity creates a graph that looks like a flatline.

The AI Trap

And no, AI is not the magic fix.

Sure, AI can write a lot of code very quickly. But can it ask the right questions? Can it challenge a bad requirement? Can it predict how this feature will break the database six months from now?

Not yet.

Right now, AI is a force multiplier. If you give it to a strong engineer, they become faster. If you give it to a weak team without direction, you just get bad code, faster. It doesn’t solve the communication gap; it just floods the codebase with unverified logic.

The Verdict

To hire amazing engineers, you need to pay money (duh). But here is the uncomfortable truth: It is infinitely harder to manage a mediocre team remotely than in person.

In an office, proximity acts as a crutch. You can bridge gaps with whiteboards, quick chats, and energy. In a distributed world, you don’t have that crutch. You only have the code they push and the communication they write.

If you go remote to save money, you aren’t building a startup; you’re building a ticket-closing factory. And factories don’t innovate—they just churn.

Takeaway: Go remote if you want the best talent in the world and are willing to pay for it. Don’t go remote just because you want to pay less for “good enough.”