We've been building software for organisations across the Pacific this year, and the lesson that keeps asserting itself is this: technical competence isn't enough. You can write clean code, deploy reliable infrastructure, and follow every UX best practice in the book. If you don't understand the cultural context you're building for, none of it matters.
What You Need to Know
- Cultural competence in technology projects means understanding how communities organise, communicate, and make decisions before you design systems for them
- Western enterprise assumptions about hierarchy, privacy, data ownership, and consent don't transfer automatically to other cultural contexts
- Working with local partners as genuine co-designers, not just reviewers, produces fundamentally better outcomes
- The cost of cultural incompetence isn't just a bad product. It's eroded trust that makes future projects harder
What Cultural Competence Actually Means
Cultural competence isn't sensitivity training. It isn't adding a mihi to the start of a meeting. It's the operational understanding that the people you're building for might organise their world differently than you organise yours, and that their way of organising is valid.
In practice, this shows up in unexpected places.
Data ownership. In many Pacific Island communities, personal information isn't just personal. It belongs to the family, the village, the community. A case management system that treats data as individually owned may violate cultural norms that exist for good reasons. Who has the right to see what? Who should be consulted before information is recorded? These aren't edge cases. They're foundational design decisions.
Decision-making. Western enterprise culture assumes decisions flow through a hierarchy: manager approves, director signs off, executive sponsors. In many Pacific contexts, decisions are collective. The village council, the family unit, the faith community all have legitimate roles. A system that routes approvals through an individual may miss the actual decision-making process entirely.
Language and terminology. Direct translation is rarely sufficient. Clinical terms that are precise in English may not have equivalents in Samoan or Tongan, or worse, may have translations that carry different connotations. The word you choose matters. Working with local language experts isn't optional.
70%
of ICT for development projects fail to achieve their objectives, often due to inadequate contextual understanding
Source: World Bank ICT for Development Report, 2020
Why This Matters for New Zealand Teams
New Zealand sits in the Pacific. Many of us have Pacific heritage. We have relationships, family connections, and cultural knowledge that teams from further away don't. But proximity isn't the same as competence. Having Pasifika team members is valuable. Assuming their presence means you've covered the cultural competence requirement is not.
Cultural competence isn't a box you tick. The communities you serve will tell you whether you got it right, and you need to be prepared for the answer to be no.
Dr Tania Wolfgramm
Chief Research Officer
Every Pacific nation has its own governance structures, social norms, and communication protocols. Samoa is different from Fiji is different from Tonga is different from Vanuatu. The "Pacific" is not a monolith, and treating it as one is its own form of cultural incompetence.
What We've Learned
Working in international development this year has taught us things we couldn't have learned from a textbook.
Start by listening, not designing. Our first trip was primarily about understanding. Not requirements gathering in the traditional sense, but understanding how the organisation operates, who the key people are, what the community values, and what previous technology interventions have looked like. Some had worked. Many hadn't. Understanding why was essential.
Local partners aren't consultants. They're co-designers. The most valuable input we received didn't come from formal workshops. It came from conversations with local staff who understood the daily reality in a way we never could. Their knowledge of what would work and what wouldn't was based on years of lived experience. Treating that as peripheral to the design process would have been a mistake.
Infrastructure constraints are design constraints. Reliable internet, consistent power, modern devices. These aren't guaranteed. Building software that requires all three to function is building software that won't function. Offline capability, low-bandwidth optimisation, and compatibility with older devices aren't nice-to-haves. They're requirements.
Trust takes time and is easily lost. Communities that have been subject to poorly executed technology projects are, understandably, cautious. Trust isn't built in a discovery workshop. It's built over months and years of consistent, respectful engagement. Every promise you make will be remembered. Every promise you break will be remembered longer.
The Enterprise Parallel
You might be reading this thinking it applies to international development but not to your enterprise project. I'd push back on that.
Every project serves a community. An internal systems project serves employees. A customer platform serves customers. A public sector project serves citizens. Each of these communities has its own culture, its own way of working, its own history of technology interventions that worked or didn't.
Understanding that culture, not just the requirements, is what separates projects that get used from projects that get tolerated.