When I look back at interviews I’ve had with junior consultants, there’s one thing that’s consistent across those who ultimately became successful..
I recall one interview in particular. Half the interview was him asking me questions - basic ones.
“How does the client share requirements?”
“What does success look like for them?”
“When you say ‘configuration,’ what decisions are actually being made?”
No engineering degree on the résumé. But the instinct was there: understand how things work before trying to fix them.
That conversation stuck because it revealed a pattern I’ve now watched for years: the consultants who thrive think like engineers. Not because they write code or build bridges, but because their first instinct is to understand the system - end-to-end - before they touch anything.
“The best consultants don’t rush to answer. They map the system they’ve been invited into.”
Consulting still rewards fast answers. Whiteboard confidence looks efficient. It feels good in the room. But in ERP - where one checkbox can ripple through finance, operations, fulfillment, and reporting - speed without understanding is expensive.
I’ve watched smart people prescribe solutions before they’ve taken the vitals. Good intent, poor outcome.
Engineers are trained differently. When something fails, they don’t slap on a patch; they pull the thing apart until the “why” is undeniable. That habit - the refusal to guess about what they don’t yet understand - is the habit consulting needs most.
“An early sign of a great consultant: they ask clarifying questions without apologizing for them.”
Questions aren’t a stall tactic. They’re the work.
Most consultants learn ERP by implementing ERP: modules, settings, roles, flows, fixes. Useful. But incomplete.
Engineers bring something additive: they see systems.
They look at a business and immediately see inputs/outputs, constraints/trade-offs, dependencies/failure points. They aren’t interrogating for sport. They’re building a mental model sturdy enough to base irreversible decisions on.
“You don’t need an engineering degree to borrow the engineering mindset.”
Consultants guide. Clients own the picture.
We can’t sign off on whether a system mirrors the business. Only the client can. That means walking us through more than the happy path. Show the Tuesday exception. Show the end-of-quarter scramble. Show the “we just do it that way” step and let us ask why.
The best implementations I’ve seen share one behavior: clients invest real time up front explaining how the business actually runs, not how the doc says it runs. That “inefficient” time pays back at go-live and every day after.
“Be patient and explain how your business actually works, not just how it’s supposed to.”
Accelerators and templates have their place. They keep us from reinventing wheels. But wheels still have to fit the axle you’ve got.
Overreliance on templates tempts teams to force-fit reality into a pattern that looks great elsewhere. Curiosity resists that. Curiosity asks, “Where is this situation the same - and where is it definitely not?”
Curiosity doesn’t scale as neatly as a playbook. It scales better than rework.
Some folks preach the 80/20 rule: listen 80% of the time, talk 20%. When you actually do that, things surface that never show up in consultant-dominated conversations.
I listen for mismatches: three people describing the “same” process three different ways. A workaround that contradicts the official SOP. A report everyone distrusts but no one has replaced. Those signals aren’t technical problems. They’re clarity problems.
Engineers listen longer because they’re building models. You can’t model what you didn’t hear.
“Curiosity isn’t inefficient. It’s precision in disguise.”
One practice I use: explain a process like it’s mechanical.
Treat steps like gears and belts. When this gear turns, what must happen next? Where does energy leak? Where will tension build under load? Mechanical language forces specificity. It flushes out “it depends” answers that hide real rules.
When a team can see their business as a system, technology stops being a wish list and becomes a reflection. ERP should mirror reality, not pretend to improve it by ignoring it.
So what does the engineering mindset look like in the day-to-day?
For Consultants
For Clients
The consulting market is crowded. Platforms promise speed. Playbooks promise certainty. Amid all that, understanding is the scarce asset.
Understanding is slow to observe and fast to execute against. It keeps teams from local optimizations that break the whole. It grounds decisions when momentum tries to outrun reality. And it’s the one thing clients remember when they say, “You understood our business better than we did.”
If you’re early in your career and don’t have the engineering chops - borrow the mindset. If you’re a client choosing a partner - look for the ones who ask questions that make you think, not the ones who make you feel rushed.
Confidence has its moment on kickoff day. Curiosity carries you through go-live and beyond. Maybe that’s my engineering bias showing, but after two decades of ERP projects, it’s one bias that keeps paying off.
If you’re leading an ERP program - or mentoring the next wave of consultants - and you’re wrestling with this balance between speed and understanding, I’m always up for a conversation. The loudest voices rarely hold the best answers in this work. The curious ones do.
Let’s keep asking better questions.