How to succeed in the creativity game! Six proven strategies.

I will show you six time-tested, can’t miss, strategies for dominating any discussion on creativity.

However, I won’t be showing them in this post because this post is actually part of a study I’m doing about attracting more blog traffic using absurd titles constructed using a simple formula.

So I hope you will excuse my involving you in this experiment, but it’s for a good cause.  I’d like to develop a search filter that filters these things out.

I’ll try to remember to post the strategies sometime.  I actually have some ideas.  But, proven strategies shouldn’t be hard to find, right?  If they exist?

Be careful about believing what you read.

Books I Recommend

I am occasionally asked to recommend books – good books – for those who are pursuing certain areas of study or who are interested in developing certain sets of capabilities.  I try to always provide a thoughtful answer.  There are certain “go to” books I routinely recommend to help others improve their speaking or writing skills, or learn more about history, or economics, or science, or philosophy, or theology, for example.  And, of course, I have my favorites in the areas of systems engineering, systems architecture, complexity, chaos, and artificial intelligence.

But I am now considering a hypothetical problem: What books would I recommend, not simply to develop a skill or learn more about a particular subject, but to begin the process of developing a rational framework for the better understanding of everything? Let us say that I must limit myself to a handful of books currently on my shelves – for I might otherwise point one toward a Great Books curriculum – and these books should be, in a sense, first books, not ultimate books, that are nonetheless sufficiently engaging intellectually to introduce you to lines of thought that might ultimately lead you to pursue studies at a yet higher level.  And, the goal is that, upon completing the recommended books, you might truly say “this has made a difference in my way of looking at the world; I now see some things in new and important ways.”

What would I recommend?

1. The Structure of Scientific Revolutions by Thomas S. Kuhn

2. Strategy: A History by Lawrence Freedman

3. The Road to Serfdom by F. A. Hayek

4. The Abolition of Man: How Education Develops Man’s Sense of Morality by C. S. Lewis

That is where I would begin.

Back to Consulting

So now it’s time for me to change course.  Going forward, my primary focus will be teaching consulting skills.  I’ll be developing training resources to help other people strengthen their own skills.  This is something I truly enjoy doing and I’m headed back that way.  Whether this blog plays a role or not remains to be seen.  But I have crossed the Rubicon (again).

Teaching and Complexity

In my previous post, I described the “complexity barrier” that makes certain types of teaching ineffective (unless, of course, it’s just me).  I then asked what could we do about it?

As a teacher, I believe that one of the key parameters in training a student to do complex things is to allow for continual course corrections.  Define small, meaningful steps that require the student to begin to reason his or her way through the “fog of complexity.”  Let them experience the unknowns; that will prompt the important questions. Let them struggle to make sense of the complexity; that will promote a healthy humility.  This is what truly prepares them to learn.

Then, have them talk through the experience, engage in dialogue to refine their understanding, reinforce their successes, and reflect on the challenges that remain.

It’s best done one-on-one or in a combination of one-on-one discussions and very small group discussions.  It’s seminar style learning, in one sense; but it’s also coaching and mentoring and personal instruction.

I’ve concluded that the goals I’ve set for certain courses cannot be achieved in the typical course environment of the day.  They cannot be achieved by reading a book and taking a test.  They cannot be achieved by working in teams.  They cannot be achieved by watching short videos.  They cannot be achieved without the student taking risks and making mistakes.  They cannot be achieved if the student is not passionate about the subject area.  They cannot be achieved if the goal is merely to obtain a degree.  And they cannot be achieved without mutual trust and respect.

Within industry, this kind of transformational learning is fairly well understood (though perhaps not practiced as much as it had been at one time).  I’ve experienced it at its best.  I know what’s possible.  But, as an instructor, I simply don’t see how we can replicate that without major changes in priorities and approaches.

So, I share that opinion with you.

The Complexity Barrier

Be forewarned, I’m going to speak bluntly in this post.  I’m not trying to hurt anyone’s feelings; I just want to make a point.

There’s an interesting phenomenon I’ve encountered the last few times I’ve taught a certain course.  I’ve given the students a poorly-defined problem with minimal guidance on what I’m looking for and then have asked them to build an organization and a process to solve the problem and then bring me a solution.

Do you know what I get?

I get a project management structure – because, I believe, that’s the only way they know how to organize themselves.

I get requests for more information, even though I’m the one asking them for more information.

And I get unhappy students.

Do you know what I wanted to get?

