Hunting for an Engineer
My latest book. (My previous was the Pikes Peak Trailguide)   This book is a hands-on guide to running a production line or any other business more efficiently. I used to be a manufacturing engineer and everywhere I worked I saw people doing dumb things. They'd talk about communication, maximizing people, and process improvements, but time and again they'd fail to deliver. Over the years, I saved up a lot of notes and stories about good ideas and bad implementation, until I had enough to tell a good story. There is nothing revolutionary here, just a light hearted look at theory and anecdotes about running a production a little more efficiently. The last chapter has tons of good ideas on how to improve your process improvement tools.

This book is available on Amazon.com, or download chapter 3 PDF here.
Amazon Page:   Go to Amazon.com
Chapter 3 PDF:   Download PDF

  Hunting for an Engineer

* Hunting for an Engineer

Mike Henry, Ghost Town Software
Edition 1, October 2016
ISBN-13: 978-1539093381
ISBN-10: 1539093387

* Table of Contents: *

Page . . 4 . . . . . Ch 1 - Maximize Communication
Page . 21 . . . . . Ch 2 - Maximize People
Page . 53 . . . . . Ch 3 - Maximize Managers
Page . 79 . . . . . Ch 4 - Process Control Stories
Page . 102 . . . . . Ch 5 - Process Improvement Tools
Page 143 . . . . . Appendix - References

About the cover: When you can’t afford a truck, you have to make due with what you have. But this might be going a little too far.

* Preface to the book: *

    There is nothing groundbreaking in this book. It is simply my observations and stories about businesses passing or failing on the three rules of execution that are listed below. Plenty of other books talk about these same ideas, but life in the real world is never quite as rosy as most authors want you to believe.
    And that is the difference here. These ideas are described with real-life anecdotes and examples that hopefully explain why these ideas don't always work the way people think they should.
    These stories and conclusions are simply my observations on the problems I've seen going on around me over the years. Most readers won't agree with all of these conclusions, but the goal is to get people to re-think similar events that they've seen in their own experiences. Sometimes a second opinion will trigger a deeper thought process that is ultimately useful.
    The stories and solutions in this book mostly take place on the various production lines that I've worked on over the years, but the lessons don't just apply to the production line, most of these ideas will work just as well in the office and at home.
    All of the stories in this book are true but none of the businesses are identified and all of the people's names have been changed.

* Introduction to the book: *

A few years ago, during one of our quarterly all-hands meetings, the VP asked us: " We had a hundred thousand dollars in process improvements last year, why don't I see a hundred thousand dollars more profit this year? "

This is an embarrassing question that gets asked by managers everywhere. Documented improvements don’t turn into measured improvements. He wasn't asking anyone in particular, but as a manufacturing engineer he could have been asking me. I thought about that over the years because I had been suspicious too. Even though the math added up on these improvements, I didn't really believe they would have the impact that the documents claimed.

It was just a gut feel and I couldn't really put my finger on it, but I knew something was fishy about their process improvement techniques and calculations of cost savings. Over the years I saw others making the same mistakes and listened to their horror stories, and I slowly realized what was going on.

Two things were happening. First, the labor hours on paper are not the labor hours on the shop floor. That might sound obvious but the reasons for the discrepancies are not obvious. Second, everywhere I've worked and from stories I've heard from others, the people on the shop floor are not being used effectively, negating a lot of the expected improvements.

There are dozens of books that describe process improvement techniques, some are very useful, and others not so much. Most of these books describe a lot of the same techniques but with their own personal twist. However, most are misleading about the effectiveness of these techniques.

For example, techniques such as 5-S and 5-Y are tools you can use to improve your workplace. They are not goals. The goal is to reduce cost and increase quality, and 5-S is a good tool to help you get there. Yet, the last few places where I've worked, they had put more effort into charting and enforcing 5-S than in verifying process improvements.

That's the point of this book. Businesses everywhere are doing a poor job of running their production lines and don't understand why they're struggling. The stories in this book describe a lot of those struggles as I've seen them over the years. Hopefully these are the same stories that people are seeing elsewhere, and will lead others to similar conclusions on their own production lines.

Books everywhere espouse their own particular theories on how to best run a business, but the bottom line in every case is simply: Execution. Somehow people will have to get the job done with efficiency and quality. Finding the best people to put in charge is a good idea, but to run a business profitably, your people will have to deliver regardless of who is in charge.

In the course of writing this book, I came up with three rules for running a business:
Rule #1: Open up the communication channels.
Rule #2: Find your best people and put them where they will do the most good.
Rule #3: Use process improvement tools effectively, according to cost vrs benefit.

These three rules are the theme through out this book, nearly all examples are based on an event passing or failing one of these rules. The stories and solutions in this book don't just apply to the production line, they work just as well in the office and at home.

Copyright (c) 2016 Mike Henry, Ghost Town Software