Confront the brutal facts

Confront the brutal facts was a challenge from Chet Richards’ keynote at LSSC11 and I believe he borrowed it from the book “Good to Great” by Jim Collins.  In my opinion, there are at least three key things this challenge brings to light.  Firstly, something(s) is negatively impacting the performance of an organization.  Secondly, we need to find the facts that are brutal, not just the everyday-run-of-the-mill facts.  Lastly, it’s not just good enough to know the brutal facts, they must be dealt with.

Merriam Websters defines brutal as: very bad or unpleasant.  A brutal fact is something that is both very real and not terribly nice.  Being unpleasant is obviously context bound and relative to an organizations particular situation.  My brutal facts are not my next door neighbors brutal facts.  Examples of brutal facts in software development could be consistently delivering software into production much later than originally planned, having builds fail every time code is checked in or not having a technically competent team.

Truth be told, many organizations defer, downplay or outright avoid identifying brutal facts because the exercise of doing so is both self-revealing and self-indicting.  Who really wants to talk about what’s going wrong?  The teams I’ve worked on have never had a problem talking about the good stuff we were doing, but talking about our mishaps never shared the same enthusiasm.  This unpleasantness is due largely in part to the fact that identifying brutal facts is often conducted as a highly subjective exercise with no concrete data to go off of.  When meaningful data is not collected, its challenging to even determine what the brutal facts are let alone possibly address them. Because of our “ladders of inference”, we need data that we can all try to agree on.  If you truly want to identify brutal facts you need to collect information and track/measure important indicators.  You need to be an organization that is desperate to learn.  Unfortunately, too many organizations measure stuff that doesn’t really matter, but that’s a topic for another day.   Revisiting the example of functionality being delivered late, if a team had collected issues/blocks/impediments during the development cycle, identifying the brutal facts possibly becomes a simple activity of reviewing the impediments.  The review could reveal that the development team doesn’t have the access it needs to the end users or subject matter experts for clarifications on how the system should behave.  Combining information like this with techniques such as the 5 Why’s can make identifying brutal facts a bit easier.

That being said, you don’t get brownie points for identifying brutal facts, no my friend, no gold stars for you.  Brutal facts need to be addressed.  The word confront carries with it what could be considered a “negative connotation” but I appreciate the choice of word here because it conveys an attitude of an active and aggressive attack on brutal facts.  That being said, it’s so very easy to address brutal facts incorrectly within an organization.  An improperly addressed brutal fact can actually do more harm than good in same way that trying to kill a fly with a hammer is an idea that can leave you with a busted thumb and broken glass all over the house.  In fact, you may be better off leaving the brutal fact as is if the only alternative you have is to address it incorrectly.

Why do we fail do address brutal facts effectively when they are identified?  I would suggest that this is due (at least in part) to our traditional analytical problem solving approaches i.e. looking at the brutal fact in isolation and not seeing it as part of a potentially larger problem.  A classic example of this is the persistent notion that the way to solve the software delivery problem suggested earlier is by adding more developers.  However, adding more developers would obviously just worsen things.   Unfortunately many organizations struggle to look at things in a holistic manner because they do not have the necessary eduction, training and skill required to address issues holistically within the organization.  This where I believe an understanding of Systems Thinking can significantly help teams and organizations address brutal facts in a holistic manner.  A book recommendation for that would be Peter Senge’s: The Fifth Discipline: The Art & Practice of the Learning Organization.   Systems thinkings in of itself is not a panacea – nothing in isolation is – but looking at the whole system hopefully gets us moving in the right direction.  For the team that does not have the access they need to SMEs, the organization could make a decision that SMEs need to set out an hour each day to address questions from the development team.  That could be a holistic solution.

What brutal facts plague your organization? Are you up to the challenge to confront them? I hope you are!


2 Replies to “Confront the brutal facts”

  1. Hi Eb,

    Do you really want to know the truth? Even if the truth is extremely unattractive? Or would you prefer a much more palatable truth? Micheal Sahota talks about a red pill, blue pill moment, from the movie The Matrix:

    We get to choose our own reality, and most of use will choose the blue pill. Life is just more comfortable that way. So in turn there are more people marketing and selling blue pills. Why? Well because there is a bigger market and hence they are more lucrative. Also because these sellers also choose to believe in their product. And so the cycle of self delusion continues. It is why we are plagued with fads. I’ve witnessed the same fad come full circle, and regain popularity in under 10 years, with people having amnesia, conveniently forgetting the past, and buying what was universally seen as failing only a few years previously.

    As for measures. There is a good quote out there: “Not everything that is of value can be measured, and not everything that can be measured is of value”. In the face of complexity this is so true. If a lack of measures was our only problem we would have cracked it long ago.

    Another good quote. “For every complex problem there is a simple answer that is wrong”. Again so true, yet we remain addicted to simple answers, simply because we want it to be so.

    I don’t see this changing any time soon. We are in the murky land of human psychology. It will take a phase change in our collective thinking along the lines described by Bob Marshall. A last useful quote. One where I actually know the originator:

    “We will win and you will lose. You cannot do anything because your failure is an internal disease. Your companies are based on Taylor’s principles. Worse, your heads are Taylorized too. You firmly believe that sound management means executives on the one side and workers on the other, on the one side men who think and on the other side men who only work.”

    Konusuke Matsushita – Panasonic

    Again so true. In my opinion it will take new people with new assumptions and new thinking to break the blue pill cycle and create new red pill organisations. Perhaps it is already happening with new technology companies like Google. Sema in Brazil is also an interesting case study.




  2. Hey Paul –

    Well said – I have read Sahota’s stuff also. So thanks for bringing that up. Sticking to ladder analogies, you are further up the ladder and see a new of barriers to break through. However, there are people at the lower rungs. Measuring something would be a step in the right direction for some folks – though its not a panacea. You know how you know some measures are useless? Because you’ve measured in the past!

    A brutal fact for some of us is that we’re clueless – but hey I wanted to be nice. 🙂



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s