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).
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.