Building Bridges: Managing a Polish Development Team with Cultural Awareness

A Dutch SaaS company decided to expand their engineering capacity by building a development team in Poland. The technical talent was excellent — strong computer science fundamentals, deep experience with their stack, and impressive problem-solving ability. But within the first three months, the collaboration was not working as well as anyone expected. Deadlines were met, but the Dutch product team felt they lacked visibility, while the Polish developers felt micromanaged and undervalued. The company brought in Emplex to help bridge the gap.

The Challenge

The issues were not about competence — they were about culture, communication styles, and unspoken expectations on both sides. Several patterns had emerged:

Communication directness: The Dutch team valued blunt, direct feedback — it is a cultural norm in the Netherlands. The Polish team, while certainly not conflict-averse, operated with more professional formality and context-setting. Direct feedback delivered without context felt dismissive; meanwhile, the Dutch side interpreted the Polish team's more measured responses as lack of engagement or reluctance to push back.
Work ethic misunderstandings: Polish developers had a strong work ethic but also clear boundaries around working hours and overtime. The Dutch startup culture of "we all just do what needs doing, whenever" clashed with a more structured approach to work-life balance. Neither side was wrong — they simply had different norms.
Hierarchy and initiative: The Dutch team expected developers to challenge requirements, propose alternatives, and push back on unrealistic timelines proactively. The Polish team, while fully capable of this, operated in a culture where the relationship with leadership needed to be established before that level of candid pushback felt appropriate. The Dutch team read this as passivity; the Polish team felt they hadn't been invited to contribute at that level.
Recognition and belonging: The Polish team felt like an outsourced resource rather than a genuine part of the company. They were brought in for execution but excluded from product discussions, strategy sessions, and social events. This reinforced a two-tier dynamic that undermined motivation.

Our Approach

We focused on understanding people first, processes second. Our engagement had three pillars:

Cultural awareness workshops for both sides: Not a generic "cross-cultural training" slide deck, but facilitated sessions where both teams discussed their actual working styles, expectations, and frustrations openly. We helped each side see the other's behaviour through a cultural lens rather than a personal one. The Dutch team learned that directness without context feels dismissive in Polish professional culture. The Polish team learned that the Dutch team's bluntness was not a sign of disrespect but an invitation to be equally direct.
Structural integration: We restructured team organisation so that Polish developers were embedded in product squads alongside Dutch colleagues, not siloed as a separate "offshore" team. They joined product discovery sessions, architecture discussions, and retrospectives as equal participants. We also introduced a buddy system pairing Polish and Dutch developers for knowledge sharing and relationship building.
Communication norms redesign: We established shared communication agreements: async-first for status updates, synchronous for problem-solving, and dedicated weekly sessions where the Polish team was explicitly encouraged to challenge product decisions and propose alternatives. We also normalised written communication for anything requiring nuance, since it gave non-native English speakers time to articulate complex thoughts precisely.

The Implementation

The cultural workshops ran over two days — one day in Amsterdam, one in Krakow. Having each team visit the other's office made a tangible difference. The Dutch team experienced Polish hospitality, the working environment, and the city. The Polish team saw the Amsterdam office's energy and pace. Both sides started seeing each other as people rather than Slack avatars.

The structural changes took four weeks to implement. We reorganised Jira boards, meeting schedules, and Slack channels to reflect integrated squads rather than separated teams. The hardest part was getting the Dutch product managers to genuinely include Polish developers in upstream discussions — it required changing habits, not just org charts.

We ran monthly retrospectives focused specifically on cross-cultural collaboration for the first quarter, gradually reducing as the new norms became natural.

Results

After three months of the new approach:

Cross-team collaboration satisfaction increased from 4.2/10 to 8.1/10 in anonymous surveys on both sides
The Polish team's contribution to product decisions became substantial — they proposed architectural improvements that saved two months of planned refactoring work
Voluntary turnover in the Polish team dropped to zero — previously, two of eight developers had been actively interviewing elsewhere
Cycle time for features involving both teams decreased by 35% as handoff friction disappeared
The "us vs them" dynamic dissolved — team members started referring to themselves as one team rather than "the Dutch team" and "the Polish team"

Key Takeaway

Technical talent is only half the equation when building distributed teams. The other half is understanding that people bring their entire cultural context to work — and that cultural differences are not obstacles to overcome but perspectives to integrate. The Polish developers were never the problem. The lack of mutual understanding was. Once both sides invested in seeing the world through each other's eyes, the collaboration became one of the company's greatest strengths.

Building or managing a distributed team? Get in touch — we can help you turn cultural diversity into a competitive advantage.