Remote, Hybrid, or In-Person: What Actually Works for a 10-Person Engineering Team in 2026

The Question Everyone Gets Wrong

"Should we be remote, hybrid, or in-person?"

That's the wrong question. It assumes the answer is one of those three, and that the answer applies to everyone on the team.

The right question is: "What does our team actually need to do their best work?"

For some teams, it's remote. For some, it's in-person. For most growing teams, it's actually a hybrid that's different than what most companies do.

The RTO (return-to-office) wars of 2023-2024 happened because both sides were right, just arguing about different things. Remote-first companies were right that you can build amazing software with distributed teams. Office-first companies were right that some kinds of collaboration are faster in person.

The mistake was assuming one answer for everyone.

By 2026, we have enough data to be specific. And I've run teams across all three models. Let me tell you what actually matters for a 10-15 person engineering team.

The Real Trade-offs (Not the Propaganda)

Remote-first (everyone distributed)

Pros:

• You can hire from anywhere. This is huge. You get better engineers because you're not limited to one city.
• Async-friendly teams are actually faster at scale. If you build a culture of written decisions and async updates, you ship more.
• People are less interrupted. They can do deep work without someone tapping their shoulder.
• Lower cost if you care about that.

Cons:

• Onboarding is slower. New hires take longer to ramp because they're not absorbing context from being around people.
• Architectural alignment takes longer. In-person, you can whiteboard for 30 minutes and all be aligned. Remote, it takes three async discussions.
• Some kinds of creativity are harder. Brainstorming over Zoom is just worse than whiteboarding together.
• If you have time zone spread, coordination gets harder.

In-person (everyone at an office)

Pros:

• Onboarding is fast. New hires can learn from people around them.
• Synchronous decision-making is quick. You align faster on architecture and big decisions.
• Some people are more productive and happier in-person. That's real.
• Easier to build team cohesion and culture.

Cons:

• You can only hire people who can move to your office. You're limiting your talent pool.
• You have rent, utilities, parking, all the overhead costs.
• Some people are less productive in an office. Open floors are distracting.
• If someone's best work happens with two hours of deep focus, an office makes that harder.

Hybrid (some days in office, some days remote)

Pros:

• You get the office benefits without losing remote hires. You can hire great people from out of state, ask them to come in once a week.
• You can coordinate synchronously when you need to, async the rest of the time.
• People can work how they want some of the time.

Cons:

• You have all the costs of an office but without the full benefits (people aren't there enough to create real culture).
• It can be the worst of both worlds if not designed intentionally.
• It's easy to create an in-group (people in office) and out-group (remote people).

What Actually Matters at 10-15 People

Here's the honest truth: at your size, it doesn't matter as much as you think.

You're small enough that you can do synchronous standups and have real meetings. You're big enough that some async processes help. You're probably shipping weekly, so coordination isn't a bottleneck yet.

What actually moves the needle:

1. Can you afford office space?

If you can't or don't want to, be fully remote. Don't try to hybrid with three people in the office and two working from home. That creates weird dynamics.

If you can afford it and people want it, an office can help with onboarding and culture. But it's a culture investment, not a velocity investment, at your size.

2. What kind of work are you actually doing?

If you're rebuilding a monolith or doing a big architectural migration, you probably want people co-located or in very tight async patterns. If you're shipping features to an existing system, remote works fine.

If you're onboarding three new people at once, in-person helps. If you're in hire-and-ramp mode constantly, remote is harder.

3. What do your people actually want?

This sounds obvious, but most founders decide the policy and then wonder why people are unhappy. Ask your team. For real. Not "would you prefer remote?" but "what would help you do your best work?"

Some of your engineers will say remote. Some will say "I need to be in an office." Some will say "I want flexibility." Respect those differences.

4. Are you going to be consistent about it?

The worst thing you can do is make a policy and then ignore it. If you say "hybrid means Tuesday and Thursday in office," and then some people are in-office every day, you've created resentment.

Consistency matters more than the policy itself.

Real Example: The Three-Model Test

I worked with a founder who was genuinely torn. She had a 12-person engineering team. Two people wanted to work in-person. Two had moved out of state and wanted to stay remote. The rest were flexible.

Instead of deciding for everyone, she ran three "modes":

• One month fully remote
• One month with an office hub (people could go in if they wanted, required Tuesday lunch as the sync day)
• One month focused on a big launch (everyone available for sync, most people chose to be in office)

After three months, the pattern was clear: the team was most productive when they had flexibility. When forced to be fully remote, they missed the synchronous collaboration for big decisions. When forced to be in office, some people were frustrated (especially the ones who'd moved away). When given flexibility with one sync day a week, they were energized.

She ended up with: office available (subsidized), Tuesday in-office for the team, remote-friendly otherwise. Not everyone came in every week. The two out-of-state people came in quarterly. It worked.

The Counterpoint: This Is Actually a Distraction

Some founders spend way too much time on this question. Here's the honest version: if your engineering team is miserable because of working location, that's probably masking another problem.

Remote workers are unhappy because they're isolated, not because they're remote. In-office workers are unhappy because they're interrupted, not because they're in an office.

The real problems are: Are they working on things that matter? Do they feel like they have a future here? Do they trust leadership? Can they ship without being blocked?

I've seen fully remote teams that are incredible and fully remote teams that are toxic. Same with in-person teams. The location isn't the variable. The team culture and the work itself are the variables.

If you're using the location question as a proxy for culture, you're solving the wrong problem.

Where I Come In

If your team is distributed and you're struggling with asynchronicity and alignment, I'll help you build the patterns that work. If you're hybrid and you're seeing a divide forming between in-office and remote people, I'll help you fix it.

And if you're actually asking "should we be remote or in-person" because you're trying to solve a deeper problem, I'll help you find the real problem.

Let's talk about what your team actually needs.

Your Action Checklist

• Ask your team: What would help you do your best work? Get honest answers. Not "what's convenient," but what actually matters.
• Audit your current collaboration patterns. When do you need to be synchronous? When can you be async? Schedule around that.
• If you're thinking about going hybrid, commit to a one-month test. Make it explicit: "We're trying Tuesdays and Thursdays in office. We'll re-evaluate in a month."
• If you have remote people, make sure your default is async. Record meetings. Use written decisions. Don't assume remote people will show up for every sync.
• If you have in-office people, respect their deep work time. Don't interrupt them constantly just because they're there.
• Quarterly, ask yourself: Is this still working? Are people shipping? Are they happy? Can we attract good hires?

The Real CTA

Your work location should support how your team works, not the other way around. If you're forcing a model that doesn't match your team's needs, you're leaving velocity on the table.

Related Reading

• Async-First Engineering: How to Build Velocity in a Distributed Team
• Leading a Dev Team: The Weekly Operating Rhythm
• Why Your Senior Engineers Keep Leaving (And What Actually Stops Them)