Not every consultant is an engineer and not every engineer is a consultant. So how should it be? One could agree that a consultant does not have to be an engineer — but in certain industries it would help to be one. At the very least: to be able to describe a process. To present it graphically and to explain it with numbers. But let's start with the question posed in the title.
01 WHAT SETS A CONSULTANT APART FROM AN ENGINEER?
The engineer seems more focused on his own process — he knows every corner of it, he knows what happens on the production floor and why. But could an engineer be an external consultant? My thesis: absolutely yes. Everything comes with time — but time is not the only thing that matters. So what does? I'm thinking of plain curiosity, the urge to understand the whole, to see the wider perspective. The consultant tends to go broader in what he does. He looks at the process holistically. The engineer more often digs into one narrow thread. It doesn't have to be a rule, but it's certainly one of the differences I see. The fact is, an engineer is not — and will not be — a consultant as long as he sits on a payroll with a narrowly assigned role of the engineer for this-or-that, because that would simply be hard to pull off.
But what connects the two roles? Because plenty does. Well, maybe not that much, but something certainly does. One of those shared traits is basing your analysis on data, on numbers, on facts. So we have facts — common ground where both professions operate every day. Before we establish the facts and base our conclusions on data and observation, though, we need the motivation: why are we doing this at all? And here, I think, we have one of those differences that really shouldn't be a difference. The problem is the starting point for both professions. Do both roles solve problems? By design they should — that's what they exist for. I'd venture to say the consultant works broader, more process-oriented, while the engineer directs his efforts into technology, measurement or design matters.
02 CORPORATE LIFE STRIPS THE ENGINEER OF HIS BEST TOOL
Here again I have my thoughts on how inefficiently the engineer's role is used in the corporate world. People holding engineering roles in companies often don't start by describing and establishing what the problem actually is — they get dispatched to tasks, stripped at the outset of the most important tool they should be using: autonomy in acting and in making decisions. Today's organizations have surrendered far too much of that ground to all manner of managerial functions — but that's a topic for another day. Autonomy in action, and the ability to state what the essence of a problem is and how to tackle it — that is one trait which, sadly, separates today's consultant and engineer roles. And it shouldn't.
03 TEAM SPORT OR SOLO WORK?
Which role is more of a team sport and which is individual? Both require working with people — the consultant perhaps even more. I'd say the engineer sits deeper in data and analysis. Then again, that's not entirely true either. Both functions, when performed at a high level of quality, will certainly meet that bar. Nevertheless: the consultant is more of a workshop with teams, while the engineer is individual work.
04 BACK TO THE CRITERIA FROM THE OPENING
There are industries where analysis, facts and data are the ingredients without which organizations do not survive. Manufacturing is one of them. On the shop floor you advise on something that physically exists: machines, material flows, people working to takt. Here you cannot "consult" with buzzwords alone, because the process instantly verifies every thesis. If you advise a factory, you don't need an engineering diploma. What you need is to think like an engineer. And in practice that means one thing: you must speak the three languages of the process.
05 THE THREE-LANGUAGES-OF-THE-PROCESS TEST
Over the years I've developed a simple test I hold myself to on every project. A manufacturing consultant must be able to do three things with a client's process.
First: words. A description from raw material to finished product, operation by operation, with boundaries of responsibility and decision points. Is that an engineering approach? Indeed it is. And it cannot be skipped, because it rests on a method — the software you switch on in your head the first time you see a process. You have to truly see it. Every operation: cutting, bending, assembly, welding, grinding, inspection, testing, packing. You have to know it, feel it — who, what, after what, and why? If someone cannot tell the story of a process in simple sentences, they don't understand it — they've merely heard of it.
Second: draw it. Value stream map, flow, layout — the form is secondary, but the drawing is merciless. On a slide you can hide ignorance behind a pretty framework; on a process map you can hide nothing. Either you know where the buffer stands and why, or you don't. The drawing is the moment the production manager starts nodding — because he sees his own floor, not a template from the internet.
Third: prove it with numbers. And this is the language that ultimately separates advisors from presenters. Take a typical eight-station line: the takt derived from demand is 118 seconds, while the slowest operation — welding — needs 181 seconds. Which means the line flows at the pace of its bottleneck and loses 63 seconds on every part. Out of a target of 480 parts a day you get 380. Add the downtime Pareto: the top two categories — micro-stops and changeovers — account for nearly two thirds of the losses. At this point the conversation stops being a debate of opinions and becomes a conversation about facts. Numbers have no charisma, but they are right.
06 ADVISOR? I PREFER EXPERT
For sure, every engineer and every consultant should have fun doing what they do — otherwise I can't imagine this job. We know, however, how it usually is. What the engineer in today's corporate companies does — or doesn't get to do. That's why it's easier to have fun being an advisor :). Which brings me to this: is "advisor" even a good name for the role? It doesn't grab me. I prefer expert. Sounds more serious, and it carries the weight of the subject.
07 DO YOU ALREADY HAVE A CONSULTANT ON PAYROLL?
And here we arrive at a conclusion that may not be popular. Many companies pay external consultants for something they could get from their own engineers. The condition? You'd have to give them back what was taken away at the start: autonomy, the right to make a diagnosis, time to understand the problem instead of chasing tasks. An engineer who is handed a problem — not a task — starts behaving like a consultant. He starts asking, drawing, counting.
So before you hire a consultant, ask yourself: don't I already have one on payroll? He may be sitting three desks away, waiting for someone to finally let him act. And the external consultant? He stays where a fresh eye and patterns from other factories are needed. So he doesn't disappear at all. Only the proportion changes.