Building Team Cultures in Remote and Hybrid Teams — Open Source CXO Ep. 6 | Active Logic
In the first of two episodes with Ben Kittrell, CTO at Quext, the conversation tackles a challenge that defines modern technology leadership: building and sustaining team culture when your team isn’t in the same room. Ben leads a distributed engineering organization that was formed through the acquisition of Homebase.ai by Quext, which means he’s not just managing remote work logistics — he’s building a unified culture from two distinct teams that were brought together by a corporate transaction, not by shared history.
This combination of distributed work and post-acquisition integration creates a uniquely difficult culture-building challenge. Ben speaks openly about what has worked, what hasn’t, and what he’s still figuring out. The conversation is grounded in operational reality rather than remote work ideology — there’s no cheerleading for distributed teams or nostalgia for office culture, just honest assessment of trade-offs and practical strategies.
The episode covers team structure decisions, fostering genuine connection in remote environments, communication dynamics across distributed teams, and the work-life balance considerations that distributed work creates for both leaders and individual contributors.
Key Insight: Team Structure After Acquisition in a Distributed Environment
Structuring an engineering team is always consequential, but doing it after an acquisition while operating in a distributed environment multiplies the complexity. Ben describes the specific structural decisions he made at Quext and the reasoning behind them.
The starting point was two separate engineering teams with different reporting structures, different tool preferences, different development processes, and different cultural norms. The Homebase.ai team had its own way of working, and the Quext team had its own. Simply declaring “we’re all one team now” without addressing the structural reality would have created confusion and resentment.
Ben’s approach was to reorganize around product domains rather than legacy company affiliations. Instead of maintaining a “Homebase team” and a “Quext team” that happened to work together, he created cross-functional squads organized around specific product areas. Each squad included engineers from both legacy organizations, which forced integration through daily collaboration rather than top-down mandate. For teams building web applications and complex platform products, this domain-based structure has the additional benefit of creating clear ownership and reducing cross-team dependencies.
The structural reorganization wasn’t painless. Some engineers preferred their old team dynamics and resisted being broken up from colleagues they’d worked with for years. Ben addressed this by being transparent about the rationale — domain-based teams produce better outcomes for distributed organizations because they minimize coordination overhead — while acknowledging the legitimate loss that reorganization creates. Structure follows strategy, but people’s feelings about structural change are valid and ignoring them undermines the strategic intent.
Key Insight: Fostering Genuine Connection in Remote Teams
The biggest risk in distributed teams isn’t productivity — most studies show remote engineers are at least as productive as co-located ones. The real risk is connection. Without the casual interactions that happen naturally in shared physical spaces, remote teams can devolve into collections of individuals who execute tasks competently but don’t function as a cohesive unit.
Ben distinguishes between performative connection and genuine connection. Performative connection is the awkward virtual happy hour that nobody wants to attend, the forced icebreaker that starts every meeting, and the Slack channel for fun that dies within a week. These activities feel hollow because they transplant in-person social dynamics into a medium that doesn’t support them.
Genuine connection in remote teams comes from shared work, shared challenges, and the trust that develops when people reliably support each other through difficult problems. Ben focuses his team-building energy on creating these conditions: pairing engineers across legacy organizations on complex problems, establishing peer code review practices that create regular constructive interaction, and ensuring that team retrospectives include space for honest conversation about how the team is functioning, not just what it’s delivering.
He also invests in periodic in-person gatherings — not as a replacement for remote work, but as a complement to it. These gatherings are designed around collaborative work and relationship-building, not presentations and meetings. The goal is to build enough relational foundation during in-person time that remote collaboration during the rest of the year has the trust needed to handle conflict, ambiguity, and the inevitable miscommunications that text-based interaction creates.
Key Insight: Communication Dynamics in Distributed Engineering Teams
Communication in distributed teams requires deliberate design in a way that co-located teams can often avoid. Ben describes the communication architecture he’s established at Quext and the principles behind it.
The foundational principle: default to asynchronous, escalate to synchronous. Most engineering communication doesn’t require real-time interaction. Code reviews, design discussions, status updates, and technical questions can all be handled asynchronously through tools like Slack, GitHub, and shared documents. This approach respects the time zone differences in distributed teams and protects the deep focus time that engineers need for complex software development work.
But some communication requires synchronous interaction: complex architectural decisions where written communication is too slow to explore the problem space, conflict resolution where tone and nuance matter, and crisis response where coordination speed is critical. Ben’s team has clear norms about when to escalate from asynchronous to synchronous: if an asynchronous thread has gone back and forth three times without resolution, it’s time for a video call.
The challenge specific to post-acquisition teams: communication norms from the legacy organizations may conflict. One team may have been Slack-heavy while the other preferred email. One may have had daily standups while the other checked in weekly. Ben handled this by establishing new shared norms rather than adopting either legacy organization’s practices wholesale. Creating something new together — rather than one team imposing its practices on the other — reinforced the message that the combined team was building its own culture, not just absorbing the acquired team into the existing one.
Key Insight: Work-Life Balance in Distributed Organizations
Remote work collapses the boundary between professional and personal life in ways that affect team culture, burnout rates, and long-term retention. Ben discusses this challenge honestly, including his own experience as a leader managing work-life boundaries.
The most common failure mode: remote work doesn’t eliminate the commute so much as eliminate the off switch. When your office is your home, there’s no physical transition that signals the end of the workday. Slack notifications arrive at dinner. A quick code review happens at 10 PM. Weekend deployments creep in because “it’s just a few hours.” Over time, these blurred boundaries accumulate into burnout that’s harder to detect in remote teams because nobody sees the physical signs of exhaustion.
Ben’s approach addresses this at both the cultural and structural levels. Culturally, he models healthy boundaries himself — he doesn’t send messages during off-hours unless genuinely urgent, and he’s explicit with his team that response time expectations are calibrated to business hours. Structurally, he’s established on-call rotations that clearly define who is responsible during off-hours, which means everyone else can genuinely disconnect.
For leaders managing teams that operate cloud infrastructure or production systems requiring continuous availability, the temptation to maintain constant vigilance is strong. Ben argues that sustainable operations require structured coverage, not heroic individual effort. An engineer who is always “sort of on call” is never fully rested and never fully present in their personal life — the worst of both worlds.
Key Insight: Managing Team Dynamics Across Distance
Interpersonal dynamics in remote teams are harder to read and harder to manage than in co-located settings. Ben describes the specific challenges and the management practices that address them.
In an office, you can see when two team members are frustrated with each other. Body language, tone of voice, and the patterns of who talks to whom provide constant data about team health. In distributed teams, this data is largely invisible. Conflicts can escalate without the manager being aware, and team members who are struggling can disappear into silence without anyone noticing.
Ben compensates with structured one-on-one conversations that go beyond task status. He asks explicitly about team dynamics: who are you collaborating well with? Where is communication difficult? What friction are you experiencing? These questions feel intrusive in office culture where managers can observe dynamics directly, but they’re essential in remote environments where observation is impossible.
He also pays attention to the signals that are visible in remote work: response time patterns in Slack, the tone of code review comments, who is volunteering for collaborative work and who is retreating into solo tasks. These signals are imperfect proxies for direct observation, but they’re the best available tools for a distributed manager. For teams building mobile apps or any complex product across distributed teams, the manager’s ability to read and respond to these signals directly affects delivery quality.
Takeaways
- Reorganize around product domains, not legacy affiliations. Cross-functional squads force integration through daily collaboration more effectively than top-down mandates.
- Focus on genuine connection through shared work, not performative activities. Forced virtual happy hours don’t build trust — solving hard problems together does.
- Default to asynchronous communication, escalate to synchronous deliberately. Protect deep focus time while maintaining clear norms for when real-time interaction is needed.
- Model healthy work-life boundaries as a leader. Remote work eliminates the commute but not the need for an off switch — make boundaries structural, not aspirational.
- Compensate for invisible team dynamics with structured conversations. You can’t observe body language remotely, so ask explicitly about team friction and collaboration quality.