I wanted to see them self-organize into, essentially, an R&D structure.  I wanted to see discipline, confidence, critical thinking, logical analysis, exploration of the unknown, trial and error, testing, discovery.

What happened?  I think there’s a barrier, what I’ll call a complexity barrier, at which our students falter.  They expect to be given sufficient information to solve the problem and they assume that what they need to do is work together as a team to apply the information to solve that problem.  I also think they perceive the purpose of a team to be an opportunity to learn to work in teams.  But I want explorers… teams of explorers.  Not explorers who are learning to work in teams.

Results count.  Teamwork does not count unless the teamwork produces results.  Teamwork is not a goal, it’s a method.

But, back to the complexity barrier, I think many of them don’t know what to do when confronted with a problem that appears too complex because of the quantity of unknowns.  They balk at that.  They fear failure (i.e., not getting an “A”).  They give up.  They shouldn’t, but they do, because we’re not teaching the right mindset.  We teach them to do simple things and we teach them to do complicated things, but when we push them to do truly complex things – things with many unknowns and not easily discernible rules and no clear definition of success – they don’t see a way forward, they begin to contemplate failure, and they either stop or they just go through the motions.

So how can we fix this?

Four Teams

I’ve been thinking about teams recently.  There are a number of reasons why.  It would take multiple posts to explain it all, if I even decide to go there, and I probably won’t.  But a few minutes of recollection reminded me of four very different, and significant, team experiences I’ve had professionally.

Two of the teams were part of new hire training.  We did not know one another.  We did not choose one another.  We were simply grouped together and told we were a team.

This first team was, in one sense, a team, but only by definition.  In another sense, an important sense, it was not a team at all.  Let’s describe it as a “nominal” team.  This team was a failure from the very beginning because certain members pursued a strategy of intentionally embarrassing other members in front of management, making their teammates look bad in order to promote their own interests.  The result was complete failure, at least from a team perspective.  (Whether it ultimately advanced anyone’s personal career, I don’t know.)

The second team, also nominal, was also a failure.  The failure resulted from the team being factional and quarrelsome from the very beginning.  It essentially split into competing sub-teams and success was never achieved.

That leaves two other team experiences, and they were extraordinary.

The third team evolved naturally.  We knew one another.  We had worked side-by-side for many years.  We gravitated toward one another and developed friendships.  We had total trust and confidence in each other.  Each of us was competent in the complex technical things that we needed to do, but each member also had their own highly-specialized areas of expertise that made us significantly more effective working as a team – fewer problems, faster resolutions, flawless execution. I think back often about the privilege it was to work with Valerie and Johnny.

The fourth team also evolved naturally, but in a different way.  I was with a new company, returning to a technical role after five years of doing something more staff-related.  My new situation was a little different organizationally.  There were fewer of us, working from our homes, scattered across a large geography.  But, over a span of time, I again had the privilege of working with two amazing teammates, Jane and Van.  Interestingly, I think the thing I valued most about this team was the friendship and support.  It was often the peer-to-peer dialogue, the mutual understanding of the challenges and complexities we were facing, that was most valuable.  Basically, we could rant to one another as needed in order to reduce some of the stress.  But they also had great strengths in their areas of specialization.  I benefited from that while, honestly, offering them very little in return.  That team dissipated late last year and there is not a day that goes by that I don’t reflect on what great teammates they were.

z/VM and Linux support considerations on an IBM Z System migration

Most of my clients are z/OS customers, but quite a few of them also run z/VM and Linux on their mainframes.  When planning for an upgrade to a new processor, be sure you don’t overlook z/VM and Linux in your migration planning.  It’s important to be sure that all of the installed operating systems are at a version and release level that supports the incoming machine type as well as any new functions that are release dependent.

(Part of the systems assurance process is to identify the version and release level of all installed operating systems and compare that to the required versions and releases for the new processor, so this topic should be covered during the pre-install Technical and Delivery Assessment or TDA.  But, that’s really late in the planning process in most cases, often just prior to shipment of the new machine.  Sort of late to discover you need an OS upgrade, right?  Check it out early.)

Here is a link to review z/VM support for Z System servers. (Scroll down a bit when you get there.)

IBM Servers Supported by z/VM

Since Linux is not an IBM product, you must seek guidance from your Linux vendor on recommended release levels.  IBM does have a link that provides information on which environments have been tested.

IBM Tested Linux Platforms

Also, though there’s nothing imminent, here is a link to the “end of service” dates for IBM’s z/VM operating system.

VM End of Service Effective Dates