IE Lessons from Dr. Jordan Peterson’s Advice

While Dr. Jordan B. Peterson’s advice is widely applicable in a variety of areas, there are snippets that are particularly in line with industrial engineering principles.

  • Make at least one thing better every single place you go.

One way of describing the goal of industrial engineering is “better and better”. The definition of better itself is variable, whether you want it cheaper, faster, using less, or an improved design.


  • Tell the truth.

You cannot solve a problem if it is against the rules or culture to admit it in the first place. You cannot fix something if you aren’t allowed to share solutions or talk to those with the most knowledge about the issue.


  • Assume that the person you are listening to might know something you need to know. Listen to them hard enough so that they will share it with you.


One way to look at this is to give people your whole attention, because the little details and passing mentions may be the most important information … and it is what you’ll miss if you give them half your attention.

Another variation of this is how often people do surveys or solicit feedback only to skim over it, analyze it in aggregate and use intermediaries for what seems like the sake of efficiency.

Early in my career, a manager listened to my advice on solving a problem based on heavy theoretical reading. He replied, “If you want to find the solution, start with the people who are dealing with the problem.”

On one occasion, the seals were falling off a PCB board’s air ducts. I went down to the manufacturing shop, talked to a production head, and he put together a test of wash processes and adhesives on the seals. A line operator assembled the combinations of seals and adhesives on junk boards, we ran the lots through wash cycles, and we found the fatal combination. It took two hours. I returned to work in time for an engineering meeting, where I stood up to discuss the results. Most present had only started to consider how it might be testing. Asking the person with the most direct experience with the process resulted in an answer.

Many assemblers knew short term work-arounds that could be turned into permanent design solutions or had recommendations based on years of experience building, fixing and deconstructing the product. After several years in product development and production support, I was surprised to later find that many engineers were reluctant to talk to those on the shop floor … or even asked me to join in the meeting for my shop floor experience so they didn’t have to talk to the people doing the hard work.

  • Imagine who you could be, and then aim single-mindedly at that.

Burning platform, anyone?


  • Work as hard as you possibly can on at least one thing and see what happens.


Define progress for the moment – faster, leaner, simpler, more efficient. Then apply a fitting continuous process improvement methodology toward that goal. Re-evaluate and sustain the gain. Remember that you can shift the focus after you achieve a goal.


  • Nothing well done is insignificant.

Don’t denigrate small process improvement projects or modest gain in an area. We worship big projects, major wins, ignoring the fact that small, incremental progress can achieve the same or more and with less risk.

This same mentality is why politicians prefer big infrastructure projects over maintaining what’s already been built. Filling potholes and preventative maintenance aren’t as sexy as a new highway or overseeing a major equipment upgrade.


  • Remember that what you do not yet know is more important than what you already know.


It is the problems you don’t know about that are about to explode, hopefully not literally. It is the root causes you don’t realize are affecting your process that have the greatest impact on your quality.


  • Be precise in your speech.
  • Do not hide unwanted things in the fog.

I put these two together because of the tendency to use heavy jargon, whether it is in the hope of seeming more educated and thus justify one’s stance or in the misguided belief that if you rename something, the seriousness of it is reduced. The end result in both cases is confusion as to the issue involved unless you’re up to date on the jargon and often misunderstandings as to the severity of the issue. And sometimes people use the euphemisms and jargon fitting for a Dilbert comic to try to hide the severity of a problem.


  • Notice that opportunity lurks where responsibility has been abdicated.

Need ideas for a process improvement project? Look at the things others have given up on but really wish was solved.


Filed under: An IE in IT, iise

About the Author

Posted by

Tamara Wilhite is the IE in IT blogger for the IISE. She is a Six Sigma green belt with experience in IT, PDM software, the defense industry and recycling industries. She currently works as a freelance technical writer.