Do you trust your software development team? Trust means being able to predict the behavior of another person or team of people. There are different ways trust can be built and they are culturally dependent.
Unfortunately if your software development team tells you the software will be completed by a specific date and then they miss the date then your confidence and trust in them could go out the window. How do you know if any date they give you can be trusted?
Or if your software development team delivers an app with obvious defects that defy common sense it will erode trust. The VP of Engineering at a Canadian company received embedded software for a video system that reformatted the hard drive every time the system was turned on, thereby destroying any recordings that were previously made. “But that makes no sense!” the VP complained to the development team.
“But it was in the spec.” explained the technical lead on the outsourced team. It will be hard for the VP to trust that they will do the “right thing” in the future.
So what’s going on?
Trust issues are more severe when you outsource because building trust doesn’t work the same in all parts of the world. In fact asking detailed questions is a sign of distrust in many cultures, especially when negotiating.
There are cultural differences in the way people express disagreement. They can be confrontational or seek to avoid confrontation. Americans tend to somewhere in the middle according to Erin Meyer in her book The Culture Map and her recent article about negotiating internationally in the Harvard Business Review. Indians, Mexican and Filipinos are more likely to avoid confrontation in comparison to Americans. The communication of disagreement is more subtle and may be difficult for an American to discern when, for example, an Indian programmer says “no”. It’s even more difficult for an Israeli or a European from Russia, France or Germany where a more confrontational style is normal.
In India it is common for a software developer to accept a job and then just not show up on the first day if he got a better offer somewhere else. That’s a non-confrontational example that is just plain weird to an American!
Americans typically value past behavior as a predictor of future behavior. What success did you have in your last job? Have you used this programming language before? Tell me about a challenging problem and how you solved it?
Sound familiar? These are the typical kinds of questions you hear in a software developer behavioral job interview.
According to HBR article by Meyer, there are two ways to approach building trust – cognitive and affective. Cognitive trust is a fancy way of saying it is “the confidence you feel from someone’s accomplishments, skills and reliability.” This is like the behavioral interviews or what you look for when you examine case studies and success stories of a company. It’s what you are trying to judge when pouring over a resume in a hiring situation. Cognitive trust is rational and “comes from the head.” “Affective trust arises from feelings of emotional closeness, empathy or friendship. It comes from the heart.” Affective trust is built on personal relationships.
You are not likely to build trust with your software development team in most emerging market areas of the world until you make an affective or personal connection.
You can’t just count on just their English skills and you will need to build a bridge across the differences in communication style.
The best way to do this is visit regularly and get to know them. Yes, it adds to the cost but your goal is to get great software and not just a low hourly rate.
Breaking bread is an effective way to build affective trust and you can’t share a meal on a Skype call.
Lifelong friendships can be created this way. I am still close friends with several Indian developers that I worked with in the 1990s. A developer at a Costa Rican software development firm was the best man at the wedding of his product manager back in the U.S. Even Americans can appreciate affective trust!
Of course the overall goal is to create great software. There are smart software engineers everywhere. No matter where your software development team is located you can bridge the cultural communication differences to increase productivity and you will make good friends in the process too.