A Focus on Consulting Skills

I began IEM 630 (Systems Engineering) this term with a strong initial focus on basic consulting skills.  It’s a useful way to help my students develop a mindset that they are not just “learners,” they are problem solvers and problem owners.  In a sense, it personalizes the subsequent course content.  It makes the material “about them.”  Or so I hope.

As I told them on the first day of class, the point of all this is to give them the knowledge and confidence to take ownership of any technical project at any stage of its life-cycle and manage it effectively.

It also moves our overall focus a little more toward systems engineering management – which is exactly where I want us to be.

The Enigma of Creative Processes

One objective of a business process is to perform a business activity in a standardized, repeatable way that provides consistent results with minimal management intervention.  And many managers take that very seriously.

“Just do it the way we tell you to do it.  Don’t get creative.”

I speak from experience in telling you that getting “creative” can cause consternation for your manager, irrespective of the results.

“Do not work outside the process.”

But there are some activities that simply do not lend themselves to this sort of process-driven logic.  For example, I once had to document my process for solving technical problems for customers whose mainframe systems were down in the middle of the night and could not be fixed using standard 1-800 number methods.

I balked.  It was like asking me how I cooked Chinese food.  Well, I never do it the same way twice.  It’s NOT A PROCESS.

I finally yielded and described my “process:”

  • I arrive at the account.
  • I ask them what the problem is.
  • I ask them to show me the mainframe.
  • I fix the problem.
  • I tell them I fixed the problem.
  • I leave.

That’s a pseudo-process.

My experience has been that tasks requiring creativity and innovation benefit only marginally from “processes.”  Processes have their strengths without a doubt, and they are numerous and real.  But driving creativity and innovation is not one of them.

Engineering and the Humanities

Let’s consider for a moment things like art, music, literature, history, and philosophy.  These disciplines or areas of study are often described as the “humanities.”  (We could add others.)

What they have in common, in large measure, is that they reflect ways that we humans express ourselves about what the human experience is like.  We draw pictures or sing songs or write stories or poems or histories or thoughtful reflections about life in all of its manifestations.  (Is this not the ultimate in unstructured data?)  The study of the humanities provides valuable intellectual balance.  It shows us the world through other’s eyes.


10 Practical Ways to Manage Complexity

Managing complexity is one of the central themes in my systems engineering course.  In one of my lectures, I offer ten practical suggestions for managing complexity.  The list isn’t exhaustive, but these ten ideas usually provoke some interesting discussions.

  1. Improve Communications
  2. Verify and Document Assumptions
  3. Instill a Culture of Thoroughness
  4. Simplify Where You Can
  5. Establish Quality Assurance Processes
  6. Manage Risks with Accountability
  7. Understand the Value and Risk of Decomposition
  8. Understand the Value and Risk of Abstraction
  9. Exploit the Use of Hierarchy
  10. Maintain a Systems Perspective



Overcoming Speaker’s Anxiety

For me, the secret to overcoming anxiety about public speaking is to remove myself from the equation.  It’s not about me – it’s about my message.  It’s that simple.

Here is why I say this.

I believe that the fear of public speaking is rooted in one (or more) of three things:

  • You think you have nothing worth saying.
  • You think you will embarrass yourself.
  • You don’t like being the center of attention.

Those are legitimate concerns. There’s nothing wrong or unusual about feeling that way.  But it’s only one side of the equation.

Just as there are reasons that cause you to prefer not to speak, there are also reasons that can convince you – even compel you – to speak. The two forces are held in tension, and it takes only a small change in those forces to tip you in one direction or the other.

What I am saying is that, as reluctant as you may be to speak in front of a group, there are circumstances that would prompt you to run to the front of the room and speak, even if it meant interrupting someone else.  Suppose, for example, that you had just received a text message that a massive tornado was approaching the facility and that everyone needed to seek shelter immediately.  Would you keep it to yourself out of fear of embarrassment?  I don’t think so.  Would you think it worth disrupting the event in order to warn others?  Of course.  People should be warned about the danger.  The message would be of enormous importance.  You would know that and you would act.

I’ve given you a dramatic example, but there is a lesson we can draw from this that applies even in less dramatic circumstances.  When it comes to public speaking, just remember that it’s not about you.  You are simply there to serve, to add value, to be the messenger of something worth saying.  That takes the pressure off.  It takes you out of the equation and puts the focus on the message itself.  For me, that changes everything.

Now, I concede that there are times when we may be required to speak, even though we have nothing significant to say.  In an academic setting, for example, you might be given an assignment to make a presentation or give a talk on some arbitrary topic.  Those can be challenging moments because the circumstances are artificial.  My advice, once again, is to remove yourself from the equation.  Find something about that topic that will enrich your audience. Tell them how the information you’re sharing with them may be of value, even if it’s simply to entertain them or encourage them.  Be positive.  Serve them in some way.

Systems Assurance for Emerging Technology

I’m a Systems Engineer who specializes in enterprise system design and implementation, but I also spend a considerable amount of time doing technical sales.  I work continually with new, complex, innovative products and technologies.  I get involved at an early stage in the product lifecycle and I get to participate in the product launch and rollout into the marketplace.

One of the challenges you face with the rollout of emerging technologies is that the level of experience and expertise is initially somewhat limited.  It takes time to scale up.  There are experts – but it takes a while for the expertise to spread throughout the organization.  Everybody is on the front end of the learning curve at first.

Because of that, there is a bit more risk doing system design at this early stage.  Experience, while growing, is still limited.  Feedback from the field is gathered and analyzed, but it often accumulates slowly.  Then, there is the unexpected.  Not all of the inevitable surprises are discovered on day one.

So there’s some extra risk to be managed.

An effective way for a technology vendor to address this is through pre-sale solution design reviews.  Complex designs at the beginning of the lifecycle need to be reviewed.  In my industry, it’s part of a process traditionally known as systems assurance, though it has gone through some name changes over the years.

One key to having an effective design review process is to understand the kinds of issues that emerge from the design reviews.  To get the most value from the reviews, you need to constantly improve the process itself.  A starting point is to know the kinds of issues that surface in these meetings and the frequency with which they are encountered.   You need to know what to expect and to have the methods and tools in place to solve the issues effectively.

Building Teams of People (and Machines?)

The way I build a human team depends upon the purpose of the team.

Sometimes I need a team with skills nearly-identical to my own.  Sometimes I need a team with widely varying skills.  Sometimes I need a little bit of both – I need subject matter experts with deep knowledge in a specific area who also have other skills and insights acquired through different professional experiences.

Sometimes I like to include a totally new perspective – perhaps a new hire or trainee or novice or someone from an entirely unrelated discipline because they may see things in a way that the rest of us can’t see or ask a question that the rest of us wouldn’t ask.

Would I do the same things if I were building teams of people plus machines?  For example, would I select multiple machine-learning systems that were written by different programming teams and that implement differing algorithms in order to gain diverse machine insights?