Same Words, Different Meaning
A client says "this is not good enough." A developer says "we will try." Both think the conversation went well. Both are wrong. Story about what happens when direct and indirect cultures work together
Nepal is growing its presence in the global IT sector. The reason is simple, hiring a skilled team in Nepal costs much less than hiring in the West. With a young and capable workforce, the potential is real. But along with the opportunity comes a challenge that not many people talk about.
I spent several years working for companies in North America and Europe. Very few projects were completed on time. There was always tension between clients and developers. Clients kept pushing hard on deadlines. Developers kept missing them. Over time, this damaged the reputation of Nepalese software engineers.
For a long time, I thought it was a management or client problem. Classic developer thinking: the code is fine, everything else is broken 😉.
When I moved abroad, I had the chance to study cultural differences as part of my masters degree. At the time I did not realise how much that would change the way I work.
My first real test was working with French colleagues. French people are very direct. They criticise openly and immediately. Coming from an indirect culture, this felt like a personal attack every single time. I took it personally on many occasions. I went home exhausted. There was a lot of emotional pressure in those early days just from normal conversations at work.
But the training I received during my studies gave me tools to handle it. Role plays, reading about different cultures, and most importantly experiencing it firsthand every day started to change how I listened. Slowly I stopped hearing the words and started understanding what the other person actually meant. The same feedback that once felt like an attack started to feel like information.
That shift changed everything for me at work. The relationships with clients & colleagues became better. I had not become a more skilled engineer. The work was the same type of work I had done back home. The difference was that I finally understood how the other side communicated.
The real problem was never technical skill. It was communication. Both sides were using the same words but understanding them in very different ways.
Direct and Indirect Communication
Every culture has its own way of communicating. In direct cultures, people say exactly what they mean. Feedback is clear. Problems are discussed openly.
In indirect cultures, messages are softer. Criticism is not always stated clearly. Keeping good relationships is more important than being blunt.
Neither style is wrong. But when both sides do not know about this difference, misunderstandings happen.
Example: Feedback
Client: “This is not good enough.”
The client means: let us improve this and move forward.
Developer: my work is bad.
The developer loses confidence. The project slows down. The client never knew there was a problem.
Example: Deadlines
Client: “Can we deliver this by Friday?”
The developer does not want to say no. So they say: “We will try.”
The client hears: yes.
The developer means: I am not sure, but I cannot say no.
Friday comes. The work is not done. Both sides are frustrated. Neither understands why.
Why This Matters
This kind of misunderstanding does not look like a communication problem from the outside. It looks like missed deadlines, unclear requirements, and difficult clients. Both sides start to blame each other. Over time, this affects how Nepali developers are seen around the world.
The solution is not to ask developers to change who they are. The solution is awareness. Nepali IT companies need to help developers understand how western clients communicate. They also need to help clients understand how Nepali developers communicate. Both sides deserve to understand each other.
If you are a developer working with western clients right now, start small. When a client asks about a deadline and you are not sure, try saying “I need to check and confirm by tomorrow” instead of “we will try.” When a client gives you sharp feedback, try to pause before reacting and ask yourself what they are actually asking for. These small habits take time to build but they make a big difference.
Understanding the other side does not happen overnight. It took me years of practice, training, and many uncomfortable moments. But it is a skill that can be learned. That is what this series is about.
In the next post, I will look at how indirect responses to unclear requirements lead to scope creep and what developers can do about it.
This is part one of a series about communication in software teams across different cultures, written from a developer’s perspective.