41–50 of 97 posts
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 consul…
I don't necessarily agree with all of this advice. Yes giving talks, having a blog, etc. help but they are a medium to long-term play and you have to wait for leads to discover you or be referred to you. You don't have much control over when this happens, which is what causes a lot of the feast and famine cycles. I have had success just directly reaching out to companies I wanted to work with. This meant I was at lea…
Another aspect of this is that large corporations have pretty byzantine processes for hiring/vetting vendors. A freelancer acting as a sole proprietor or single-member llc raises risk factors with being classified as an employee, and will likely have to get routed through a third-party staffing firm for legal coverage. Which adds friction and cost to hiring you. A multi-member llc or incorporated entity, however, can sometimes be easier to get approval for.
You bypass all of those shenanigans by focusing on the small and mid sized companies first.
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 consul…
>>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…
Okay, great: that means you're a contractor. In the past five years, all of my clients have told me, "Tell me what to do." (I'm a consultant.)
He's spot-on with that last part: you only need a few. The same few contacts (4-5) have brought me more work than I can actually do, and I often have to say no. It's pretty hard maintaining a relationship with all of them, though: when you say no, they have to look elsewhere, and that's when the relationship can falter.
Do be careful. Becoming overly dependent on upstream "feeders" is what killed my company. It is a balance. Turning down work is dangerous, and the generally opposite of why you're in business. But giving other firms too much leverage will kill you just as dead as insufficient work. I started getting nervous when one company was over 50% of our income, but there was disagreement about urgency and what exactly to do ab…
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 consul…
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…
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.)
Earlier quoted context omitted.
> 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...?"…
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…
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. :)
Earlier quoted context omitted.
> 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...?"…
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…
Earlier quoted context omitted.
Do be careful. Becoming overly dependent on upstream "feeders" is what killed my company. It is a balance. Turning down work is dangerous, and the generally opposite of why you're in business. But giving other firms too much leverage will kill you just as dead as insufficient work. I started getting nervous when one company was over 50% of our income, but there was disagreement about urgency and what exactly to do ab…
I my experience, at least for an individual, I think saying no is exactly the opposite of dangerous. I’ve been contracting exclusively for 10 years and said yes about 6 times and no dozens or hundreds of times. As long as you say no frankly, with a reason, and offer some names of people who can help, people are happy with you and will more often than not ask again in the future. Saying no, especially for bad fit, is…
For people who are reading this quickly, this is the magic that makes saying no ok. If you are just turning down client requests they'll stop asking. Most people are extremely busy so they really appreciate having a "go-to guy" they can send any requests even vaguely related to what you do.