In consulting, part of the job is often to be seen as smart. After all, that is what customers are paying for—smart, competent individuals and teams that can help solve their problems.
And that expertise costs them quite a bit—so they should get what they are paying for, right?
Well, as anyone who has done this job for a while might tell you, sometimes doing things that seem smart, competent, educated, professional or technically knowledgeable, even though they are beneficial in itself, can end up being detrimental to the end project’s result.
Nassim Taleb surmised a similar thought in his latest book in a quote:
When you come to a doctor with a headache, he’ll probably recommend an aspirin, not brain surgery—even though the second one seems more ‘scientific’.
The consulting business is one where this can easily happen, although unlike in a medical setting, not so obviously.
Very often we might see overly combined, complex tools, processes and models, or meetings on top of one another, discussing areas only vaguely related to what the process is really trying to achieve.
One instance of this I keep encountering is:
- Do I spend hours researching and documenting 2 solutions, comparing them them, giving detailed cost/benefit analysis and a professional recommendation…
- or do I show a quick demo of how each solution looks to the people who will be actually using it and ask them what looks better, making tweaks as we go?
The second option being almost always better, quicker and oftentimes more useful.
Sure, sometimes, the complexity is necessary. Sometimes, it’s just a function of the size of the project—the amount of different people and needs in a project oftentimes requires that kind of complexity. In our example, it would mean that the solution has many users with different needs, which would need a longer investigation to decide what’s best—something that can’t be solved on the fly.
However, it should still be the goal of every consultant to try to present and manage even such requirements as simply as possible—without hiding behind complicated models and being rewarded for it even when these models end up being (although pretty looking and competent seeming) an overly complicated mess.
Experts with a narrow focus especially can bring a lot of complexity in small areas, while if you’d talk to the end user, he’ll have a very simple and clear idea as to what needs to be achieved and will be able to give a much better idea of what the minimal requirements would be.
Even though there is nothing necessarily wrong with “seeming professional” in and of itself, I believe the looks should come second after results. And I often saw the most actual progress, when the ‘mask’ of professionality was briefly dropped, with the right people at the right places…
In times when jargon and technicalities were abandoned and language considerably loosened, the discussion proceeded completely differently, without the worry for formality and politics, but with a focus on what was important and over needless clutter.
What to do about it
One antidote that promises improvement is Agile—trying to go one step (or sprint) at a time, avoiding unnecessary administration where possible, cutting requirements down to the bone, delivering the simplest MVP and slowly working up from there, dividing responsibilities and simplifying communication.
But as with anything, it’s not a cure-all. Even with Agile (done wrong, mind you), you can plan the backlog for months ahead. You can spend weeks of time on analysis (sometimes correctly, to avoid issues in the future). Plus an inexperienced team may end up ‘drowning’ in the Agile rituals and wasting time, doing what they perceive to be ‘agile-driven’—while agile is very much about trying and adjusting processes, depending on what works and makes sense on a case-by-case basis. Even in agile, you can spend weeks doing analysis or thinking up complex solutions and customizations, just to fulfil the customer’s wildest ideas and to seem smart or competent.
Still though, it’s a step forward.
The other thing that helps clear up solutions, but often in direct conflict with seeming helpful, is challenging customers needs.
When a customer says he wants to do some tiny change, it might end up needing days and weeks of work. Implementation, documentation, testing, and ensuring compatibility…
So even when we want to give customers the best—and creating new functionality and processes definitely seems like the best, the ‘professional’—often the correct way would be challenging—figuring out why he needs it, if it can be achieved differently, or even realizing he doesn’t need it at all!
Conclusion
What I am trying to say—as was phrased much better by Taleb—is that being smart or competent doesn’t need to look smart or competent.
Sometimes the most stupid question in a meeting will allow people to look at a requirement differently, giving clarity, and moving progress forward more than hours of discussion and pouring over excels and presentations would.
This is not an easy lesson to take to heart. Especially up-and coming consultants or technicians may be eager to show their knowledge, or use it to gain the customers’ confidence… But with time and experience, I believe it should be the goal to slowly move away from these ‘crutches’ of expertise.
For me, this is the greatest value consultants add—a clear insight, free from prior assumptions, that others may be too entrenched in to see. Showing there might be another way, better way, even when it’s not presented in a colorful report or five-page spreadsheet.
As the saying goes: “if it looks stupid, but works, its not stupid.”
Do you have any questions? Don’t hesitate to contact us!