Critical Thinking, Criticism, and Problem Solving

In higher education, we talk often about the value of critical thinking.  We want our students to learn to be critical thinkers.  Wikipedia gives a whole list of definitions of critical thinking, but here is one I particularly like:

Critical thinking is a tool by which one can come about reasoned conclusions based on a reasoned process.

Criticism is a related activity, but there are some differences.  Here is Wikipedia's definition:

Criticism is the practice of judging the merits and faults of something or someone in an intelligible (or articulate) way.

 Finally, we have problem solving.  It seems to me that the first step in problem solving is recognizing that there is a problem and defining it.  This requires critical thinking, or maybe criticism.  After all, you can't solve a problem if you don't know what it is.

So what's not to like about all of this?  Like almost any good human attribute, there is a flip side.  If you let your critical thinking flip into negativity, then you will have a hard time getting support from others in solving the problem.  If your criticism is too harsh, then the recipient will have a hard time accepting it, since he or she will become mired in feeling bad and won't hear the message.

I value my skill as a critical thinker and a problem solver, but I sometimes struggle in giving criticism.  What helps me in this realm is to keep balance in mind.  I must balance my critical thinking with compassion and diplomacy.  And like a lot of people, I can be my own worst critic, so I have to remind myself to keep that important balance when I am working on self improvement.

Leaders must be critical thinkers, they must solve problems, and they must offer criticism.  The trick is to employ balance to do it well.

Planning and Measuring Pays Off

Information Technology Systems and Services (ITSS), the department I lead, has been creating an annual Goals and Priorities plan for many years now, with the plans on the web back to 2000-01.  Moreover, we have been collecting process measures in each of our teams back to 1996.  This year, we saw a major payoff to all this work.  The UMD campus has launched a Program Prioritization Initiative, whereby every campus unit will submit information, including measures data.  This information will be scored by a committee and reviewed by our Chancellor's Cabinet.  Here is the goal of this initiative:

The goal of the Program Prioritization initiative is to manage and allocate our financial resources in ways that will best meet the needs of our students and our community.

 As our department has been working on our responses, we discovered how valuable our plan and measures are.  We were able to respond to the questions by showing our plans and supporting our points with measures data.

Now certainly we believed that these plans and measures were worthwhile during all of the years we have been doing them.  Planning documents set the goals for the department to meet each year.  Measures allowed us to see how our processes were working and to seek improvements where needed.  If we hadn't believed in their value, we would not have done all that work.

This year, however, it feels really great to see that work pay off as we work on our program prioritization response.  We sure hope we get some great scores.

Engaging the Other Side

This week I read, "Need Buy-In?  Invite the Lions In," by John Kotter in the Harvard Business Review Blog Network.  There is an accompanying video as well.  In these materials, Kotter talks about the value of bringing the "naysayers and obfuscators" to your presentation.

This reminded me of some of the issues we are experiencing in our newly-established Technology Coordination Meeting in our department.  We have had a few experiences when a technical group brings forward a new technology or upgrade, only to have many objections raised by the support staff, who worry about the impact on customers.  The technical group comes in, thinking they are ready to go, only to find out that there are many objections to their roll-out plans as well as requests for further testing and documentation.  The support staff are happy to have a say in the process, which they might not have had before, but the technical staff feel criticized and delayed.  As one technical person said to me, "It isn't a good idea to replace one unhappy group of people with another."

As a result, we have made several changes to our process.  The first change is to ask the technical staff to come forward earlier in the process, so that the concerns can be addressed during the development phase, rather than at the end.  The second change was suggested by one of our support staff, and it seems to be working great.  We have invited customers to join our Beta Bulldogs group.  We give them access to the new service early, ask them to help us test, and fold their advice and experiences into the further development of the solution.  This new process seems to be working just great so far.

Despite the growing pains with our Technology Coordination Meetings, I think we are already seeing the value of this new process.  Hearing concerns before we roll out new services, and involving the support staff in solving the problems, simply strengthens the final product.  And that is good for all of us.  Keep those lions coming.