Overcoming Cultural Barriers and Keeping Connected as a Tech Leader — Open Source CXO Ep. 10 | Active Logic
In the second of two episodes with Jim Poteet, Senior Director of Revenue Cycle Development, Analytics & Middle Solutions at Oracle Health, the conversation turns to the challenges that emerge when technology leadership extends across countries, cultures, and organizational boundaries. Jim speaks from direct experience: his role involves managing development teams distributed across multiple international locations, and he navigated the massive organizational change of Oracle’s acquisition of Cerner from inside the organization.
These aren’t abstract leadership challenges. They’re daily operational realities that affect code quality, team morale, and product delivery. Jim brings a candid perspective on what works, what doesn’t, and what well-intentioned leaders often get wrong when managing across cultural and organizational boundaries.
Key Insight: International Development Team Management
Managing engineering teams across countries is fundamentally different from managing co-located teams, and the differences go far beyond time zones. Jim describes the operational reality of coordinating development work across international offices with different working norms, communication styles, and professional expectations.
The most common failure mode: treating international teams as interchangeable with domestic teams. Leaders assign work the same way, communicate the same way, and expect the same patterns of interaction — then are frustrated when results don’t match expectations. The problem isn’t the international team’s capability; it’s the leader’s failure to adapt their management approach.
Jim discusses specific adaptations that make international teams effective: adjusting meeting cadences to respect time zone constraints, being explicit about expectations that domestic teams might infer from context, and investing heavily in relationship-building that creates the trust needed for honest communication across cultural divides. For organizations considering software development with distributed international teams, these investments are prerequisites, not nice-to-haves.
Key Insight: Cultural Barriers in Distributed Teams
Cultural differences in engineering teams manifest in ways that are often invisible until they cause problems. Jim provides specific examples: in some cultures, engineers are reluctant to say “I don’t understand” or “I disagree” to a superior, which means problems go unraised and bad decisions go unchallenged. In others, the concept of “done” has different boundaries — code that works but isn’t tested or documented may be considered complete.
These aren’t failures of competence. They’re differences in professional norms that, when unaddressed, create friction, rework, and resentment on all sides. The American team thinks the international team is cutting corners. The international team thinks the American team is micromanaging. Both are operating according to their own cultural norms and interpreting the other’s behavior through their own lens.
Jim’s approach: make everything explicit. Define what “done” means in writing. Create feedback mechanisms that don’t require confrontation. Establish quality gates that catch gaps regardless of cultural communication preferences. And invest time in understanding the cultural contexts your international colleagues operate within — not to adopt those norms, but to bridge between them effectively.
Key Insight: Product-Driven vs. Engineering-Led Cultures
Jim draws an important distinction between product-driven and engineering-led organizational cultures, and explains why the tension between them is both inevitable and healthy when managed well.
In product-driven cultures, feature delivery and market response drive priorities. Engineering exists to build what the market needs, and technical decisions are evaluated primarily by their impact on product capabilities. In engineering-led cultures, technical excellence and system quality drive priorities. Product roadmaps are shaped by architectural realities and engineering capacity.
Neither extreme works well in isolation. Pure product-driven cultures accumulate technical debt until the system can’t support new features. Pure engineering-led cultures build elegant systems that don’t solve real customer problems. Jim describes how Oracle Health navigates this tension: product leadership defines what needs to be built and why, engineering leadership defines how it gets built and what technical investments are needed to sustain velocity.
The key is mutual respect and shared accountability. Product leaders who dismiss technical concerns as “just engineering problems” and engineering leaders who dismiss market pressure as “just business noise” are both failing their organizations. The most effective teams Jim has led operate with genuine partnership between product and engineering, where both perspectives inform every significant decision about building web applications and enterprise systems.
Key Insight: COVID’s Impact on Remote Teams and Engagement
The pandemic forced a rapid shift to remote work that tested every assumption about how engineering teams collaborate. Jim reflects on what that transition revealed at Cerner (now Oracle Health) — both the unexpected benefits and the genuine losses.
The benefits were real: many engineers were more productive working from home, commute elimination improved quality of life, and access to talent expanded beyond the Kansas City metro. But the losses were also real: new employee onboarding became dramatically harder, informal knowledge transfer evaporated, and team cohesion gradually weakened as the social connections that support professional collaboration deteriorated.
Jim describes the engagement strategies his organization deployed to counteract these effects: regular virtual social events, deliberate one-on-one check-ins focused on well-being rather than task status, and periodic in-person gatherings for relationship rebuilding. The most important lesson: engagement in remote environments requires proactive investment. In co-located settings, connection happens as a byproduct of proximity. In remote settings, it happens only when leaders deliberately create opportunities for it.
Key Insight: Oracle’s Acquisition of Cerner — Business Acumen in Tech Leadership
The acquisition of Cerner by Oracle was one of the largest healthcare technology transactions in history, and Jim experienced it from inside the organization. The conversation covers what this kind of massive organizational change looks like from a middle-leadership perspective — where you’re responsible for maintaining team performance through uncertainty you didn’t create and can’t fully control.
Jim discusses the business acumen that acquisitions demand from technology leaders. Understanding why the acquisition happened, what Oracle’s strategic priorities are, and how your team’s work fits into the new organizational context are all essential for making good decisions during the transition. Leaders who focus only on technical execution and ignore the business context make decisions that may be technically sound but strategically misaligned.
The practical challenge: keeping your team focused and productive when organizational identity, reporting structures, processes, and even job security are uncertain. Jim’s approach centers on transparency — sharing what he knows, acknowledging what he doesn’t, and maintaining a focus on the work that clearly matters regardless of organizational changes. For technology leaders at any level, the ability to maintain team effectiveness through organizational uncertainty is increasingly a required skill, not an edge case.
Takeaways
- Don’t treat international teams as interchangeable with domestic teams. Adapt management approaches to account for cultural and logistical differences.
- Make expectations explicit across cultural boundaries. What seems obvious in one professional culture may be invisible in another.
- Healthy organizations balance product and engineering priorities. Neither product-driven nor engineering-led extremes produce good outcomes.
- Remote engagement requires proactive investment. Connection that happened organically in offices must be deliberately created in distributed settings.
- Business acumen is a leadership requirement. Technology leaders who ignore organizational context make technically sound but strategically poor decisions.
- Transparency sustains teams through uncertainty. Share what you know, acknowledge what you don’t, and focus on work that matters regardless of changes.
