I recently came across National Geographic’s article, Could Malcolm Gladwell’s Theory of Cockpit Culture Apply to Asiana Crash? For those of you who are unfamiliar with this theory, bestselling author Malcom Gladwell proposed that the culturally-based power distance between pilot and copilot in the cockpit can be a main determinant of success or failure in a flight. He cites Korean Air as an example. For a period in the 90s, Korean Air had more planes crash than almost any other airline. While many may assume ageing planes or poorly trained pilots to be the cause of these crashes, Gladwell effectively argues that cultural legacy was the cause. Korean cultural legacy is hierarchical and built on a relative structure based on seniority, respect and familiarity. Historically, this structure has manifested a cockpit culture in which copilots are deferential toward their senior, the pilot, even when the pilot is exercising poor judgement.

Collaborating in the project room

While the article rebukes the argument that the crash was caused by culture, it reminded me of the potential for power distance to play a pivotal, and sometimes detrimental, role in team-based activities. I wondered how this might affect my project team.

Here at Intelliware, we operate according to our Agile, i-ProvingTM methodology, which includes working on project-based teams. We foster an environment in which everyone’s thoughts and opinions are valued. That being said, the level of communication for any given project team depends on the personalities, cultural backgrounds and leadership styles within the room. These differences between team members can affect how we collaborate. For example, the power distance between teammates can lead to an imbalance of member contribution. Just as Gladwell found risk in the high power distance between Korean pilots and copilots during the 1990s, we find that a similar risk is possible between a senior developer and a junior developer when pair programming. At times, rather than working together to solve the complex task at hand, the senior developer takes control of a task while the junior developer watches passively. This problem can be compounded by cultural differences if the senior developer is from an assertive culture and the junior developer is from a culture that values cooperation.

I have also experienced culture’s affect on my team when each team member is asked to estimate how long a piece of work will take to complete. It isn’t uncommon for junior developers’ estimates to be undermined by his or her senior team members. Like with pair programming, this problem can be compounded if the junior developer is also from a cultural background that is more cooperative or more reserved than his or her teammates.

The consequences of culture in the software development project room are certainly not as dramatic as they may be in the cockpit of a plane but these consequences could manifest in subtle ways and cause major failures in the software project. Inaccurate estimates can affect the team’s capacity to deliver value to the customer in a timely manner. Power imbalances between teammates could lead to reduced collaboration and a fragmented team. Disenfranchised team members may underperform on projects and be limited in their career progression.

In a typical Canadian or American workplace, you must speak up or others will do so for you. If you are a relatively passive person, after awhile you might find yourself struggling to move forward on your career path – or to remain on the path you’re already on. Personally, I am not an assertive, Type A leader. Growing up in Hong Kong, I was taught to respect others, especially those senior to me, be it in age or in skill. I was taught that confronting my superior would limit my career, especially if the result had potential to make them look bad in front of others, therefore “losing face”.

It is a different culture here in Canada. Over the years, I have learned to speak up more often. I am also fortunate to be able to work for Intelliware, a software development company in Toronto, which values collaboration and communication and celebrates diversity when staffing a team.

I think cockpit culture exists in most social and professional environments. Consequently, we have to be mindful of it and plan to staff the team in order to avoid the extreme and negative scenarios. In the project room, team leaders need to be able to sense whether team members, particularly those who are more junior, feel comfortable expressing their opinions. Like good teachers, team leaders need to facilitate a collaborative and communicative environment. To do so, they need to foster a safe and open culture.

To help you create this environment, consider the following:

Create an environment of equals from the start

  • Make sure that everyone’s voice is heard in the first meeting

Before pair programming, have the team leader first speak to each programmer separately

  • Let the senior developer know that the junior developer has been encouraged to share their opinions openly. Ask the junior developer to share their opinions openly with their senior partner

If a project member seems uncomfortable sharing their opinions with the team, have the team leader ask them for their opinion in a one-on-one setting

  • Provide positive feedback to encourage them to share their opinion more often

Build diverse, multicultural teams

  • Diverse teams might take longer to gel, but they benefit from having broader cultural and life experiences that help avoid groupthink