Working Across Cultures — Collaborating with International Teams

A web director based in Tokyo had been working with an overseas engineer for three weeks and was troubled by the feeling that "progress is invisible." Slack responses came quickly, always with "OK, got it." But when the weekly report arrived, task completion was less than half of what was expected. When the issue was raised, the response was: "I couldn't make decisions because there were no detailed specifications."

This was not a language problem. It was friction created by a difference in cultural assumptions.

In Japanese business practice, an implicit expectation often functions: "If we share the general direction, the other party will read the atmosphere and fill in the gaps." But in many overseas business environments, the principle is that work not explicitly instructed should not be started, and "OK" is simply an expression of agreement — it does not necessarily mean work has begun.

Friction in global collaboration falls into three broad layers.

The first layer is the language barrier. This is the most visible obstacle and what most people try to address first. But investing in English training or translation tools alone does not resolve collaboration problems. Language is merely a medium; how the message is interpreted depends on cultural context.

The second layer is communication style differences. The assumptions about what to say, how to say it, and when to say it differ. In teams where direct pushback is seen as a sign of integrity and teams where harmony is valued and opinions are expressed indirectly coexist, even constructive discussions can be perceived as "aggressive" or "evasive."

The third layer is differences in structural work assumptions. How deadlines are interpreted (firm vs. approximate), how quality standards are defined (what "finished" means), how consensus is built (unanimous agreement vs. majority rule vs. authority decision), and how granular reporting should be (report immediately when problems arise vs. report after resolving them) — these are foundational differences that affect the entire project operation.

The critical insight is that these friction points are not "a capability problem with that person" but "a difference in cultural codes." Attributing the cause to an individual damages relationships and leads corrective actions in the wrong direction. Treating these as structural problems and redesigning the team setup is the only effective approach.

The concept of "high-context/low-context culture" proposed by anthropologist Edward T. Hall is one of the most practically useful frameworks for understanding friction in global collaboration.

In high-context cultures, much of communication depends on context, relationships, and non-verbal cues. What matters is not so much the literal content of what is said, but "who said it," "under what circumstances," and "what was left unsaid." Japan, Korea, China, Arab countries, and many Latin American countries are said to exhibit this tendency.

In low-context cultures, messages are embedded in the words themselves. Intentions are articulated explicitly, with less reliance on context or non-verbal cues. Germany, Scandinavian countries, North America (especially the US and Canada), and Australia are representative examples.

Here is how these differences manifest in practice.

The "No" problem

Team members from high-context cultures often avoid direct refusals. Expressions like "We'll consider it," "That seems difficult," and "Some adjustment would be needed there" can be functional "No" responses. When a client from a low-context culture interprets these as "Yes," significant confusion arises later.

An effective countermeasure is habitualizing "confirmation questions." Asking "Can you take on this task? Specifically, when and in what form can you handle it?" makes implicit "No" responses explicit by anchoring them to concrete actions and deadlines.

The feedback temperature gap

In low-context cultures, candid critique of deliverables is an expression of professionalism and respect for the other party. In high-context cultures, negative comments in a public setting are recognized as a risk that can damage relationships.

It is not unusual for a German counterpart to interpret "It's not bad, but needs a bit more consideration" from a Japanese team as "a positive evaluation." Conversely, a Japanese team member who hears "This needs significant rework" from a Western team may receive the harshness as a personal attack and become subdued.

The countermeasure is to agree in advance on a feedback format. Using a structured feedback template — overall assessment → three positives → three improvements → priority — reduces interpretation variance caused by cultural differences.

The "done" definition problem

Japanese software development tends to prioritize attention to detail and aim for delivery in a "near-perfect state." In contrast, Western teams where Agile development culture is standard approach things as "release in a working state and improve through iteration."

Both sides use the word "done" while meaning completely different things, causing confusion when deliverables are received. The countermeasure is to document a "Definition of Done" at project kickoff and reach agreement from both sides.

These differences are not a matter of superiority or inferiority. The key to collaboration is not determining which approach is "correct," but designing a translation layer based on the premise that different codes coexist.

When a Tokyo-based team collaborates with a client in New York, the time difference is 14 hours (13 during daylight saving time). Tokyo at 9:00 AM is New York the previous evening at 8:00 PM (7:00 PM during daylight saving). Overlapping work hours are extremely limited, and a project design premised on real-time interaction will not function.

The biggest failure pattern in time-zone environments is maintaining a synchronous communication design. Habits like "decide in meetings," "reply immediately on Slack," and "confirm by phone" produce late-night message notifications, irrational early-morning and late-night meetings, and blocking delays caused by waiting for responses.

The effective design principle is an async-first structure.

Async decision-making

Non-urgent decisions are made document-based rather than in meetings. When requesting a judgment, a "decision document" specifying "the decision needed, background information, options, recommended approach, and response deadline" is left in Notion, Confluence, or similar tools. The other party can review the content in their time zone and append comments with their opinion. Meetings are dedicated exclusively to "confirming agreements" and "maintaining relationships," minimizing time required.

Maximizing overlap hours

