Creating software usually involves quite some people, as there are important tasks to take care of: gathering requirements, validating them, writing the code, testing created softwate just to name a few. These different tasks create certain roles, each requiring different skillsets and thus, people who fill them in differ in background and lexicons they use. Product owner will have different perspective and use other concepts on daily basis than a business analyst, who in turn uses a different lexicon than a developer.
I won’t be discussing who should be talking with who in a software development process. Every development team merges or splits the roles as it fits the context, but there are some common communication barriers, which are not dependent on how the roles in a project are assigned.
Every project has some inherent hierarchy in the process of communication. Product owner does not communicate with the whole development team on a daily basis – it’s unfeasible. First, depending on the size of the team, gathering all the people in one place could be impossible. Second thing, which also depends on the size of the team, not everyone is on the same page. If a new programmer comes to the team, he will have a hard time understanding, what is being discussed. He does not possess enough knowledge to get sufficient understanding. Because of these reasons, there are managers, who receive requirements from higher-ups and then discuss them with the development team. Such communication defers the propagation of knowledge a little, but avoids the problem of not sufficient knowledge mentioned earlier.
This isn’t however innovative nor exclusive for the IT world. We see such communication everyday. A real estate developer won’t be talking directly to the physical workers as it just won’t work – he wouldn’t speak comprehensively enough for them. Such developer thinks of abstraction: “Build me a building”, but the workers need much more tangible info: where, what size, what materials to use. The same class of problems also occur in software development, but they are solved by delegation. This way, a real estate developer does not need to know how to put up a wall and a product owner does not need to know how to create a web service.
However, the deferral of knowledge spreading really kicks in, if the last in hierarchy spots something inconsistent or otherwise needing a consultation. Sometimes, getting the info higher and then getting a response can take quite some time.
When you get into IT world, language itself usually is not an issue – English is almost a necessity if you want to be a developer or a tester anyway. Differences in culture can however prove to be problematic. When two non-native English speakers talk to each other, either in person or electronically, the level of formalism and politeness is usually not very high. After getting used to that, switching to talking with British people can lead to some misunderstandings (possibly even hurt feelings). That’s the result of projecting native “language mentality” to a foreign “language mentality”. English contains considerably developed honorifics which are used when talking or writing. In my native language however, excesive use of expressions of politeness seems very unnatural, fake even.
Both sides – natives and non-natives – have to be understanding towards each other in that matter. It’s not that non-natives don’t want to express politeness, it’s difference in culture and thus, mentality, which makes us use the English language in a more colloquial way.
I’ve heard and read different estimates about the rate of introverts among software developers. Some say, that even 66% of programmers are introverted. I do not have a reliable researches at hand, but I can tell from experience, that there are quite some introverts in our ranks. Truth be told, software development requires focus and sometimes long hours of debugging, where being interrupted by someone is the last thing you want to experience. Because many of us are introverted to a lesser or higher degree, there may be some hesitation in communication, especially concerning the youngest employees. The importance of communication should be stressed more heavily in Computer Sciences courses, so young IT workers are better prepared for the job.
Because of the nature of the work, distributed teams in IT are quite common. That not only causes the cultural differences problems discussed earlier, but work schedules may start to play a significant role in communication. When I go out of office in Poland, some of the people in the US have just started their work. Communication is then basically deferred by a work day. That certainly isn’t desirable, but can be fixed to some degree by changing the working schedules to overlap with each other more, but the maximum depends on how far two places are apart. You can’t really fight physics.
Every software development project will have some communication problems, no doubt. But their impact tends to be smaller with time, as people learn how to work with each other, how to talk, when we are available, what pieces of information are relevant for whom. Even if the previous sentence may feel cliche, it still holds true and implementing correct communication patterns and tools always takes time.