Learning Agility: Why take the time to reflect?

This post is the fourth in a series I have been writing on Learning Agility.  My initial post talks about the five areas of learning agility as described by the Center for Creative Leadership-CCL.  These five areas are as follows:

  1. Innovating:  Agile learners are not afraid to challenge the status quo
  2. Performing:  Agile learners remain calm in the face of difficulty
  3. Reflecting:  Agile learners take time to reflect on their experiences
  4. Risking:  Agile learners purposefully put themselves in challenging situations
  5. Defending:  Agile learners are simply open to learning and resist the temptation to become defensive in the face of adversity

In previous posts I have spoken about innovating and creativity as well as the need to deal with challenge and obstacles in the performance of what we do.  In today’s post I’ll speak more about the value and power of learners and leaders taking time to reflect on their experiences to gain meaning and improve.  I’ll also share a personal experience to highlight just how this has been valuable to me.

Much of the work I have done, and see done by others, takes place in a project format.  As a result, project management is a key skill for each of us as leaders and learners.  One of the key components of project management is what some call the “post mortem”.  This time is set aside to review, reflect and learn from what went well and what could have been improved in a given project.  Time after time I have seen others, including me, gloss over or completely ignore this key step because we were too busy moving on to the next project.  Why can’t we all see the value in reflection as  a key tool for learning?

Some of this lack of reflection has been somewhat cultural in nature from my own personal experience.  My time working for the Japanese in the automotive industry taught me the value of planning and checking, sometimes painfully so.  As a member of the western, American culture, I found we were always so interested in moving ahead that we often missed key issues that needed to be corrected along the way.  We also missed valuable learnings from the project summary that could have been implemented in future projects of a similar nature.  I find that many of us are not students of the Deming process, PDCA; Plan-Do-Check-Act.  Rather than being disciples of PDCA we are more prone to be advocates of the Ready-Fire-Aim culture that focuses solely on speed and less on quality and process.  This kind of thinking diminishes the value of reflection both before, during and after any given project.

Let me share one personal experience where reflection gave me great insight into a life situation that didn’t appear to be positive upon first glance.  In 1983 I was working in a manufacturing role and found out that I was going to be part of a RIF, reduction in force, due to economic issues.  This occurred at the end of March.  After learning about this change I took the time to spend a week with my ailing father just prior to his death from cancer.  When I look back at that time now and reflect I see that i was given a great opportunity to share time with someone who meant a great deal to me versus spending more time in my prior role.  That final week with my father provided unreplaceable memories for me that will never be forgotten.

How many of us have neglected to take the time to reflect on issues that are currently involving us that might be altered to make better use of our time?  Better yet, how often do we pause and list all that we are engaged in to make hard decisions about where we are spending time versus where we “should” be spending time?  I suggest that this time of reflection will be valuable if you just set it aside and use it.

Reflection is a powerful tool, sometimes a scary tool.  You may choose to take someone along on the reflection journey to help you objectively process what you see and remove your own personal filters and biases.

If you do this, I know you will find what you have learned to be life-changing.