IE Lessons from Dilbert, Part 1


I remember a story from and by Scott Adams, creator of Dilbert, about the language shift of the 1990s. Many of the buzz words for management trends shifted to clearer and more pragmatic terms, as one manager said, they were uncertain who was feeding ideas to Dilbert and were afraid that what they said in the meeting would be mocked in the next comic.

I’ve found a number of lessons for industrial engineers from Dilbert. We’ll start with the titles of some of his latest books.


“I’m No Scientist, But I Think Fung Shui Is the Answer”


Just because you know of a management fad doesn’t mean it is applicable to your situation. And applying it may be counter-productive.


“Optimism Sounds Exhausting”


Too many managers and employees focus on looking good instead of doing good, assuming that if it looks good, it is good, and if you make it look good, you’ll magically cause others to do good. When you focus on the appearance instead of the reality, you may end up letting a bad situation get worse. And the time spent maintaining appearances instead of honestly assessing the situation and correcting it is never value added.


“Go Add Value Somewhere Else”


Dr. Jordan Peterson said that more than half of management activity is not value added, while a fraction of what remains is actually counter-productive. If the team is trying to cut the manager or a team mate out of the process, the likely answer is that they person is counter-productive in some way. And it may be a good idea to find somewhere else for them to add value, especially if the time and effort of trying to resolve the conflicts or mistaken beliefs get in the way of getting work done.


“Your New Job Title Is Accomplice”


If someone is asking you to alter the data or recommendations to suit an agenda, be wary of their motivations and the end results. If the request comes with demands for secrecy, barring actually having a government security clearance, the best answer is “no”.


“I Can’t Remember If We’re Cheap or Smart”


This conundrum comes up in a variety of ways. If you set a small budget, you may find creativity and productivity finding ways to use the resources you have instead of the default action of buying new and starting from scratch. Set a budget too small, and you’re almost setting people up for failure or fraud. Or you end up with high technical debt and burned out staff working unpaid overtime. That’s just another recipe for failure.


“Team Work Means You Can’t Pick a Side That’s Right”


The book “The Wisdom of the Crowds” discussed how a general consensus generated by open discussion without extra weight given to any person or group was more accurate than even an educated guess by experts. One issue I’ve seen in modern life is the increased deference to people with multiple credentials though their expertise may not apply to that situation, skewing the results. Another mistake is “we’ve hammered out a consensus by hammering on the holdouts instead of trying to resolve root causes of their concern, now the team is right, do what we say”. This situation creates people who are more likely to not really give their all for the project, since the consensus is false, and your project risks failure because you poo-pooed their concerns … too often because a key person says optimism and emotional investment in the vision overrides risk management. Until the project fails.


“Your Accomplishments Are Suspiciously Hard to Verify”


This maxim is embodied in the default presumption that statements with statistics are more correct and honest when it includes statistics. Reports with statistics and resumes citing numbers have more gravitas with the reader than generic platitudes. Just be ready to back it up with real data when someone asks for more evidence, because 90% of statistics are made up on the spot, including this one.


“Problem Identified, And You’re Probably Not Part of the Solution”


If someone gave that statement in a private or public meeting, the biggest problem with it is the failure to be directly honest. If someone is making mistakes while training, don’t ignore it and hope it improves, but send them back for more training or team them up with a mentor to figure out what they aren’t doing right. If someone is failing to live up to performance requirements of the job, ask why. It could be lack of resources, lack of support, a mismatch between job requirements and skills, a personality mismatch relative to the ideal fit for the job or a change in personal circumstances.

I personally ran into times where the drop in productivity was because training on a new software system didn’t cover what people needed to know, and instead of lecturing people for not reading the manuals, I created job specific (and short) references so that people knew what to do for what they had to do. Saying that the problem was the shop floor personnel or giving generic criticisms of the software didn’t solve the problem. Identifying the root cause and then working with people to solve it was.


“This Is the Part Where You Pretend to Add Value”


Per an IISE magazine article a year or so ago, implementing basic management practices like inventory management, basic quality checks and inventory control reduced waste and improved productivity for poor Asian businesses about 10%. Simply not ordering things on a monthly basis but checking to see if you had some in stock first improved their profitability. In this regard, management can increase productivity and quality.

Unfortunately, management in business is another form of administratium, the element that is the only one in the known universe that increases its mass by adding new layers and attracting more elements like itself until it is unbearably heavy. Organizations have to be mindful of the tendency to add administrative controls, layers, and bloat. Streamlining production is a start, but streamlining the administrative processes and actually reducing the need for administrators is even more important. Sometimes the first step is reviewing one’s processes when there is an error or disaster and implementing a solution other than yet another administrative check.

Nor do I think this is mere theory. I improved process control and IT manufacturing flow in one department to the point I was redundant; that’s when I moved to formal IT.


Filed under: An IE in IT

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.