Building Team Culture When You've Never Met IRL

alex_infrastructure · February 22, 2026, 4:35am

I joined my current AI startup 18 months ago. Fully remote, 12-person engineering team spread across 7 countries. We ship fast, execute well, have strong technical foundations.

And I’ve never met any of them in person.

Not once. No offsite. No team gathering. Never shaken hands, never grabbed coffee, never seen each other outside a Zoom rectangle.

For the first year, this felt fine. We were productive. Code shipped. Infrastructure scaled. All the metrics looked good.

But something was missing. We had strong execution, zero team cohesion. We didn’t really know each other. Slack conversations were purely transactional. No one shared what they were working through. No one asked for help until they were completely blocked.

Here’s what made me notice: I switched jobs and realized I had no one to say goodbye to. No relationships. Just professional acquaintances who happened to share a GitHub org.

The Traditional Remote Advice

All the remote work playbooks say the same things:

Virtual coffee chats (scheduled 30min “get to know you” calls)
Team building games (remote trivia, online escape rooms)
Async watercooler Slack channels (#random, #pets, #music)

I tried all of it. The engineers hated it.

Virtual coffee chats felt forced. We’d run out of things to say after 10 minutes. “So… how’s the weather?” is awkward enough in person. On Zoom it’s excruciating.

Team building games were even worse. Low attendance, people multitasking, nobody engaged. Asking engineers to play Pictionary after a full day of work doesn’t build culture, it builds resentment.

The watercooler channels went silent. Occasionally someone would post a meme, get 3 emoji reactions, then nothing for weeks.

What Actually Worked

I was ready to give up on team culture when something shifted. We built culture accidentally, through how we worked, not through forced social time.

Here are the 5 practices that actually created connection:

1. “Learning in Public” Slack Channel

Started as a place for TILs (Today I Learned), evolved into something deeper. Engineers share:

Experiments that failed
Bugs they spent hours debugging
New tools they’re exploring
Questions they’re too embarrassed to ask elsewhere

The vulnerability created trust. When our senior ML engineer posted “spent 4 hours debugging why my model was predicting garbage, turns out I had the labels backwards,” it gave permission for everyone else to share their struggles.

Sharing the messy process, not just polished results, built psychological safety.

2. Pair Programming Rotation (Actual Building Together)

Not just code reviews. Not just pairing on a bug. Actually building features together.

Every two weeks, random pairing assignments. Two engineers, one feature, build it together via screen share over 2-3 days.

This forces:

Learning each other’s work style
Navigating disagreements in real-time
Building something collaboratively vs handing off work

Side effect: Knowledge spread organically. No more “only Sarah understands the auth system.”

3. “Ask Me Anything” Personal Docs

Everyone maintains a doc: “Ask me about X.” Lists what they’re expert in, what they’re learning, what they’re happy to help with.

Examples:

“Ask me about Kubernetes internals, Brazilian food, mechanical keyboards”
“Ask me about LLM fine-tuning, horror movies, sourdough baking”

Mixed professional + personal. Gave people entry points for conversations beyond work tasks.

4. Demo Days with “Behind the Scenes”

Bi-weekly demos, but not polished product demos. Raw walkthroughs of work-in-progress.

“Here’s the feature I’m building. Here’s where I’m stuck. Here’s the ugly hack I did to get it working. Here’s what I’m refactoring next.”

Showing the messy middle, not just the finished product. People asked questions, shared similar problems, offered solutions.

Built respect across the team. You see someone wrestle with a hard problem and you appreciate their craft.

5. Async Book Club (Team-Chosen Topics)

Not company-mandated reading. The team votes on technical books/papers they actually want to discuss.

Last 6 months:

“Designing Data-Intensive Applications” (Martin Kleppmann)
“A Philosophy of Software Design” (John Ousterhout)
“Staff Engineer” (Will Larson)

Weekly async discussion in Notion. People drop thoughts, questions, disagreements. No live meeting, no pressure.

Creates shared context. Inside jokes emerge. We now reference “Kleppmann’s rant about two-phase commit” and everyone knows what that means.

The Shift

Culture emerged from doing work together, not from avoiding work to “do culture.”

Remote team culture isn’t office culture via Zoom. It’s a different thing entirely. It’s built through:

Shared struggle (pair programming, debugging together)
Shared learning (book club, learning in public)
Shared context (demos, AMA docs)

We still don’t have perfect cohesion. Some people are still quiet. Some pairs don’t gel. But it’s better than the transactional emptiness we had before.

My Questions

What’s worked for your remote teams? What’s failed spectacularly?

Specifically curious:

How do you build trust without face-to-face time?
What async rituals have created real connection?
Has anyone actually made virtual social events work? (genuinely asking, maybe I’m doing it wrong)
For folks who’ve done in-person offsites - does it actually help long-term, or is it a temporary boost?

Remote culture is hard. I’m still figuring it out.

maya_builds · February 22, 2026, 4:36am

Alex, this resonates so deeply. Your “Learning in Public” channel especially.

We started something similar on our design team and it TRANSFORMED how we work together.

Here’s what happened:

I encouraged designers to share work-in-progress in Slack, not just polished final designs. At first, crickets. People were scared to show messy work.

Then one of our senior designers posted: “I’ve been iterating on this navigation pattern for 3 days and I hate all of them. Help.”

She shared 6 Figma explorations. All rough. Some barely sketched. She wrote honest commentary:

“This one is too complicated”
“This one is boring”
“This one I like but it breaks our design system”

Within an hour, three other designers jumped in with ideas. An engineer pointed out a technical constraint she didn’t know about. Our PM shared user research that reframed the problem.

By end of day, she had a solution. Not because it was her best solo work, but because the team collaborated in real-time (async real-time, via threaded Slack).

The cultural shift was huge.

Before: Designers worked in isolation, presented polished work, got critique too late to incorporate.

After: Designers show messy progress, get input early, build on each other’s ideas.

Side effects:

Engineers appreciated design more. They saw the iteration, the trade-offs, the dozens of options designers considered. Design wasn’t “magic” anymore, it was craft.
Designers saw technical constraints earlier. Instead of designing something beautiful but impossible, they’d check with engineers mid-process.
Psychological safety skyrocketed. If Sarah can post “I’m stuck and this is ugly,” then I can too.

Counter-intuitive insight: Vulnerability built trust faster than polish.

When people see your struggle, they respect your expertise more, not less. Because they understand the difficulty of what you’re solving.

We also started “Failure Fridays” (totally optional):

End of week, share something that DIDN’T work this week
Could be technical (code that got reverted), strategic (feature idea customers hated), or personal (gave bad feedback, miscommunicated)

No judgment, just learning. The goal is: what did you learn from the failure?

Our VP of Product posts in there regularly. When leadership models vulnerability, everyone else follows.

On your virtual social events question:

Yeah, we also tried forced fun and it flopped. Here’s what I learned:

Virtual social events work when they’re:

Optional (no pressure, no judgment if you skip)
Activity-based (not just “hang out on Zoom”)
Small groups (4-6 people max, not whole team)

Examples that worked:

Design co-working sessions (everyone working on own stuff, just screen sharing and chatting)
Friday “show and tell” (share something non-work: hobby project, recipe you made, book you’re reading) - 15 min max
Game nights for people who actually want to play games (self-selected attendance)

The key: opt-in, not mandatory. Culture for people who want it, not imposed on everyone.

Alex, your list of 5 practices is gold. I’m stealing the “Ask Me Anything” docs idea for our team.

vp_eng_keisha · February 22, 2026, 4:36am

Alex, this is fantastic. And Maya’s response about vulnerability building trust faster than polish - 100% true.

I want to talk about scaling this, because what works at 12 people is different at 80+.

Your practices work brilliantly for small teams. At 12 engineers, everyone can participate in the book club. Everyone can see the “Learning in Public” posts. The pair programming rotation ensures everyone works with everyone eventually.

At my EdTech startup (80+ engineers now), that organic approach started breaking down around 30 people. Here’s what happened and how we adapted:

The Scaling Challenge

At 30+ people:

“Learning in Public” channel became too noisy (50+ posts per week, people stopped reading)
Pair programming rotation couldn’t cover everyone (combinatorial explosion)
Book club discussions had too many voices (signal-to-noise problem)

We needed structure.

Three-Tier Culture Model:

Squad Level (5-8 people): Organic connection
This is where your practices shine. Each squad has:

Their own “working in public” channel
Pair programming within the squad (manageable rotation)
Squad-specific rituals that fit their team

Let squads figure out their own culture. Some do coffee chats, some do co-working, some do gaming. Autonomy matters.

Team Level (20-30 people): Structured rituals
Across 3-4 squads, we needed intentional connection points:

Monthly “Engineering Showcase” - two engineers do deep dive on their work (30min presentation + Q&A)
Quarterly retros on team processes
Shared Slack channels for topics (e.g., #learning-frontend, #learning-data-science)

Company Level (80+ people): Intentional programs
Can’t rely on organic culture. Need dedicated investment:

All-hands with regular “engineer spotlight” segments
Company-sponsored hobby channels (#rock-climbing, #cooking, #music-production)
Bi-annual in-person offsite (yes, this matters)
Documentation culture (can’t know everyone, must be able to find information)

The Budget Question

Small companies ask: “How do we build culture with no budget?”

At scale, you need to actually spend money:

Dedicated budget for culture activities ($500/person/year in our case)
Someone’s job (or part of their job) to organize rituals
In-person offsites (expensive but necessary at scale)

On In-Person Offsites:

You asked if they help long-term or just temporary boost. My experience: Both, and it’s worth it.

We do biannual week-long offsites. Expensive as hell ($200k+ for 80 people with travel/hotel/activities).

What happens:

First 2 days: Workshops, planning, structured work
Middle 2 days: Mix of work sessions and social time
Last day: Team bonding activities, reflections

The magic is the unstructured time. Dinners, coffee breaks, late-night conversations. That’s where relationships form.

Does it last?

Temporary boost: Yes, everyone is energized for 2-3 weeks after
Long-term impact: Also yes, but different

After an offsite:

People have faces to match to names (huge for empathy)
Inside jokes emerge (creates shared context)
Relationships deepen (easier to ask for help via Slack from someone you’ve met)
New engineer onboarding improves (they meet people at offsite, feel part of team faster)

The effect fades, which is why you need them regularly (we do every 6 months).

One Key Lesson: Culture is About Intimacy at the Right Scale

You can’t be intimate with 80 people. But you can:

Be intimate with your 6-person squad (daily interaction)
Be familiar with your 25-person team (monthly interaction)
Be aware of the 80-person company (quarterly interaction)

Different layers need different approaches.

Alex, your question - “How do you build trust without face-to-face time?” - I think the answer is: You can, but it takes longer and requires more intentional structure.

At 12 people, organic works. At 50+, you need systems.

eng_director_luis · February 22, 2026, 4:37am

Great insights, Alex and Keisha. I want to add the cross-cultural dimension that often gets overlooked in remote culture discussions.

My team is spread across US, Mexico, and Brazil. Even though we’re all in the Americas (relatively similar timezones), the cultural differences in how people build relationships are significant.

Culture Building is Cultural

What I learned the hard way:

US engineers (broad generalization, I know):

Comfortable with direct feedback
“Let’s grab coffee” can happen with strangers
Professional relationships can be casual quickly
Separation of work and personal life is normal

Mexican engineers on my team:

Relationship-first culture
Need to know someone personally before deep professional trust
Family and work are more integrated
Formality in initial interactions, warm once trust is established

Brazilian engineers:

Very relational, similar to Mexico
Social time is important for team bonding
More comfortable mixing personal and professional
Expect more frequent check-ins from managers

Where This Broke My Culture Building

I tried the “Learning in Public” channel (great idea, btw). Worked well for my US engineers. They immediately started sharing struggles.

My Mexican and Brazilian engineers: Radio silence.

Why? In their cultures, showing weakness publicly (even in a “safe space” Slack channel) felt risky. Trust needed to be built first, preferably one-on-one.

What Actually Worked: Cultural Liaisons

I designated someone from each region as a “cultural liaison” (informal role, rotates every quarter). Their job:

Advise me on what resonates culturally
Translate cultural norms for the rest of the team
Help adapt our rituals to be culturally inclusive

Example: Our Mexican engineer suggested we do “Learning in Public” as small group discussions first (3-4 people) before sharing to the whole team. Built trust in smaller circles, then expanded.

Our Brazilian engineer suggested we start team meetings with 5 minutes of personal check-in (“How was your weekend? How’s your family?”). In US culture this feels like wasting time. In Brazilian culture, it’s essential relationship building.

The Results

Our team rituals now vary by region:

Brazil team: Loves video social time (Friday virtual happy hours actually work for them)
Mexico team: Prefers in-person gatherings (we do quarterly Mexico City meetups)
US team: Likes async flexibility (co-working sessions, opt-in events)

But work practices stay consistent:

Code reviews: async, same standards globally
Documentation: English, same format
Standups: async written updates
Decision-making: Same RFC process

Key Principle: Culture is local, process is global.

Let teams build culture in ways that fit their context. Keep work processes standardized.

On Alex’s Virtual Social Events Question

I think the reason they often fail is they assume one approach works for everyone.

Virtual trivia might work great for extroverted US engineers. Terrible for introverted Brazilian engineers who prefer smaller group conversations.

We now offer variety:

Large group optional events (monthly, fun but not mandatory)
Small group co-working (weekly, opt-in)
One-on-one virtual coffee (encouraged, manager facilitates pairing)
Regional meetups (quarterly, in-person when possible)

People choose what fits their style and culture.

Final Thought

Remote culture isn’t just about remote vs in-person. It’s about recognizing that “culture” itself is cultural. What builds trust in San Francisco might not work in São Paulo.

The mistake is assuming Silicon Valley remote work culture is universal. It’s not.

product_david · February 22, 2026, 4:37am

Coming at this from a product perspective, and I’m going to share what worked for cross-functional culture building (Product + Engineering + Design).

Alex, your practices are brilliant for engineering teams. The challenge I’ve seen is that engineers bond with engineers, designers bond with designers, and product managers end up as the lonely middle layer that nobody wants to hang out with.

The Cross-Functional Culture Problem

Engineers have shared context (code, architecture, technical challenges). They can geek out about Kubernetes or debate tabs vs spaces.

Product managers… talk about roadmaps? Customer problems? It’s harder to find organic connection points.

Here’s what worked: “Trio Planning” Sessions

Borrowed from pair programming, but for cross-functional work:

PM + Designer + Engineer in a (virtual) room
Not a handoff meeting (“here’s the spec, go build it”)
Collaborative problem-solving session

Example: Building a new payment flow.

Traditional approach:

PM writes specs → Designer creates mocks → Engineer builds → Everyone discovers problems late

Trio planning:

PM presents customer problem (not solution)
All three explore solutions together
Designer sketches, engineer identifies constraints, PM checks business viability
Converge on approach together

Why This Built Culture

Mutual respect: Engineer sees PM wrestle with trade-offs, PM sees engineer’s creative problem-solving, designer sees both
Shared ownership: It’s not “your feature” vs “my feature,” it’s “our feature”
Fewer rewrites: Catching issues early because all perspectives are present
Natural relationships: Working through hard problems together builds bonds

We do this once per feature kickoff (90 minutes), then async collaboration from there.

Side Benefits

Product-engineering trust improved dramatically. Engineers stopped seeing PMs as “order-takers from customers” and started seeing us as strategic partners.

PMs got better at technical thinking. When you’re in the room while engineers debate implementation, you learn.

Designers got earlier input on feasibility. No more “this beautiful design is impossible to build.”

The Async Version

For teams across timezones, we do “async trio planning”:

PM posts problem statement + context in Notion (includes customer research, business constraints)
Designer adds exploration sketches + questions (24 hours to respond)
Engineer adds technical approach + constraints (24 hours to respond)
All three comment back and forth for 48 hours
Final sync meeting to converge (60 min)

Not as good as live collaboration, but way better than sequential handoffs.

On Your Book Club Idea

We tried this cross-functionally and it actually worked. Recent books:

“Inspired” by Marty Cagan (product-focused, engineers appreciated seeing PM perspective)
“The Design of Everyday Things” by Don Norman (design-focused, whole team benefited)
“Accelerate” by Forsgren/Humble/Kim (engineering-focused, PMs learned about DORA metrics)

Rotating focus meant everyone learned each other’s disciplines.

Bottom Line

For cross-functional teams, culture comes from doing hard work together, not avoiding work to socialize.

The best team bonding happened when we shipped something difficult as a trio and celebrated the win together.

Remote culture isn’t about virtual escape rooms. It’s about structuring work so people build relationships through collaboration.