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!