My Teaching Journey

I’ve recently been reflecting on my teaching career.  I started teaching in the engineering school about fourteen years ago.  The first course I taught was an undergraduate engineering course on engineering computation.  The focus was on using Microsoft Visual Basic and Microsoft Excel to solve basic engineering problems.  It was a great opportunity to do something different professionally.

My next course was a graduate course in operations management.  That was a nice fit, given my background in operations research, mathematical modeling, and simulation.  I taught that course for several years.

I added a couple more courses shortly after that.  One was on computer networking and the other was on computer security.

There came a point where we began to steer our master’s degree program more toward technology management and entrepreneurship.  I reworked the operations management course to become a course in the management of technology.  That quickly became my favorite course to teach.

From there, I spun off a course specifically on technology and innovation, with the emphasis on innovation.  I also developed a special topics course on professional communication for engineers.  That’s a long story; it was built around my own personal experiences of being a person who was always uncomfortable speaking in front of an audience, while being someone who has to do that all the time.  That’s when I wrote my book, Effective Speaking: An Introvert’s Guide to Making Presentations.

In the last few years, my courses have been centered around systems engineering and engineering management.  I’ve been a professional systems engineer for over forty years, so that’s my niche.  But I’ll tell you, that’s been a tough subject to teach.  I’ll save that story for another time.  On the engineering management side, I’ve been teaching what is essentially “finance for non-financial managers” and strategic planning (with a deliberate focus on teaching IT-industry technical professionals how to better understand the problems of alignment between business and technology workers).

It’s been an interesting journey:

  1. Engineering Computation
  2. Operations Management
  3. Computer Networking
  4. Computer Security
  5. Management of Technology
  6. Technology and Innovation
  7. Professional Communications for Engineers
  8. Systems Engineering
  9. Financial Concepts
  10. Strategic Planning

What will I be teaching going forward?  Anything new?  I’m not sure.  One thing I’d like to do is develop a course on consulting skills and methods.  Another idea is a course on technology sales and technical sales support.  I’d also like to revise and update my course on professional communications, which could easily be part of the consulting skills course.

I’ve also considered starting a “professional development” consulting business to bring some of these important topics to a broader audience.  I ran my own consulting business for a number of years and it was a satisfying experience.   It’s also a great way to serve if you can help others develop their professional abilities and do it for a nominal charge.  There’s more to this story as well.

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.