The title is way off: he's talking about contractors, not consultants.
Short version:
Consultants tell the client what to do.
Contractors are brought on to do what they're told.
The advice in the article is a lot about "do you need someone do to ___ task" or "are you hiring an FTE, and could you do with a contractor instead" and that's contracting, not consulting. It's still valuable advice, but you don't find consulting clients this way.
This is a distinction that ceased being meaningful 10ish years ago. Even the big management consulting firms run a combination of staff aug and strategy advice on most projects because there are so many more dollars for staff aug and project work than there are for advice.
Yes, there are advice-only consultants and clients looking for that, but "consulting" is a bucket of work that encompasses a lot of different things. Trying to force a distinction is kind of elitist and not really in line with reality.
Source: been consulting for the last 12 years with firms of several sizes and focuses.
>>Short version: Consultants tell the client what to do. Contractors are brought on to do what they're told.
My company does both of these (we're in tech), and I can authoritatively tell you that in the overwhelming majority of engagements this is a distinction without a difference. Over the past five years I haven't had a single client who just had me "tell them what to do". Typically, if we're being brought in, the expectation is that we will not only identify what needs to be done to solve the problem, but that we will also do it ourselves.
I mean they don’t just have us tell them what to do, and then we go our separate ways after that.
Rather, after we tell them what they should do, 99% of the time they respond with “okay that makes sense, can you give us an estimate for how much it would cost to have you guys do that? Because we don’t have the inhouse expertise for it”
In those situations, we hire the other vendor as a subcontractor, rather than expecting the client to evaluate and establish a relationship with a brand new vendor.
It's not always practical to do that. For example you can have situations where you are advising on vendors who are 10x - 100x the size of your company, and would not accept a subcontract arrangement. Clients like the fact that you can represent their interests purely.
I'm sure what you describe fits your firm's experience, but it isn't indicative of the range of consulting experience.
> Just to clarify, do you tell them what needs to be done and do it, or only tell them what to do?
I only tell them what to do. You can check out my site via my bio to learn more - I'm really explicit about that in my sample deliverables. My consulting engagements are purely read-only - I don't make any changes to their environments whatsoever.
If you are just getting started, I think it is good advice either way. What is most important at first is just having clients. Whether you are behaving as an executive or grunt doesn't matter. If someone has clients, then I think it is easier to transition to consulting from contracting. And giving talks, blog posts, etc is great advice for consulting and contracting at any stage.
Assuming this semantic distinction holds, what are the practical consequences? How do you find "consulting" clients?
In fact, what is even the shape of a "consulting" engagement in software development, where I am telling the client what to do, instead of doing what I'm told? Do clients hire consultants to build software without knowing at least something about what software needs to be built? Not trying to put up a strawman here, it's just that I've seen this distinction made elsewhere, but not clear on how it plays out in practice. I suspect the line between "consultant" and "contractor" isn't that bold.
> Do clients hire consultants to build software without knowing at least something about what software needs to be built?
Absolutely - that's what I do in the database realm. One common request is, "How should I re-architect this system to fix the problems we're having today?" Another common one is, "How should we be storing this data to retrieve it more quickly?"
This type of work tends to be very senior, very architectural. Another way to think about it is by billable rate - at my rate, clients don't want to pay me to do the work. They just want to bring me in for short periods to tell them what work needs to be done, and how, and they have their existing teams (or contractors) execute the plan. It's not usually cost-effective to hire me to do it (although, for the right teams and projects, I cut deals.)
> Do clients hire consultants to build software without knowing at least something about what software needs to be built?
Yes? All the time.
"I've heard about this thing called machine learning. Come assess how I can use it in my business."
"We have a problem where orders are missing their commit dates and we need something built to find those earlier in our procurement process. Maybe our new cloud ERP can help...?"
So they have some degree of knowledge around the success criteria (what) and the value (why) but even those need to be shaped up and agreed upon.
And then the design considerations, approaches, tradeoffs, constraints, risks, options, etc. (the how) is somewhere between directionally correct and nonexistent.
It seems to me you find people who have a vague idea of what project they want built the same way you find people who have a fleshed out idea of what project they want built. And I'd much rather find people who have fleshed out idea of what they want to purchase. They seem to much more reliably and quickly pull the trigger.
Imagine you're selling ERP systems and you have a client who says "we need an ERP system that has features X,Y, and Z" versus "we think we need sometype of system to manage our business"
Which client do you prioritize? Every good sales person in the world will tell you the first one.
If you're selling ERP consulting where you go in and help clients figure out what they actually need, client #2 would be a better prospect because client #1 doesn't need your services. :)
That's definitely true that you want to be selling what your client is buying :).
But even in that circumstance I'd rather approach a lead that says "We need a consultant to come for a week look over our processes, and help us decide between these three ERP based on this criteria" :).
I worked at Accenture, Avanade, a 100 person consulting company before starting my own with a couple of friends. And pretty much every time the client brought us in they had a pretty good idea what they wanted. Sometimes we'd be able to find problems the customer didn't know they had or solutions they didn't think about but that was almost never the reason for the original engagement.
It's usually more "We think we need some type of system to manage our business, please deliver a white paper and presentation comparing options, and then stand by to design the option we choose"
Yeah, we've had a couple of leads like this but each has wasted an enormous amount of our time. The general story has been they'll bring in several companies, we'll compete to get their business. We'll win the "competition" and then they'll assure us they're right about to pull the trigger for years.
I've found that a large portion of clients that have vague idea of what they want are window shopping or very early in the purchasing process, that usually when I have vague requirements I'm usually pretty far from writing a large check. And it's really difficult(for me at least) to tell the difference between "I want to write a large check to solve a problem which I don't have any proposed solutions for" and "I have no idea what problem I want to solve, and if I even want to solve it, but I'd like to bring in a highly paid expert and chat with him for free to figure out if I even want to solve this problem".
Ah right, that's the key. Window shopping is ok, if it's the kind where they will write a check for you to help with the shopping. Window shopping where they are not anywhere near writing a check is no good, and is something sales funnel should try to actively disqualify leads for
But he actually gives examples of things you could recommend to a potential lead. I don't think it's as far off as you claim. And it's generally good advice anyway...
I strongly disagree. Nobody hires somebody to tell them what to do, ever. "Consulting" is always ultimately a euphemism for just contracting or freelancing. It's a figment of the imagination of McKinseyites and other people in suits who don't like to think of themselves as excel monkeys or powerpoint monkeys in the same vain as there are code monkeys.
> Nobody hires somebody to tell them what to do, ever.
Uh, that's literally what my clients hire me to do. I don't do any of the work for them - I analyze the current situation, and give them a checklist of what to do in order to solve their problems. I don't do the work.
I think that is literally what you think your clients hire you to do.
I've seen things that look like this on the surface play out numerous times, and at a deeper level it always turns out that what's going on is something different.
Example. SURFACE: Startup CEO hires consultants to tell him the next product line for his company. WHAT'S HAPPENING: CEO sends consultants off to do surveys, competitive intelligence, spreadsheets with made-up numbers, literature reviews, etc etc to build a case for what the next product should be. Also provides the slightest of hints that product X is something they should be looking into amongst other things (just a suggestion of course). Whenever consultants make recommendations that advance the agenda of company getting into product line X, recommendations are followed. For all other recommendations, CEO sends consultants off to do more surveys, more competitive intelligence, more spreadsheets with made-up numbers. BENEATH THE SURFACE: CEO woke up one morning, having decided to do product X. Needs to make it look like something other than his sheer whim. Hires some excel-monkeys to create a trail of documents, meetings, scribbles on whiteboards etc. Decided to outsource the excel-monkey work because he didn't want to distract his actual employees from doing the work that actually needs to get done to keep the company going.
Other example. SURFACE: Network incident response division in major international telco corporation hires consultants to determine the prioritization function for network incidents. WHAT'S HAPPENING: The network is rotting away. Every day, more incidents get created than the company has resources to address. There's a hiring, spending, and capex freeze, so there is no way to get the resources that are needed. On regular intervals, mid-level managers get shouted at by top-level bosses about why on earth they didn't give priority to fixing that one network incident that resulted in Tom Cruise being without a signal when golfing last weekend that resulted in a lot of press attention and ultimately even an enquiry from the regulator. Whenever that happens, mid-level managers change the prioritization function, to try to appease top-level managers. They have already done this 3 times this year. Then they have a great idea: Let's hire some consultants to determine the prioritization function. BENEATH THE SURFACE: They know that the whole endeavor is futile and doomed to failure. No matter how they prioritize incidents, the network will keep getting worse, and angry tweets from Tom Cruise about the shitty network will become an inevitable element of the brand. The outside consultants were hired as scapegoats. Next time the mid-level managers get shouted at by top-level bosses, instead of saying "Sorry, but we will really really get it right next time" they can say "I am just as shocked as you are! I told you we shouldn't have hired those moron consultants! But us mid-level managers, we will still be getting our bonuses this year, right? Because, ever since these consultants have been here, we ourselves, didn't screw up. Not even once!".
...I hope you see where I'm going with this.
Actual opportunities to make actual meaningful decisions are the rarest of things in business. You chance into one only rarely in your carreer. And when you have one, you don't ever give it away. No one does that.
To add to your first example... New product fails miserably in the market. CEO blames consultants for the failure, retains his job and gets his next bonus as scheduled. Rinse, repeat.
Short version: Consultants tell the client what to do. Contractors are brought on to do what they're told.
The advice in the article is a lot about "do you need someone do to ___ task" or "are you hiring an FTE, and could you do with a contractor instead" and that's contracting, not consulting. It's still valuable advice, but you don't find consulting clients this way.