Improving The Odds Of Success: My Thoughts On Malcolm’s Book ‘Outliers’

 In Archive

I read Malcolm Gladwell’s ‘Outliers’ recently. I like his writing style and I find his examples and observations very thought provoking. While all the examples are compelling and Gladwell’s writing style helps in making a strong point, I am not quite ready to generalize the conclusions drawn.

I was most intrigued by Chapter Seven The Ethnic Theory of Plane Crashes. In this chapter, Gladwell describes the communication sequence between the pilots before the Korean Air crash and the sequence between JFK’s Air Traffic Control and the Colombian Airlines’ co-pilot.

Gladwell demonstrates how culture and ethnicity shapes behavior. He points that most air crashes are not because of some major technical failure in the plane but are a sequence of missteps. In this situation, a combination of events like pilot fatigue, difficult weather conditions and poor communication added to the reason for disaster.

For the last few weeks, I have been thinking if these analogies apply to software project failures as well and if we can address these to improve the odds of success on software projects. I will be happy to hear your views on this subject. Please share your thoughts on what you think.

– Anand

Interested in learning more about our offerings and solutions?
Let's connect
Recommended Posts
Showing 7 comments
  • jingle-all-the-way

    “We look at outrageously talented and successful people – the Beatles, Mozart, Rockefeller, Bill Gates – and assume there is such a thing as pure genius. Not necessarily…”

    I quite enjoyed reading this book myself. The book is thought-provoking. It made me think very differently about success. Gladwell insists so much on culture, timing of a particular incident, persistence, making the most of a ‘chance’ or a ‘situation’ that could determine success, it sure got me thinking about my own destiny.
    However, I was not quite convinced by his his explanations of why Korean airline carriers have more crashes or why white Southern men seem prone to violence.
    His anologies can certainly be applied to failures in software projects – dedicated and focused practice time, hours of hard work, proper communication, etc. could all add up to improve the odds of success.

  • Sammeer Chabukswar

    I just read this book, like his other books (blink, tipping point) he provides insights into events from a very different perspective. The example that you sighted above has been showcased in our UE presentations. Traditionally such incidents were referred to as ‘human error’ but as the field of human factors matured these failures were recognized to be of ‘design error’ OR design that is not suited to human capabilities and limitations. Most software fails in the marketplace because of mismatch between user expectations and what the software offers. I feel that software that is consciously designed for users (user experience design) has a high probability of success in the marketplace.

  • Siddhesh Bhobe

    I haven’t read the book yet, but the post got me thinking on the odds of success (or failure!). From our experiences in e2eConnect, one of the major learnings I had very early on in my career was that great technology and sophisticated algorithms mean nothing if your end users cannot use the software because it doesn’t map directly to their business needs. I have seen far too many products/deployments where my business model needs to change because the software or the technology doesn’t support it! I think the choice of technology should come very late in the SDLC, after all business requirements have been captured and documented. Unfortunately, with marketing hype, previous investments, and IT departments calling the shots, business users are left with no choice but grudgingly accept a system that doesn’t serve them – instead, they have to modify their operations and processes to serve the system. That’s a guarantee for failure. Another major factor is communication. I think a badly written status mail can create far more havoc than we give it credit for!

  • Prasadd Bartakke

    ‘User Centered Product Design and Development’ can be Persistent’s offering to not only ensure better product success (users’ acceptance) for our customers but also highlight it as a differentiator. It has all the ingredients that today’s situation needs – Faster time-to-market,increased productivity, confident and higher quality solutions. Could this be our mantra and way of life at Persistent? Can we pitch, sell and market it that way?

  • Kundan

    I have always thought of analogy between commercial aviation and software processes very useful. Like I say to my colleagues, running project without processes and human factor consideration is like driving a car in Pune city for more than 12 hours continuously. You are bound to get dents and scratches if not a major accident owing to fatigue coupled with no discipline. What project need is an auto-pilot system. A pilot cannot be expected to manually fly a plane for hours per day for years without doing a mistake.

    Applying this to Software projects and specific to the QA projects, what you need are processes that act like auto-pilot and automation of course. As a team lead you want some time off that control yoke and let auto-pilot fly the plane, so that you are able to think of new ways of improvement, innovation and efficiency. Set a lot of processes in project, it ensures that you do not fail often and in rare case of failure you put blame on processes rather than on individuals. Easier said than done, it requires lot individual conditioning to always think from failure perspective, to think in pro-active manner and anticipate things before they go wrong rather than fix things when they have gone wrong. By then the damage is already done, and the end result is a grumpy client and a burnt out team.

    At organization level a culture to think pro-actively is needed. What we tend to reward are the burnt out colleagues as a gesture of their heroic efforts. Let’s see an organization that is able to recognize pro-activeness also.

  • Ashish Anand

    To start with I have not exactly read the book, but yes I do know about it and all the examples Malcolm has given. Surely there are many things which can be taken from here, especially when he talks about the culture. Here is an example, when project manager plans things & developers knowing that it cannot be done, still nod their head and finally suffer in pain, which when inflates & makes the company suffer. Similarly no or less communication leads to in ability of people taking right decisions at right time or being reactive when a person needs to be pro-active. Finally if you see people at both the end move forward but the company suffers.
    My take from outliers, let’s build a open culture where people see opportunity everywhere & thus the company grows.

  • Anil Nair

    Anand, I read this book (Thanks!). Really fascinating. Specifically on the topic of communication and its relevance for software/product development (or project management in general) – I feel that in most projects communication quantity gets emphasized but not communication quality. I believe the root cause of poor communication quality is the lack of understanding of the purpose of a project and the purpose of a specific communication. We have all seen projects fail where there is a whole lot of communication that never served the purpose of getting the job done.

Start typing and press Enter to search

Contact Us
close slider
Contact Us

Yes, I would like Persistent to contact me on the information provided above. Click Here to read our full Privacy Notice.