I've been there and done that for better and worse. It sounds like the author wants to create their own agency which is a different game than being a solo consultant. If you really want to be a solo consultant...
Lessons from 20+ years as a solo consultant:
- Customers rarely know what they want.
- Customers always change what they want.
- Change control in fixed bid work is vastly more important than how smart or productive you are.
- It takes an extraordinary amount of effort to find customers.
- One gets customers by searching, networking, having other good customers and mastering useful technologies.
- What matters long term is consistently making money every month.
If you truly want to be a solo consultant:
- Maintain good relationships with your customers.
- Bill hourly and get paid no later than monthly.
- Be willing to work with consulting agencies and accept their markup on your rate.
I did this for a short time, but one more important lesson I learned: The more $ you charge, the better you get treated by customers. The less $ you charge, the more abuse you take from customers.
Also, once you get good rates, you ask for a higher rate from the next customer. If it is higher than their highest rate they tend to tell you what their highest rate is which gives you a great place to negotiate from. Like, maybe I'll take less if I can work remote 2 days a week.
I agree. As 20+ years as a consultant, I can't imagine billing "per project". That dream project where the requirements don't change and the scope is perfectly estimated in advance doesn't exist.
I - then working as a freelancer programmer for a few years - once had a (German company) customer where the person that I was supposed to work with was so unpopular and known as "difficult to work with" inside the company that the manager that had hired me for the job apologized profusely, especially that he had to place me in the same room with that person. All the people I had contact with were similar.
Why was he never fired? Well, because he was so good, you could say he was perfect. So they gave him a room for himself - usually it was about four people per office and accepted the rest. And I say that with decades of job experience in many software companies in the US and in Germany. The documents describing what he wanted down to the last detail were just.. perfect! I ended up doing two programming jobs for them a year apart and both times I simply took the documents and worked on it from top to bottom until it was done. I never had to ask a single question, there never were any changes. Sometimes I had to explain a few things I did, but that was just usual communication, there never was anything unclear.
And also, I never had any issues with that guy myself, even during the time we shared a room. He "merely" expected everybody to be on his level, other than that he was fine. Once a female colleague came into the room to ask him something, and in an exasperated tone he told her that he had already described everything she asked for in paper X in section Y. And he was right, what she had asked was right there. As always, he had everything perfectly planned and documented well in advance. Of course, that's no way to gain any social points and that woman was almost ready to cry (I had quite a few chats with people working in the other rooms and the women disliked him the most, but the men did too), but for better or worse, he was just too perfect and expected the same perfection from everybody.
That was the first and only time I ever had such an experience, everybody else apart from that one guy is just working normally. Right now I have the exact opposite experience, I program for people who only have very fuzzy ideas what they want. Works too - you just have to treat it differently and have a different mind set. That one job is one of my most memorable experiences, including the social drama.
Had similar experience that you described but with a professor in Uni. He was documenting everything clearly to the last detail and was unwilling to answer any question, he was even unwilling to listen to questions asked because the answer was documented. I learned a lot in that class but I got a pretty bad taste for this type of this agressive personality. I saw it as logical sadistic at times... In retrospect I think that professor had some sort of asperger or was on the spectrum. I wish I knew that them, I’d probably take it better
Curious how labeling the personality as "on the spectrum" makes it more palatable? Not asking from snark, just genuinely curious.
As I think about it, it gets to what's wrong with the idea of expecting to be friends, or to always get along congenially with co-workers, when in fact the reason for interaction in a business is to produce something of value.
No doubt this unpalatable person was impressively productive in both yours and OP's stories, and in a business environment, I wish that could weigh heavier than the difficult personality...
Don't think I have a point, but am genuinely curious why having a diagnosis for the behavior makes it easier to accept
> Curious how labeling the personality as "on the spectrum" makes it more palatable
It eliminates malicious intent. If you know they can't help it, you still might think it's not worth working with them. But you know that it's not personal.
An analogy would be a coworker who studiously ignores your friendly greeting everyday. You decide they must think you're below them or not worth the time of day until one day you learn that they are deaf and were completely unaware of your greetings.
This sounds fantastic and I personally am trying to learn how to document better. Would you be able to share any of these documents or do you have one take away from those documents that was done differently than any other documentation you have seen?
This approach to product design is the polar opposite to design thinking. In my experience it only works for internal use products and to a lesser extent b2b products that are replacing a deeply understood manual process.
Specs, reference docs, how-tos, tutorials, and explanations are all different types of documentation. They have different tones, amounts of detail, structures, and purposes. It's impossible to do all of the above in one document except in trivial cases.
So at the risk of having opinions that overreach the context I was given here, I'll argue that the materials were not "perfect", no matter how thorough.
In fact, I think it's possible to edit what you wrote a little and make the word "perfect" ironic. If someone is making colleagues emotional, that's a red flag that the approach to documentation leaves room for improvement, for instance. Good writing requires empathy for the audience.
My guess would be that he has created all of this documentation and that nobody is reading it. Everywhere else in the company there is probably a culture of creating project requirements with a series of meetings and emails and it doesn't even occur to his colleagues that there is another way or place they are stored.
Most of my 27 years were as a consultant. Honestly, every time I hear someone talk about what you did, scope change, I ask, "What was the original definition in the contract?" Usually I hear back, "it was just a quote for the job, no contract."
Scope changes aren't scary if you write a good contract. As a consultant, that's truly one of the most important skills, writing a well defined scope for contracts. That way when it changes, you're covered by change order fees.
Surprisingly, I didn't learn the hard way, I actually took advice from other people. Granted, I've learned a LOT the hard way, but not that one.
There's a clause that says the scope of the project is defined in an addendum document, and any changes to that may incur additional fees that must be agreed upon by both parties. There's also a clause that the deposit is 100% non-refundable once I have begun work in any manner, and that I'm not obligated to turn over anything until the final payment has been made. This way they have skin in the game, and can't try to pull a fast one with a huge change expecting me to do it free or lose the contract.
Those responses are so funny to me, as there seems to be a complete difference in recommendations, every time this topic comes up.
I'm also very happy with hourly billing, but the last time I saw a similar topic, the whole comment section was insisting that per-project billing is the only viable way to make money in consulting. Oh well..
the whole comment section was insisting that per-project billing is the only viable way to make money in consulting.
Generally, when someone gives you advice that's supposed to be 100% right in all cases, they either stand to gain from it personally or have no idea what they're talking about.
In this case, the difference between the two approaches is mostly a question of who ends up with what risks. My wife and I run a two-person development contracting business, and we've done projects with both approaches. Both have worked well for us, but for the type of work we tend to do, most projects would not be suitable for fixed price billing.
The reason is that most of our work consists of "deep dives" for figuring out if something is possible at all. (Or more precisely, possible within a reasonable amount of effort.) So what usually ends up happening is we'll agree on a capped research budget, and dig into the problem up to that number of days. If we find a solution before that time, great; if we find a fatal blocker before that time, well, not great but it's a result. Otherwise, we'll hopefully have found some leads to pursue in that time and can give a better estimate for how much more effort it'll take.
Maybe it's possible to do this sort of project on a value-based basis, but I certainly haven't found one that seems fair, or that a client is likely to accept. The author of the original article likes to claim that with value based pricing, interests are aligned. Well, for this sort of project, one of the parties is likely to lose out massively if you agree a fixed price up front.
And as for the author's assertion that your income is capped: you have one variable you can tweak: your rate. Charge more! We charge more than his "optimistic estimate". Sure, we're still not rolling in it, but we also don't work anywhere near 40 hours a week. And the implication that our incentive is to drag out projects to get more billable hours - well, I have a stronger incentive to make all my clients super happy so that they keep coming back for repeat business. This way, we have more requests coming in than we can feasibly accept.
Of course, only touch open ended projects for savvy clients. The nature of our particular specialty means we work with tech companies who understand the nature of big unknowns in projects.
You don’t understand. $240K is not cool, $2M is cool.
Good luck with hourly billing to get that kind of money.
The only way to still doing what we love - software engineering (not some kind of managerial, leading, business role) is fixed price and re-selling already implemented stuff (same approach as lawyers).
Only reselling already implemented stuff is neither software engineering nor what I love.
$240k would be a highly respectable income pretty much anywhere in almost any field. In most of the world, doctors are paid less than that while routinely working night shifts and constantly making life and death decisions about their patients, and you’re seriously complaining about being paid $2k/day for fiddling about with stuff on a computer?
Dude, nobody cares. What ridiculous moralizing. "Fiddling with stuff on a computer?" Crabs-in-a-bucket comparisons to doctors? Whatevah. Get outta town.
No one pays you because they like your face. They pay you because you make them money.
No one works when they have rivers of cash flowing in their direction. You trade your time for their money: a slice of your life, in the most literal sense.
What is the value of your life?
Know your worth. Take every dollar. You will get precisely what you can negotiate, nothing more, nothing less.
Good luck making $2M as a solo consultant. In order to take on projects that big and maintain your customer pipeline you almost certainly have to build a team which is what I call creating an agency.
The real answer is you do both depending on the situation. My best hourly has been doing per-project billing, but you need to be smart about it or you can end up working some hours for free. Hourly T&M is a nice situation to be in since it takes a lot of the risk out and lets you just focus on the work that needs to be done.
If you're in familiar territory, the product is well defined and the customer is reasonable - go for project billing. An example would be implementing some low level function for an embedded device. Anything you know is going to only take a few hours, bill per project (unless of course it's an extension of an existing hourly contract with a customer). Anywhere there's upside or difficult circumstances (such as unreasonable timeline due to external requirements, such as an upcoming event or demo), charge per project.
But to be in that position you first need to build a stable revenue stream and that happens more easily with hourly consulting.
I think a "low level function for an embedded device" is probably the riskiest well-defined software problem you might ever run into.
It isn't unlike tying your contract to the behavior of a poorly documented remote API provided by another company that won't respond to any of your requests.
The risks include: the hardware being flaky. The hardware being undocumented. The hardware having no run control. The function relying on another piece of hardware or environment not provided.
I once spent two weeks looking for a single bit not-so-helpfully labelled "WinCE" in Texas Instruments' documentation.
I totally see where you're coming from - in my mind I had something like a modern ARM microcontroller (STM32 and the likes) where the functionality is 99% internal to the chip. For example, adding an SD card or CANBUS interface to a project - not too much you depend on the customer for in that regard.
But then again I'm at this very moment doing a board bringup for a Tegra AGX system and I wouldn't advise anyone on doing that on a fixed price contract!
Good point. From this thread it is clear that people have made a go of it with project billing in some domains. I develop enterprise business systems that are generally too large and complex to reliably estimate or manage to a fixed budget.
In any case, all it takes is one project with one unreasonable customer who demands extra work and then doesn't pay, to wipe out the gains from lucrative projects.
Also, in the long term you accumulate responsibilities like mortgages and families that makes that low-risk monthly revenue stream so important.
> But to be in that position you first need to build a stable revenue stream and that happens more easily with hourly consulting.
I'm trying to get started with freelance work as a college student, and I've experienced the opposite. People want project-based billing because they don't trust me, or my ability to work "as quick as an experienced programmer".
(For context, when I say starting I mean starting. I'm currently working on my second contract ever. I have no non-internship work history. My first was for $50 for what ended up being 4hrs, my current was $300 for what I expect will take at most 20hrs. Then Upwork takes 20% for making the match and providing insurance against my not delivering.)
I'd say that for 20 hours project, it's generally not worth the hassle to bill hourly.
For small tasks people want to know what they're on the hook for, but once you go into the larger scopes with more variables and properly price your risks, you'd notice their reaction is much less welcoming.
I don't know the exact nature of your work - is this just doing generalized programming work, or do you specialize in something (e.g. setting up a Wordpress site)? If what you do is repeatable enough, at some point you'd make good money working per project because you'll become much more effective.
Of course it's more difficult to pull off when you do generalized work.
This however has one very significant exception, and that's when dealing with a corporate client which would lead to more work.
You see, any company that's larger than 20 employees separates the financial management from the technical staff. That means that if you've made it through negotiations and contract work setting an hourly framework with the financial side of the company, you're now another tool at the disposal of the technical people which could utilize you almost on a whim.
With a project based setting you need to go almost to square one and renegotiate all the way down every time you want more work. It's not just a hassle for you - it's a hassle for the engineers who'd love to use your help.
This, eventually, is what builds you a recurring revenue stream; making yourself available to the technical people at minimal friction. I've been responsible for a pretty significant corporate operation where my team was responsible for procurement of products and services the size of a respectable startup A round, and dealing with vendor onboarding, scope of work, legal approvals and financial signing at the VP/CFO level were a huge time waste. Contractors who billed hourly were much simpler to work with - waste time once and be on your merry way for months at a time.
I try remembering that now when I crossed sides, back to consulting. Try make the life of the people who need your services as easy as possible - usually you'll have mutual interests.
That's fascinating. Thank you for sharing your experiences.
> I don't know the exact nature of your work - is this just doing generalized programming work, or do you specialize in something (e.g. setting up a Wordpress site)?
I have no idea. I'm just applying to every doable looking short job on Upwork posted a by client that doesn't scream sketchy or terrible to work with (eg they've hired more than five people and rated every one less than two, or they say they want to run deploy code to other people's computers remotely but will only give details over another channel).
By doable I mean looks like I'll only have to learn two or three new things. For example, I just finished figuring out how to make a basic Netlify cloud function that will take data from the Google Sheets API (two new things) but the next step, parsing the cells and plugging it into a template, is something I've done before.
I'm thinking of becoming a Shopify specialist because the dev experience seems so pleasant, but I wonder if I'd be better off learning something more unpleasant to work with because there might be less competition.
If you need the work to survive I guess take it but a good lesson to learn fast is that if someone says something belittling/disrespectful to you like that then just politely move on.
Plenty of fish in the sea, plenty of clients who are a pleasure to work with and want to build a long term partnership with their freelancers.
Likewise, if you aren't desperate for cash today try making a plugin for a marketplace somewhere, or some library or product you can be an expert in. Also consider whether companies might want a part time intern during the year or other opportunities. I think freelancing works better after you've been on a successful team and can replicate that success on your own. It's a lot of moving parts if you're just beginning to learn your trade.
Thank you for all your advice. You've given me a lot to think about.
I absolutely don't need the work to survive. I'm aiming to get around 200 hours of contract work over the course of a semester with good references to be more competitive for jobs and internships this summer.
Also, I didn't even bother applying to the jobs that had those quotes I mentioned. I doubted very much they'd leave a positive review, and with only one review a negative review would make it much harder to get the next job. Those quotes came from the proposals they posted for freelancers to apply to be interviewed for, not private communications.
I'm going to college in a small town in Connecticut, where I can't get a programming job, and I don't think many places would take on a remote intern. In the summer I'll be staying with family in the Bay Area, so options will be better.
Your advice to build a plug-in sounds like a great idea. I think I might try to specialize in Shopify, get a feel for what people want, and then generalize what I'm building for people (of course being transparent that I would retain ownership of code).
I totally agree with you that it doesn't make sense to jump into a career in freelancing. It does look like a nice option once I get more experience, thought.
Best of luck and it's really great you're even thinking of these things now.
And while there may not be so many remote internships out there, tossing a resume at a remote-friendly company and seeing what happens can't be any harder than upwork :)
> Also consider whether companies might want a part time intern during the year or other opportunities.
Personally, I was lucky in this regard. I landed myself an internship summer after my sophomore year in college doing web/db work on an intranet site at a Fortune 500 back in 2001. Paid decently, started at around $15/hr. When I left 3 years later, was making around $20/hr. Worked fulltime during summers, but was able to keep working through the school year. I was also able to largely work remotely during the school year, so I was able to put in 20-30 hours per week while only going into the office once a week.
The internship was a great experience. I was working for the DBA team, so I got a lot of hands on experience and knowledge working with them on several RDBMS's including DB2 (mainframe), UDB (Unix/Windows) and SQL Server. Things that I had no course to take in college at the time.
The internship also set me up well for getting my first fulltime job. The hiring manager was stunned at the uears of professional experience I had straight out of college and the level of self learning I showed (worked ar first in ASP/VBScript and Javascript, then ASP.Net/C# in the 1.0/1.1 days - all self taught). They had me take Brainbench exams for C++ (which is what they were looking for) and C#. I was abysmal at the C++ exam at the time, something like 65th percentile, but scored above 95th in C# at the time. The manager took a risk and hired me, expecting that Id be able to grow into the position. This at a firm known for hiring only from top Ivy League schools and culling the bottom 10% every year. Lasted a bit over 9 years there, before I decided to move on.
It's a different strategy. Per project you take on more risk, but you can also typically charge a lot more (less of a barrier for the client to overcome than hourly).
Definitely this. I moonlighted as a consultant while at a full time salaried day job. Job was billed as some minor enhancements to a data processor and a website for one of their clients. What it quickly devolved into was badically me being the scapegoat for everything that was wrong and expecting me to to answer rather impolite and unprofessional emails from their client (this was in finance). Even billing at 150/HR, it wasnt worth it and I quit after a few months.
The little extra per week just wasnt worth the stress and hassle.
It's not that they don't know what they want. It's not that they change their mind. It's that they are oblivious to the cost (to you) of both. Furthermore, when the cost is fixed there's typically no incentive for them to be reasonable.
I find it funny how often I hear, "it's just..." Really? You hired someone else because of your lack of knowledge/experience but suddenly miraculously you have complete clarity on what it's going to take?
Why do you suggest hourly? I understand fixed big puts all of the risk on you, but would you also consider daily or weekly billing as a reasonable compromise?
Larger clients are not flexible about how you bill them. Hourly is the only option. Never mind that you might be working on multiple projects, run training, meetings and so on
In this case, I would still break out my work across multiple projects and types of work all charged at the same rate. If no other reason than to give me a breakdown of numbers to estimate future projects.
Billing hourly or daily is about the same. Weekly gets complicated. It is all about reducing risk, locking in cashflow and getting compensated for your time and energy.
Weekly/Monthly billing means you can never take a vacation. And if you're going to suggest pro-rated weekly billing well that's just daily or hourly billing isn't it?
You could certainly take week-long or month-long vacations, or take a month off of consulting to do things like business development or education. Generally, if you're at the level where you're billing engagements weekly or monthly, monetarily you don't need every single week to be filled with billable work.
The thing is that managing inevitable scope changes is an art and a science. Some changes get accepted as part of the project, others are scoped as fixed price updates and others are very hard to scope so may be hourly. In any case this involves identifying the changes, scoping the work, estimating the work, pricing the work and then negotiating with the client to accept the pricing on the change. All of that takes time, often has little to do with the actual development and adds additional risk. That change control is the delicate balance of pleasing the customer while continuing to make money without taking on too much risk.
I work for a small consulting firm, and we keep bidding on very aggressively-timed projects with technical challenges and high skill requirements. Things like directory system mergers, mail migrations, complex infrastructure builds, etc...
The conversation always goes like this:
"How long would it take your to do it?"
"Physically? 2 weeks of button-pressing time."
"With change control and stuff?"
"6 months."
"What!? That's crazy, the customer won't accept that!"
"Well, tell them to stop adding 2 weeks of change control management paperwork for a no-risk 5 minute task in a green field environment with zero data and zero users and then we can do it in 2 weeks."
"They have processes! You know that!"
"Their processes are stupid, that's why it's going to take a chunk of a year and cost an order of magnitude more."
"Fine, we'll promise we'll do it in 4 weeks and then bill them for anything over that if we're slowed down by change control"
"So now I have to do both the change control paperwork and I'll have to track everything internally so we can charge the overheads back? It'll take one year."
"You're wrong! You'll see! It'll be 6-8 weeks at most."
... one and a half years later...
"I told you."
The customer of course signs off on the 4 week estimate, thinking they got a good deal, and the final bill is like 95% overruns and paperwork overhead, but we make a much bigger profit so we don't care. Why would we? We get paid at consulting rates to sit around and fill in boring, simple paperwork. The customer doesn't care either, because they see the costs as "unavoidable", and it's not their money. It's either the taxpayer footing the bill, or it is some huge department's budget at MegaCorp. The decision maker never gets any personal penalty for this kind of thing.
This is why 90% of larger government IT projects have cost "overruns". It's not really an overrun, it's just how these things play out.
PS: This really does happen this way. At a recent project the minimum lead time for any change of any magnitude was 2 months, which was negotiated down from a proposed 4 months. If anyone forgot a firewall rule somewhere we all had to put tools down and twiddle our thumbs while one guy on the team filled out the paperwork and jumped through the hoops to convince the powers that be that yes, server applications really do need networking.
PPS: I have seen change control stop a bad change going ahead exactly once in twenty years. Once. That's because I rejected the change, and this caused an argument and then eventually they did the change anyway and broke stuff. I'm convinced that change control is 99% pointless. The 1% benefit is dwarfed by the overheads and costs. Change my mind.
> I'm convinced that change control is 99% pointless.
99% of the time their packaging and/or deployment systems can't track changes to the degree their change control setup claims anyway.
Thought experiment: run an "upgrade" command on your package manager. Even with a modest system, there are dozens (possibly hundreds) of "things" (executables, configurations, daemons, modules, etc.) that change. Often those things are rebuilds incorporating updates from their dependencies. So if a change management system wants to track exactly why each update happened, that appropriate stakeholders were in the loop, etc., you're actually stuck.
No [1] release system has that level of detail. You'd need a directed graph of all the reasons for all these changes top to bottom.
[1] Yes, I've seen safety critical situations before. No, the paperwork isn't at that level of detail there either. System-wide requirements (the whole system has to be fast in specific ways) don't map to particular lines of changed code like that. At some point, the paperwork gets to be gratuitous.
My point is actually that it's not possible to do that meaningfully past a certain (rather modest) level of complexity and reuse. How does a library like openssl meaningfully and thoroughly notify all it's downstream users in Debian, Node, Gentoo, etc. what changes to pay attention to?
My experience with CC is not that bureaucratic, where it took weeks/months for a single line change. Simply a discussion and negotiation at the weekly meeting between the stakeholders.
I’m not so willing to engage with consulting agencies. I find it very difficult to deliver a good product with an added degree of removal from the final customer, which is how some of those agencies structure work in order to maintain their business.
When you say "Be willing to work with consulting agencies and accept their markup on your rate.", are you saying that they should pass on your cost to the customer? Or do you advocate reducing your rate to acknowledge the customer-acquisition-cost of the agency?
I've struggled with this myself. I am firm on my rate, but I also haven't really considered that it might make sense to reduce it in the case that someone else is finding the clients.
I agree with everything except "Bill hourly".
A client wants a benefit, not x lines of code. Charge them for the value you deliver.
The few hourly projects I agreed to when I first started were always a challenge because I had an incentive to not go full speed which then ended up killing the enjoyment of loving what I do.
You should be flexible enough to bill in whatever manner that works best for the work at hand, the client, and most importantly, yourself. If the job requires hourly billing, don't pass it up because "I don't bill hourly". With some clients, you simply won't get them past that and it's up to you to make it work anyway, for both of you.
I agree, you should push clients away from hourly billing, but sometimes it's not possible and it's not worth losing an opportunity over.
You can propose to "sell" a fixed number of hours every two weeks or month, then allocate those hours when you estimate, without forcing you to keep a timer open while you work.
Yes, it's a compromise, you're not selling value, but you're not exactly selling time either and you have sufficient incentive to be productive.
Please let's not pretend that there is an infinite amount of opportunities out there and it's just a matter of your grabbing the right one. You need to keep money rolling in every month and you take what's in front of you, making the best of it.
Yes, the consulting agencies or headhunters do just that. They do the day to day work of talking to hiring managers. Then they take their cut either when they place someone full-time or take a cut out of the hourly consulting rate.
It varies from place to place, but in the NYC metro area it is common for companies to only staff up through agencies so there is no chance to go directly to companies unless you know someone inside the company already.
I cant agree with this article. Ive been a solo consultant for 5 years now. Here are my takeaways-
-Maintain good relationships with anyone that can give you work. Most of the time you will ping pong between vendors for work.
-Don't be afraid to build in "bench" time into your hourly rate. The rates listed in this article are much lower than I would recommend. I target 85% utilized in my personal model. I work in a niche and will not consider less than 150/hr for anything less than a 12 month contract.
-Remember that despite the best of relationships and intents, contractors are expendable. You can and will get let go before employees. That is not a bad thing. In fact, its a gift. You get to leave before morale and expectations get too far out of control.
-Do put rainy day money away into fungible assets. Savings accounts probably aren't great for that.
-Do try to have multiple clients at once, if you can swing 2 full time gigs, most of the time this can be juggled in the short term.
-If you get told you are rolling off, don't take it personal. I have the hardest time with this part of it. It is my nature to give my all when I am at a gig. When the let me go, I feel that it is an affront or personal. Its not, its business. If you do this, you will make more than many high level executive salaries. That doesn't count the equity side but making 2-400k a year is a real possibility.
-When its time to leave you will know. The biggest upside I see in consulting is I have the freedom to leave when I cant deal with the bullshit anymore.
-Every company has bullshit you will grow tired of. Honeymoon periods last 3-24 months, but there will always be bs.
> put rainy day money away into fungible assets. Savings accounts probably aren't great
Could you elaborate? Do you feel that the returns on savings accounts are too low?
What do you recommend instead? (I'm not looking for a very specific answer here.)
I would think that you would want emergency money to go into something that isn't very volatile, and savings accounts or money market account are the first things that come to mind.
(I've been very disappointed by what I've seen of CDs. If you hunt around, you can find savings accounts with interest rates that beat any CD I've seen, and they don't have an early withdrawal penalty.)
The online savings and money market accounts are the best I have found as well. Also shared your experience with CD rates while looking at them. No point to going down that road unless you need to make it harder for yourself to withdraw money. Depending on your health insurance situation tax advantage of HSA accounts as well even though they are less fungible.
Fed rate dropped - but up until a month or two ago, there were a number of banks. Discover, Wealthfront, Marcus by GS. Right now the rate i'm seeing everywhere without crazy requirements and no minimums is ~1.7%
Ally Bank offers 1.6 APY if you want a bigger name with a good reputation that still offers decent rates. And I don't think more than a few months expenses should be in savings anyway (as opposed to ETFs)
If you're working a project on a full-time basis, the client will expect to be able to call you up and get you on the line at pretty much any time (and yes, often outside of normal work hours, in my experience). If you're on a "part-time" basis, you don't have this pressure because the expectations are set differently.
> the client will expect to be able to call you up and get you on the line at pretty much any time
I get your point but maybe it's the opposite in some cases? People want to have someone they can get at a moment's notice and when they find that person they are more likely to a) Use them next time (where price is less of a factor) and b) recommend them to others.
I say this as someone who has done quite well at consulting (and I do mean that) and that has no problem taking a call even on Saturday night. Now of course the devil is in the details and the particular client (goes w/o saying) but the counterpoint is that is how you build customer relationships and build a business. Fear of 'door number two' is what gets people to pay more the comfort of knowing someone is there for them.
I agree with you, and that's how I personally choose to work. There's a lot of folks who would prefer a different lifestyle if they could manage it though.
Ultimately, the number one thing that gets repeat business is results. Because of that, I can totally imagine people who offer a smaller time commitment still being successful. Regardless, I definitely wouldn't recommend going the 'part-time' route to anyone that isn't already established enough to get away with it.
Some customers expect you to be on call 24/7 if they think you work for them full time. Setting clear expectations that you always have other clients removes that.
IF someone employees you full-time, the 40-ish hours they pay for is always interpreted as whenever they need you (if they're working you are too, right?). If you're part-time the mental model is you are only available for a very specific subset of hours (which a crisis rarely honours) or the expectation is you don't respond immediately because you're not a full-time engagement. Either way you don't have to be on call 24/7
All the customer’s managers including the CEO sided with X, as they concluded that bending the company X to their will was more trouble than an individual. And anyway, I would be paid for the extra work.
I absolutely don't understand why this is the problem. Something came-up (not because of you) and you will get paid for solving it.
If you don't have time (other plans) or you just don't want to do that (good example: request is stupid and you know it will cause more trouble in the future) you can just tell that to your customer (or bump-up rate for this extra work).
How value base pricing would solve the above issue?
I had a similar reaction. Something doesn’t add up about the anecdote. His customer decided it was in their own best interest to pay his hourly rate to solve the problem. Partner X decided the same. What’s the problem?
It’s quite the leap from there to an accusation of unethical behavior. I’d wager he had incomplete information or there’s much more to that story.
Edit: For example, Partner X might have said to the CEO, “I understand you’re frustrated with the outcome, but it does meet spec and we advised you Z was missing from the spec you provided. You decided to keep Z out of scope. We’re happy to add Z now, and we’re also happy if the author adds Z. Your choice.”
He reasoned in terms of days needed to fix the problem, and concluded that therefore X would be cheaper. But maybe the change management in the contract made it more expensive. So even if he needed more work on it, he was still the cheaper option and/or easier instead of a change request.
This is a problem from the perspective of the customer. Company X delivered a substandard product based on a fix bid. The customer then had to turn around and pay 10 weeks of hourly fees to this guy to finish it.
Presumably, if magic of value pricing was realized X would be incentivized to finish it.
Pretty unprofessional on X's part I'd say, so I understand why the OP nearly lost it.
I think that just highlights the downside of fixed bids, value based or not, that the author ignores. You come out ahead and are incentivized to finish early, but are deincentivized to do any additional work if you go past your costs plus margin
The customer found someone to do the work and was willing to pay for it. If he had his customer's interests at heart, his objection should have ended the moment the customer made a decision. No need to "lose it".
I did both hourly and project based pricing models when consulting. Each have pros and cons but for projects that aren't "off the shelve" and do require discovery days, lots of inputs from client and a level of solution design from the consultant, the key thing is milestones. This way you can fend off scope creep and also be very specific on deliverables.I.e.:created x feature: 10 hours( 15% of the overall project). As for the rates, one hits the ceiling pretty quickly with hourly rates: try pitching $500/h if you not a lawyer. That's why value based pricing is the only way to push it up as high as possible. It's one thing to say that you'll be charging $200/h for the next few weeks and another when you say you'd build something for $24K that'll make the company $500K over next 12months.
I shifted from mostly fixed price to mostly hourly based billing over the past year, and increased the rates. It’s very easy to start a project with hourly billing, adjust the scope and expand as you go. It’s very difficult to do that with a fixed priced project.
But the biggest issue against fixed price is that companies are quite bad at pricing R&D activities (which is why they’re usually running late and require office heroics to complete).
When you try to put a realistic price on such an activity you may give your customer a sticker shock.
I still do fixed price at places but only when the work stands alone and it’s something I’ve done many times in the past.
Working hourly, if you spread the work across multiple clients and provide good value for each, creates a structure where you cost each of them slightly less than a full time employee. My experience is that this is quite sustainable for everyone.
There are a few general prerequisites for fixed pricing. They apply to hourly pricing as well but they're more important when the price is fixed.
1.) The project needs to be well-scoped with any significant out-of-scopes also explicitly specified.
2.) Client responsibilities/deadlines are specified.
3.) As you suggest, the work is predictable based on past experience and there aren't likely to be unexpected things that come up and significantly increase the time required.
When I'm spending 90% of the time developing software, especially if that's a stand-alone or well specified isolated components - I can quote after some initial research, and I agree it's a good way to go.
For other clients I'm doing a job of technical lead. In that case, too much time is spent defining requirements, reviewing other people's work, writing project documentation, etc. These things are borderline impossible to estimate in advance. For these projects, I prefer hourly contracts.
Scrum is more or less a time & materials approach.
Agreed. If it's small and finite - similar to an oil change - then a fixed price is doable. On the other, if the resuest is "the engine sounds odd and acceleration is off" then it could be anything.
Anyone who is the latter but expects a fixed price must be avoided. They'll cost you more than you'll make.
> They call you. Your acquisition costs are close to zero. The million-dollar question is: How do you make potential customers contact you?
>...a strong brand makes finding new projects so much easier: New projects find you! Be aware that building up your brand easily costs you 60 hours per month.
Not sure how this is a compelling argument. 40% of your time seems like a lot more than close to zero
I took it as just a statement of reality that people should be aware of. Especially for higher-level advisory work, i.e. not primarily writing code, a large percentage of time is "off the clock." Most of the independent consultants I know spend a lot of time writing newsletters, doing podcasts, speaking for free at events, in addition to whatever 1:1 marketing/sales they do.
I think the point was that the acquisition costs are _not_ close to zero. Rather, the acquisition costs are no longer specific to individual clients, they're general in nature. If you spend just as much time/money but don't spend it on specific client, then the cost for each client doesn't change (it's just the total divided by the number of clients).
Good point. There clearly are acquisition costs. In marketing speak what he's basically saying is that your bottom of funnel acquisition costs are low. (I don't think they're quite zero because you still need to close a specific contract.) But top of funnel awareness/education/etc. is a large chunk of your time. Which for some types of consulting/advisory work rings absolutely true to me.
I think the author is trying to say that you're trading high fixed costs to get near-zero marginal costs per client acquisition.
If you're only planning on working with half a dozen clients every year, the distinction is mostly academic. If you're running an agency that has a new project kicking off every other week, the difference could be huge.
It's an ages old dilemma, per-hour vs. per-project. There's no single right approach. It's a choice, often circumstantial. Both options have risks.
Solo/freelancing awards us that freedom to balance the risks. After all we do sell our time - we either bill our client for it OR give the account of it to ourselves (man, that design took me awile....).
So eventually it's supposed to bring out that feel of one's own time value. Raising rate is what logically comes out of this too.
Being solo also means facing one's own anxiety and insecurity. So we need to be flexible and choose whatever works to boost our professional and personal confidence, then review what outcomes this turned us. This, again, will eventually harmonize what you bill your client to what you really want to be paid.
The real question is how soon this balances out before bills would choke us. So it makes sense to not routinely under-charge just because of anxiety, as this only will make it stronger next time.
I'm curious to learn about your adventures in value based pricing.
I've worked as an independent consultant for 3 years and have priced by the hour, and using value based fixed prices...the latter with mixed results.
I love Jonathan Stark's Ditching Hourly podcast... And I must recommend the 2bobs podcast with a shout out to Blair Enns on value based pricing and David C. Baker on expertise advice business.
Not the OP but, when I did consulting/advisory work, we mostly did a combination of value-based and nominally value-based.
What I mean by that is our large clients had subscriptions with us for advisory services, which included or could include some specific deliverables like reports but was mostly fairly open ended access for inquiries, press references, etc. I put these mostly in the value-based category.
Then we had things like advisory days, speeches, etc. we priced on the basis of the deliverable value--but in practice there was a fairly close correspondence to time spent. In practice also, clients would end up turning a one day session into two half-day sessions for different groups, so from their perspective they were mostly buying our time on-site (plus travel, etc.). We tried to hold the line on pricing for value but I'd say we only had some success here.
We'd also do custom research etc. for clients which, from their perspective, was almost certainly more value-based as much of our work was out of their sight. (Of course, from our end, we were mostly coming up with that pricing from a desired internal day rate.)
I think the only time we nakedly charged by the hour was when we were doing legal work because that was just the way the law firm which was our direct client worked. (TBH, it was pretty nice to get a healthy hourly rate for everything and it was a substantial job. Also somewhat open-ended work we weren't particularly familiar with, so an up-front quote would have been difficult.)
My biggest challenge with value based pricing (VBP) was that it required an upfront discussion about the perceived value of the work, and my prospects/clients were often totally in the dark about "value".
I don't think VBP works well for tech/biotech startups:
-founders/exec can't define value
-founders/execs are selling the dream (= infinite value) and don't want to pay for it.
-startups want to hire brains, but pay for hands
-founders/execs and especially managers want to focus on (minimizing) "costs", rather than unearthing or creating "value" with consultants.
Yes, we worked for (or at least were paid primarily by) mostly old-line enterprise IT companies. We talked to plenty of startups. But they mostly couldn't/wouldn't afford us even when we had good personal relationships with the execs. ADDED: I do know at least one firm that does mostly value-based advisory work for small companies; their approach is to have a fair number of low dollar small clients in addition to some larger ones.
As I said, even with the big cos, a good chunk of what we did was at least roughly day-based. At one point, for example, we experimented with trying to price more strategic advisory work higher than make-your-product-launch-deck-better type of work and it never really flew.
I'm not really convinced by the argument regarding value-based pricing, because that's just not how markets work.
The clearing price (in this case, of labor) is based on demand AND supply; it has nothing to do with how much value you bring to the table. Yes, it's true that maybe writing some piece of software will save some company ten million dollars per year. Should you get one million dollar for writing it? Maybe not, if I can find someone charging 60K to develop that same piece of software.
There is one way to do that with software, though: royalties. It's used for middleware for games and movies. But it's more a risk-management tool for buyers than a sure path to profit for providers (i.e. with royalties you limit your losses if the game or movie does poorly).
So, in the end everything boils down to negotiation. Obviously, if you can't negotiate the $1mil deal, then you won't get it.
Furthermore, the market is not perfect. Just because somebody wants to do the job for $60k it not mean that the company can even get into contact with this person.
Crucially: if you’re more likely to deliver successfully you’ll be able to price accordingly as well. E.g. if the perceived change of success with the 60k person is 80% and with you it’s 90% then you’re arguably worth a few 100k extra.
(Now: that %-chance-of-succes is difficult to measure. Which is why it’s a relationship business IMO :)
> An easy way to build up productised services is to keep the rights to use of the software that you write or that you oversee others writing. This works best for software that doesn’t give a competitive edge to customers and that is not specific to customers. Your leverage is to give a discount on your fees, if you are allowed to keep the rights to use.
I have never seen this going well. It is in my experience very rare that companies are willing to let the consultant keep the rights and when they do there is a big chance that they regret it and want the rights for a small fee later. I've seen this damaging the customer relationship in the past. I'm curious what other consultant's experiences are?
I don't have firsthand experience, but anecdotally this sort of thing seems to be more common with government agencies and large corporations than small business clients.
I suspect that negotiating it is a lot more complicated than just offering a discounted rate. Honestly, it probably involves wining and dining key decision makers. (Hence, why it happens with government agencies and large corporations.)
> I don't have firsthand experience, but anecdotally this sort of thing seems to be more common with government agencies and large corporations than small business clients.
Dumb question: is "this sort of thing" keeping or not keeping the rights?
Not parent, but I suppose that government agencies in the US are more willing to not insist on keeping the rights. There is the idea that tax-paid work should (or must?) be available to the general public. Therefore the agencies don't have a good argument for keeping the rights anyway. As far as I know this is very much a US thing and doesn't exist elsewhere. At least where OP and I work it is - to the best of my knowledge - unheard of.
For a prime example see SQLite, which is in the public domain because its author worked as contractor for the Navy, when it was created.
"Don't charge hourly" doesn't work for "researchy" work where you can't be certain things will work in the end or indeed how long they will take. I charge hourly. Setting a high hourly rate (if you can do it) prevents the "bullshit work" situation described in the article. Customer then finds it more cost effective to have their junior FTEs do bullshit work.
Please take also the consultancy buyers perspective when assessing the value you bring in.
Are you the only consultant who could figure out how to bring down the cost of the appliance (in the articles example) down by 1$?
If not then your value is not as high as you used in the calculation.
The potential client could find other consultants to do the same thing (price optimization of a mass product - service well available in the market).
As there are more providers then estimating the "value" should take in to account that there are several offerers of service. It is now a tendering situation. I am now excluding a remote situation where all the offerers of the optimization service would collude in their offers.
The customer perspective is more "this is my ROI, and thus budget I can request from higher up: should I therefore inhouse or contract, and if contract, how to allocate?" Predictability and quality from high val contractors matters more once you are in the budget green zone than focusing only on $.
We build GPU graph-based visual and automation tech for investigating event and rich (high dimensional) data, and while our ultimate focus is a self-serve product, do project-based and annual fixed support contracts because we can fairly provide that combo of ROI, predictability, and quality. The situation is a bit diff as this mean we offer an effectively discounted product license / services combo, which aids the derisking in a couple dimensions.
Consulting is a relationship business. The quality of your relationships determines how much you can sell your services for. Furthermore, solo consultants tend to specialize in a few specific niches where their services aren't a commodity. For commoditized consulting services, buyers will just go to a body shop.
The same applies to advisory type consulting as well. Even people who are more generalist than others are still fairly specialized in the grand scheme of things. On the one hand, you don't want to be so specialized that almost no one is a potential customer. But get too broad and you're getting out of the realm of having knowledge/experience that people will pay a real premium for.
I've long felt I had to keep pulling myself back a bit from dabbling in too many things at a relatively cursory level.
I was actually meaning it in terms of advisory consulting since that's what I do :)
But my experience has been very similar to yours -- I find myself focusing more and more on product strategy and less on engineering process as I move forward in my career. Clients are increasingly going to body shops for that kind of work, and I have no interest in competing in a race to the bottom.
It is products designed, made and shipped from you in the past that help set your personal brand as a consultant. You show something so that prospective clients can assess and trust your potential contribution in advance. Portfolio is the name, right?
Rather than say one way to bill is better than the other, I view this as situational. I've worked a fixed price project on occasion, but most of my work is hourly. The approach is a result of the negotiation process.
I also believe ethics is subjective. A consultant is running a business and has a fiduciary duty and a right to make money. If I can make money and keep the customer happy then all is good.
From my own 4 years' experience, I echo what zenpaul said, and would add:
* Understand who your client is, and stop and check in if they change. I once had a manager at a client company change mid-project, and the politics (and sense of trust) completely reversed -- in retrospect, I should have insisted that we start the relationship over, clarify expectations, etc.
* It's not always a good idea to agree to disagree. I estimated one sub-project would take 3 weeks, and a client insisted it should take more like one; we decided to proceed, it took 3 weeks, and the client was unhappy. Looking back, I think we should have more seriously considered dropping the project if we couldn't agree on expectations. This can be proposed gently and respectfully: if you don't think that plan is worth it, I'm happy to do my best to help you find someone else.
> I couldn’t believe my ears. After regaining my composure, I answered: “I regard such behaviour as unethical, because our customer would suffer a substantial and unnecessary loss.” [...] In hindsight, I should have terminated the project at that point [...]. The example shows how ingrained hourly billing is. Customers accept it as God given, although they know that they are ripped off.
But that's the thing. Companies exist solely to make money.
Let's say it again.
Companies do not exist to create value.
Companies do not exist to do cool things.
Those are all secondary.
Companies exist solely to make money.
This is business school 101.
The CEO and the rest of the workers were right in this instance. In this decision the agency was better off as a company if the person took the deal. The client at all times had the choice of going to a different firm that was cheaper, the customer in this case opted not to bother with doing those things (which might have cost them more in the long run anyway), and therefore had already committed to the cost that they would be charged.
The job of the client company in this case is to extract as much value as it can from the consultants while paying them as little as it can. Clearly in this instance, given they were happy paying that cost, you weren't being paid as much as you could have been, based on the 'value' that you 'created'.
I don't see why the person in question sees this as unethical. Or rather, I don't see why the person in question sees this as unethical under capitalism. Capitalism is an inherently unethical system, where the entire system is (From the top perspective) about ripping other people off as much as you can, or (From the bottom perspective) trying to ensure you get paid as much as you are worth to the company that you serve.
If you don't like it, back projects to change the system, whether that's to introduce more regulation, or to change the system full stop so that gross wealth-hoarding cannot exist. Until then, you have to make a living and try and make sure that you and the people you support are better off. If you can 'create value' for others by doing that, then all the better!
I just want to say a big thank you to the author for sharing the derivation of a consultant's profit.
I've always struggled as a consultant, generally scraping by and feeling spread too thin. That’s because I subconsciously gave up on the idea of profiting from my business. If you stop and think about that for a moment, it means that I had internalized this idea that I would always be working linearly at my hourly rate. There would never be residual passive income from work that I had done, whether it was SAAS or building an app or frankly just reselling something that I had already made. That death of faith in a better future is one of the most toxic and detrimental blows to a maker’s psyche that I know of.
The full profit formula is:
profit = (price you charge) - (your cost as hourly rate * hours)
Your cost here is the time that you would have put in coding, as if it were any other job. On top of that, you have the periodic struggle to find more gigs, as well as the logistics of handling your own taxes, health insurance, etc. So if you don’t charge something above your own cost, you’ll burn the candle at both ends just getting by, and eventually burn out after 2-4 years just like at any other job (tech especially).
I’ve always said that I feel that consultants should charge at least their overtime rate to account for the overhead and headaches involved. So if you make $30 per hour as a developer, your overtime rate (time and a half) is $45 and I would recommend starting around there or round up to $50. That's only part of the answer though, because an agency will charge between 1.5 and 4 times your hourly rate, so between $50 and $120 per hour, often more. So really you are competing with agencies. Which means that there is nothing wrong with charging the same as them, and probably more if you are experienced in your target market.
But there are also physical laws to consider. It’s hard to beat a pair of coders making something, so that limits an agency’s maximum value to a customer to just twice what a single consultant can provide. Keep in mind that this ignores an agency’s existing infrastructure, ability to absorb failure costs, and scalability. But if we’re just talking raw coding velocity, an agency is limited to about twice the velocity of a consultant, no matter how many people they through at a problem (see The Mythical Man Month). Knowing that, it makes sense to me that a consultant might typically charge about half the flat rate fee of an agency. And if they always deliver, why not charge the same amount!
It's not true that, by running a "make customers contact you" strategy, your acquisition costs are zero, quite the contrary. In order to make customers contact you, you need to take a lot of risky bets on the acquisition-side of things.
Things you might do to build a strong brand, like writing books and having a presence at events come with a likelihood that they won't be effective. By sinking time into those things, they present a risk of derailing work that actually pays. Doing a lot of PR & media work is a double-edged sword from the pov of clients who see the work you do as a trade secret. They want people on the job who know how to keep their mouths shut.
And the stream of project opportunities you get from that kind of project-acquisition is highly volatile and unpredictable. Chances are, when an opportunity comes in, you will be engaged in another project, and when a project ends, you won't have an opportunity waiting for you at that moment.
This only works, if you can scale it up enough so that the central limits theorem starts working in your favour and presents you with a constant stream of opportunities. But as a solo-consultant you wouldn't actually have the capacity to do anything with them, other than turn 99% of those opportunities down. At which point the relationship between the costs behind those acquisition effforts, and the rate at which you monetize them make the whole economics of the strategy break down. So you need to scale up your capacity and become a big agency, instead of a solo consultant, to make it work.
Element B: BARGAINING POWER
The other thing: Value-based fee sounds great, but what do you do in a situation where other people who get paid by the hour compete for the work you want to charge a value-based fee on? It's a race to the bottom, and can only work in areas that are so niche and highly-specialized that you are basically without competition, or where it would be prohibitively expensive for your prospective customers to line up alternative offers to compete with yours.
CONCLUSION
But then, the requirement to have scale, and the requirement to serve highly specialized areas so that you can have a lot of bargaining power are difficult to reconcile.
...so, all of this is just not as easy as the author of this article is making it out to be. If it were, everybody would be doing it, and nobody would allow themselves to get paid by the hour and do project acquisition by contacting the client rather than having the client contact them.
There is a broader picture to these lessons that I would like to point out:
Not only is it economical to do bad work if you bill by the hour;
but it is also necessary to build flawed products to sell more of them.
See printer inc, light bulbs, computers, everything that could last 100 years but doesn't...
The other side of this is that energy is considered free, if we paid the real price for oil/electricity it would cost many thousands dollars per gallon/kwh.
The only way for this to change is for the whole system to collapse, and that will happen during this decade.
All arbitrary (not based on experience from nature) human skills are going away.
But math, physics, chemistry and biology will stay; prioritize in that order.
Build a good computer today, it will not become obsolete technically for the rest of your life.
Buy a ARM computer that you use as desktop, it will be usable for the rest of your life AND it will teach you to become a better programmer!
Lessons from 20+ years as a solo consultant:
- Customers rarely know what they want.
- Customers always change what they want.
- Change control in fixed bid work is vastly more important than how smart or productive you are.
- It takes an extraordinary amount of effort to find customers.
- One gets customers by searching, networking, having other good customers and mastering useful technologies.
- What matters long term is consistently making money every month.
If you truly want to be a solo consultant:
- Maintain good relationships with your customers.
- Bill hourly and get paid no later than monthly.
- Be willing to work with consulting agencies and accept their markup on your rate.
- Always be learning and using new technologies.
- Always be looking for the next opportunity.