For Tokyo and London (8–9 hour difference), overlap time is limited but exists. Institutionalizing this overlap as "core hours" and handling only high-priority topics during it. Establishing the convention that Slack notifications outside core hours are muted removes the team-wide pressure to respond in the middle of the night or early morning.

This convention not only prevents conflicts but also prevents member burnout. One of the primary causes of burnout in global teams is "always-on pressure without knowing when the next message will arrive."

Async progress management

Instead of holding daily stand-up meetings to track progress in real time, introduce async stand-ups. Each person posts "what I completed yesterday, what I'm working on today, and any blockers" in a designated channel at the start of their workday in their time zone. Tools like Slack, Teams, Linear, and Jira can be used.

Particularly important in async environments is immediate sharing of blockers. When a problem arises, share it immediately without waiting for the next overlap window, enabling the other party to prepare solutions within their working hours. The Japanese-style habit of "report after resolving the problem" causes significant delays in async environments.

Explicit time zone notation

When writing dates and times, always specify the time zone. "I'll check at 10 o'clock tomorrow" is a source of confusion. Standardize the format "2026-10-03 10:00 JST (= 01:00 UTC)." Use tools like WorldTimeServer or World Time Buddy, and make it a habit for meeting invitations to display local time for all participants.

The biggest characteristic common to global teams that function well is a communication culture centered on written language. Reduce verbal and informal agreements, and document all important agreements, decisions, and specifications in writing.

This is different from simple "meeting minute creation." It is a conceptual shift that positions documentation not as "records for future reference" but as "the primary medium of communication."

The culture of writing "why"

Many Japanese teams document "what to do (What)" but tend to omit "why (Why)" and "what was considered before deciding (Context)." This omission causes problems with international teams.

Recording only the decision "page X will have a simple design" leaves a later team member unable to understand "what does simple mean?" or "why simple?" A "decision record including Why" is needed: "Because competitive analysis showed users prioritize data processing speed above all else, and decorative elements were the primary cause of page load delays, page X will adopt a simple design."

Maintaining a glossary

At project kickoff, create an English-Japanese bilingual list of industry-specific terms, internal company concepts, and abbreviations. Whether "KV" refers to a key visual or whether "CMS" refers to a specific system cannot be communicated without context. Maintain the glossary as a living document with continuous updates.

Defining roles for communication channels

Clearly define "what each channel is for" across Slack, email, video meetings, and document sharing tools. The following definitions work effectively:

• Slack: Questions requiring quick responses, brief progress updates, incident reports. Response deadline within 4 hours (during business hours)
• Email: Formal external communication, agreements that need to be retained as records
• Video meetings: Complex discussions, relationship building, feedback requiring emotional consideration
• Notion/Confluence etc.: Specifications, decision records, process documents — information that will be referenced permanently

Without this definition, important decisions become buried in Slack flows and cannot be found later. Or they scatter across emails, making it impossible for new members to understand past context during onboarding.

Meeting documentation habits

Within 24 hours after a video meeting, document and share three items: "decisions made, action items (with owner and deadline), and next agenda." Consistently maintaining this habit structurally eliminates "he-said-she-said" problems.

Meeting minutes do not need to be detailed conversation transcripts. It is sufficient to clearly record "what was decided, who will do what by when." Long minutes go unread.

Even with well-designed processes and systems, global collaboration will not last without trust between people. Building trust with members from different cultural backgrounds requires conscious effort.

Designing virtual water coolers

When working in the same office, hallway conversations and lunch-time chat function as informal relationship-building opportunities. In remote, async environments, these do not arise naturally. They must be intentionally designed.

A monthly "no-agenda meeting" is effective. Business topics are prohibited, and time is devoted to talking about how people spent their weekends, hobbies, and aspects of each other's cultures. This time, which may seem "inefficient" at first glance, builds the foundation of trust.

Creating a "casual channel" in Slack for members across different time zones and encouraging contributions is also effective. Sharing photos, local events, and interesting links creates "human presence" in a virtual space.

Making failures a learning opportunity

Communication failures are inevitable in global teams. What matters is how failures are handled. Creating a cycle of "observe → understand → improve" rather than "blame → defend → distrust" determines the sustainability of the relationship.

When cultural misunderstandings occur, frame them as "a problem with our communication design" rather than "the other person's fault." Specifically, review the scene where the misunderstanding occurred and have the team examine "which channel, in which format, and what information shared would have prevented it." This habit of "process post-mortems" strengthens the team's adaptability.

Including a culture guide in onboarding

When welcoming a new member to a global team, make it standard practice to provide not only technical procedures but also a "team culture guide." Contents should include: "team communication norms (what to discuss on which channel)," "decision-making processes," "expectations for how to give and receive feedback," and "cultural diversity considerations."

This document is also an accumulation of lessons learned. Even if initially thin, growing it alongside the team converts tacit knowledge into organizational knowledge.

Global collaboration does not work perfectly from the start. Reframing cultural differences not as "barriers to overcome" but as "diversity to leverage," and continuously improving the design, is the essence of sustainable international collaboration. Intentionally creating an environment where members with different cultural backgrounds can each demonstrate their strengths becomes the greatest competitive advantage in global projects.

References