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.

FICON on Z: LX or SX?

I recommend going with LX FICON cards on IBM Z systems.  There are technical vs. financial trade-offs that come into play and I’m not going to debate the issue in my personal blog.  But, as I say, my preference and recommendation is to go with longwave.

I understand the financial argument.  I also understand the technical considerations, the value of not making self-limiting moves, and the longer-term benefits of positioning yourself to better align with certain statements of direction.  I respect those who have a different opinion; I’m just looking at the problem in a different way.  I encourage my clients to go with LX, which most of them already do.


A Systems Philosopher?

It’s that time of the year when I think about what’s next.  What do I want to accomplish in 2018 and what do I need to accomplish?  What are my interests?  What are my priorities?

Do you ever find that your interests and your priorities don’t align very well?  I guess we all do.  That’s certainly my situation at the moment.  It’s one of the challenges of life, of course.  You have to make choices – trade-offs – and that’s not always easy.

I don’t have the answers, yet.  I know that I’d like to have more time to dig deeper and deeper into complexity and chaos.  Yes, I’m serious.  I suppose I’m more metaphysician than anything else.  If I could have made a living as a philosopher, that’s what I would be doing.

I’d also like to experiment with AI, just for some personal applications.  And, in general, I wish I could get back to doing more programming.  It’s been a long time since I’ve done that.

I’d also like to have time to do some writing, especially on professional development and consulting.  And I’d like to bring out a new version of my Effective Speaking book.

The desire to learn, apply, and teach is part of my nature.  Teaching is one of my question marks, though.  I have always enjoyed teaching, but, honestly, I seem to enjoy it less now.  Maybe it’s because I simply need to teach new things.  Or maybe it’s that, to me, technology has depersonalized teaching in the same way it seems to depersonalize everything else.

Then, there’s my profession – systems engineering.  It pays most of the bills and keeps me at the center of complexity (and always on the edge chaos).  It’s also “who I am” and “what I do.”  I’ll miss it when it’s gone.

How do I bring these disparate things together into a meaningful whole?

If only I could be a systems philosopher.

Trading Off Capabilities

My experience has been that net expense reductions in a mature organization almost always result in a loss of longer-term operational capabilities.  They rarely produce a net efficiency improvement.  Usually, there’s a corresponding reduction in value, quality, or capability.  It’s a trade-off.  The key is whether you understand the trade-off or not. If you understand it, fine.  But if not – if it manifests itself as an unintended consequence – then not so fine.

I saw an article recently in the Navy Times that captured the same idea.  I’ll post the link below, but here’s the paragraph that really caught my attention.  It’s an excellent example of what I tell my students.

From: https://www.navytimes.com/news/your-navy/2017/12/14/new-secnav-report-criticizes-navy-culture-and-top-brass-decisions/

“However, the cumulative effects of well-meaning decisions designed to achieve short-term operational effectiveness and efficiencies have often produced unintended negative consequences which, in turn degraded necessary long-term operational capability.”


Generic Planning Checklist (Part 2)

This post is a continuation of the sample checklist I introduced in my last post.  Let’s look at items 8-14.

  1.  Hardware Configurations
    • All devices and features supported?  Any compatibility issues?
    • How was hardware configuration validated?
    • Correct quantity and types of adapters, cables, and connectors?
    • Correct power, plug, and receptacles configured?
    • Firmware or microcode levels correct?
  2. Software Configurations
    • All components at required version and level?
    • Any maintenance to apply?
    • Have new products been properly licensed?
  3. Network Configurations
    • Any network address changes?
    • Any required firewall changes?
    • Connector and cabling components in place?
  4. Support Plans
    • Warranty understood?
    • Maintenance agreements in place?
    • Procedures documented for obtaining technical support?
  5. Service Offerings
    • Contract services required?
    • Agreements (contracts, SOW) in place?
    • Scheduling completed?
  6. Systems Management
    • Backup/recovery plans in place?
    • Problem management processes understood?
    • Change management processes understood?
    • Availability management process understood?
    • Newly required tools in place or on order?
  7. Equipment Removal or Disposal
    • Any components or parts to be returned to a 3rd party?
    • Understand who handles packing, delivery, and transportation costs?

As I said, this is a sample of a generic checklist.  It may seem like a list of obvious things.  If so, that’s good.  That’s the purpose of a checklist like this.

As Dr. Gawande says in his book, the function of a checklist is to be sure you get the “stupid stuff” right.




Generic Planning Checklist (Part 1)

Checklists are a useful tool for verifying your readiness to move from one phase of a technical project to the next.  I realize that’s not exactly a news flash, but it’s something worth repeating occasionally.  That’s why for a number of years I required my students to read The Checklist Manifesto: How to Get Things Right by Atul Gawande.

As an example to my students, I present a somewhat generalized, 14-point checklist in my courses.  It’s patterned after the more elaborate checklists that I use when I’m actually implementing an enterprise system within my area of specialization.

I’ll list the first seven points in this post and the remaining seven in the next post.

  1. Expectations
    • Are performance expectations understood and documented?
    • Will the system meet performance expectations?
    • How were performance expectations validated?
  2. Resources
    • Are all appropriate resources involved in the planning and implementation activities?
  3. Responsibilities
    • Do all parties (management, staff, vendors, consultants) fully understand their responsibilities?
    • Are required contracts signed?
  4. Education and Training
    • Does the project team have the necessary skills?
    • Are there technical classes or training sessions that should be scheduled?
    • Is end user training needed?
    • Do operations personnel need training?
  5. Installation Plan
    • Is an installation plan in place?
    • Are key dates and milestones identified?
    • Has the plan been reviewed with all parties?
  6. Shipment and Delivery
    • Are product ship dates and delivery dates known?
    • Are there special requirements for delivery?
    • Any specific security/access issues?
    • Any loading dock issues?
    • Identified the contact person for delivery communications?
  7. Physical Site Preparation
    • Power, cooling, cabling, floor space/rack space requirements met?
    • Physical access issues?  Elevators?  Site walk-through required/completed?
    • Site planning checklists reviewed and completed?

Zero to Many to One

If you’ve taken my courses, you know I say this a lot.  This is just a reminder.  The solution development process unfolds in a way that takes you from zero to many to one.  You have a design problem.  You start, in theory, with no solution.  You end up, ideally, with one solution.  In between, you generate and evaluate multiple possible solutions.

Sometimes, in our eagerness to “solve the problem,” we are too quick to say “okay, those are enough possible solutions.”  I think generating possible solutions is half the fun because that is where you get to be creative and innovative, exploring new possibilities and maybe taking a fresh look at some typical problems.  If time allows, use the opportunity to say: “Okay, that’s great; but, now, let’s try it this way.”