Obviously rates vary dramatically according to many factors other than the desire of the freelancer/consultant/whatever who wants to charge them: location, industry, level of experience/credibility/relevant specialist skills, and so on. But without even a general indication of how much the poster child consultants of HN have succeeded in putting their own rates up before dispensing this advice endlessly to everyone else, it's hard to take seriously the idea that an average freelancer who isn't Internet famous is going to jump from their normal rate to something on a different kind of level, at least not without fundamentally changing the way they're working in a lot more ways than just the cost per unit time on invoices.
Let me ask a very simple question, which hopefully those consultants might be able to answer without giving away anything sensitive about the specific rates they are personally charging right now: if the going rate for freelance software development work in your area is typically in the range $x-$y, and you have moved via successive rate increases and repositioning what you offer to $z, approximately what are the ratios between x, y and z? For extra marks, since in the podcast a comparison was drawn with the way lawyers charge, how would z compare to a typical range for lawyers working in the same area and with the same kinds of clients?
It's not necessarily due to undercharging that I advise folk to "raise your rates" - it's because it's a fantastic client discovery mechanism.
You want clients who pay more. The clients who pay more tend to get more value from your work.
So at any point the clients you have that are willing to pay more are generally better clients (for you and for them). So if you raise your rates and only support those clients you get a set of better clients who are going to be happier with your work, and give you more money.
Those clients, in turn, allow you to find similar good clients. Through recommendation and marketing for those clients. So you grow your set of good clients.
You'll then find a subset of those will be willing to pay more - because you provide more value for them.
Repeat. You will find that some of the work you do changes radically - at least in the way you sell it - during this period.
Raising rates isn't (just) about extracting the most money from your clients as possible. It's a way to help you find the clients who you will serve best - and because of that they're more than happy to pay you more.
To answer your end questions (and this is a little bit unfair since this is the second time I've started my own consultancy so have probably moved through the levels a bit faster this time - and I have a very strong idea of where my value-niche is).
If normal hourly is $x to $y - then I very deliberately started at $y just under 2.5 year ago (I very much do not want the clients who want the cheapest possible solution - learned that lesson ten years back ;-).
Currently my effective hourly rate (I don't actually charge by the hour any more so clients never see that number) is about what my day rate was when I started - so about 1:8, 1:9... something like that. Looking back with 20:20 hindsight I could have made that transition quicker if I'd been braver.
After a conversation a little while back I have discovered there are people doing similar stuff to what I'm doing with a slightly different kind of client for about five times what I'm charging. This is being actively addressed ;-)
Do you think Patrick or Brennan are übermenschen? Can they program 30x as good as you? They focus on bringing value to clients, discarding pride in technical perfection (well maybe they do, but your customers don't want to hear it anyway). It's taking development focus from "how you do" it to "what you do". Once you do that, your methods change over time - at least that's what I got out of this podcast. Of course you can't demand 100k for an app from a bootstrapped startup - but you can demand 100k for an app which makes a bank some more millions per year.
I just wish that if people who have been consulting for a relatively short time themselves want to share their advice with others who might be thinking of going down that path, they would give some sort of meaningful context to guide those other people about what to expect in practice. Otherwise, we're going to have a whole load of people who were actually on perfectly respectable if not exceptional rates, who were happy doing the work they were doing, whose clients were happy with the work they were doing, and who can't conveniently tie their personal contribution to an X% increase in the total profits of their clients, yet who then think they should be charging 10x as much and start going after new clients with unrealistic expectations. In most places, the software development industry is still quite a small world, and I'm genuinely concerned that such an approach is going to damage young developers' careers.
To be frank, I'm deeply skeptical about the current round of Tim Ferriss-style "Make More Money Than God In Five Minutes" discussions on HN. There are some interesting perspectives, and I'm certainly not criticising Patrick or any of the other guys for volunteering their points of view. But I do think quite a lot of that advice is going to be hard for many people to apply in practice, because the context won't be the same, and I do think it's borderline irresponsible to push the advice in as general and unqualified a form as sometimes happens, even if it happens with the best of intentions.
My method is pretty simple: understand the client's business, get to the root of why they're thinking they need Project X, and then only proposing solutions that have a high likelihood to return a positive investment (this sometimes means having hotly debated arguments with said clients.) In short, in no way do I position myself as "tell me what you want and I'll build it."
The end result has been positive growth and ROI for my clients, which makes my hourly rate immaterial if the product I deliver yields steep dividends.
Suffice it to say that I was charging a rate many American engineers my age would have been (too) happy to take when I started out, and my most recent rate is 7.5X that, and in a few months I'll be putting 10X on proposals and winning a similar percentage of them.
Lawyers who made their last client millions attributable to a two week engagement probably do better than me, but the typical lawyer working for my clients didn't do that recently, so without knowing anything about their rate card I'm going to assume it's below mine.
We're really not just blowing smoke here.
My area is Raleigh, NC, and currently all of my active clients are in NC.
This dovetails quite a bit with the Ramit Sethi interviews earlier, but is largely about the mechanics of businesses as they get away from the solo consultant stage. There is some very important math in there for folks looking to expand by hiring. (Copious hat tips due to Thomas for much of the advice here. Except the bad stuff, that's mine.)
1. Patrick's consulting rate has more than septupled since he began consulting (or possibly just this year, can't remember.)
2. The longest he has ever waited to get paid by a client he would be happy to work with again is nine months.
3. On a related note: The bigger your client is the more bureaucratic BSthey will have so they get the special “I expect dealing with you on a business level to be hell” surcharge.
4. Becoming a consultancy is a different deal from being a consultant, even an extremely high end one. Brennan made less as yhe principal of a consultancy than as a consultant for the first year and a half. If you take the commendable attitude that making payroll is sacred you should have $30K set aside for “Despite cashflow issues, we made payroll” purposes.
5. On a related note: When the business has a bumper year employees get a 3-5% payrise. When things are looking like shit they still get paid what was previously negotiated, on time. Most people are, quite sensibly, risk averse. If they want the upside they can take the downside too.
There is a great deal more that's very valuablr in the transcript, like the discussion of the change in attitude that comes with charging more nut those struck me especially. Oh, and there's a link to a tptacek ccomment that is step by step guide to making LOTS AND LOTS OF MONEY.
4. That's 30k per employee.
I'd have edited the original post but commenting on HN from a Lenovo phablet is hell.
1. Charge more.....
2. Sell yourself as someone who solves business problems, not as someone who implements technical solutions
3. http://thunderboltlabs.com/ - An excellent example of how to sell yourself as a developer, without selling yourself as a commodity coder. Their hourly rate does makes my brain melt.
4. Learn the language of yours customers. This is something I've really got to work on, I have now idea how business people speak.
5. When you're teaching a potential customer new things in your sales pitch you've already won the sale.
I'm not sure I've summarised number five very well. So here's an example from my own limited experience. When I've stepped into a design agency who's looking for a developer and I start talking about version control, the latest technologies, previous projects and how I could make their business better I've actually felt the atmosphere change in the room. At that point I know I'm walking out of there with a new client.
There's more hidden gems in this Podcast and I'm sure I'll be reading / listening to it again before the days out.
So much to learn.... being self employed is awesome.
Not just their language, but their lifestyle and culture.
A big portion of my clients are Jewish; this is because an early client was Jewish and I learned the little things like... sending emails late on Friday afternoons will rarely get a response till Monday. Or, Mondays are bad days to be in touch because a lot of Jewish holdays fall on them. Etc. etc.
I picked up a ton of clients because word got around that "hey, there's this guy who is easy to work with"
> Their hourly rate does makes my brain melt.
Is that the hourly rate for both of them? (they say they work in "pair programming style"). Given the mass of skills and experience they bring that seems and extremely good rate.
I assumed it was for one person but now you've mentioned it, that is probably for them both. In which case I guess it's less extreme on my brain.
BTW: I would pay a small subscription fee to have podcasts (and audiobooks) summarized like you just did.
My career path has always been very conservative, e.g. "What skills do I need to be employed by corporations at salary X?" Even today, I struggle with a strong and compelling internal voice that says "oh, learn blub and enterprise platform ZZZZ" and then you will be seen as more valuable.
I know this is a extremely limiting mindset, but breaking free to a new viewpoint has proven difficult.
Worth it for that line alone. There's a special art in being the one who gets the idea through purely because you're a third party and not the internal person/team. Some of my happiest gigs are when I've ended up getting paid to teach management to listen to the team and implement their suggestions. Everybody wins ;-)
As an economics PhD drop-out who left [after year #2] to start my own consulting company based on my PhD research, I can relate with so much of what I've heard so far (I'm only at 22mins at this point).
Also, as a person who went from the economics/business (albeit, academic) life -> developer life, I agree with your observations about how programmers suck at economics (err... business). It is a much easier transition (relatively speaking) to go from an econ/business person --> compsci/developer than it is compsci/developer --> econ/business person. You can't learn economics overnight, but I can certainly figure out how to create a tool that solves a specific problem overnight, because some guy wrote a tutorial about how to use <some technology> to solve <a congruent problem>.
I'll try and update my post later after I've finished the podcast.
Scenario: A client asks me to do support and maintenance on an internal accounts receivables tracking app. How do I justify asking 300/hour or whatever you guys are suggesting? How do I give them substantial business value from that?
What happens if we cut the time wasted by 10% and bring in one or two extra invoices a month? Oh, we just made you several hundred thousand dollars in the first year? Interesting. What is that worth to you?
"I'll write up a document explaining the plan, but in broad strokes, we're going to work on the user experience so the team spends less time fighting this tool and more time being effective in chasing receivables. Also, we'll build a new workflow which automates the early stage of receivables collection." (I would start thinking "Automated emails or Twilio replacing a human employee doing either is pure win in the early stages of collection" but you're the guy in the client's office, figure out what they'll except.)
So if their system is already highly optimized, or it's a small company so any gains wouldn't translate into large amounts of money, you'd suggest to pass on the opportunity?
Also, what happens if you improve the UX and make new workflows but the profits don't materialize for some reason? Would you not get paid?
ProTip: Make friends in the purchasing department and learn their rules. There are often ways to game the system...
For example: Some may have a global rule that they must take advantage of any discount greater than N% on the invoice if it's just a case of moving the payment date. Offer an N+1% discount for payment up front to that department and you will automatically have payment up front. Suddenly your cashflow looks much happier ;-)
(edit: Also - you never punish people for late payment. You reward people for early payment. Of course the numbers may look the same either way ;-)
"Your bill is $10k, pay after Dec 15 and you get fined an additional $5k"
say
"Pay by Dec 15 and get our discount rate of $10k, otherwise get our standard rate of $15k"
Numbers are the same. Very different reaction from people.
Discounts are something people want. Having time-limited discounts is a classic sales technique. People don't want to lose out.
Some departments are required to take discounts, but encouraged to fight late fees.
Fines are annoying, but the effectively give you a structure and excuse for doing the bad thing.
There is no logical difference - but people aren't logical.
Emails in my profile, let me know if you'd like to be on the announcement list (going to cap the workshop at 25 people)
What steps can someone in my position take while in the middle of (multi-month) projects?
I'd probably also take the opportunity to raise rates.
Of course, that depends on the expense. Generally I'd say if you need to overnight then it is an expense to charge for - if you're driving for an hour then definitely don't :) (in the UK we can get tax relief for mileage in relation to our business, so I generally don't charge for travel if I have to drive less than 3 hours - otherwise I end up being "paid" twice :D). Taking the piss with expenses (one place I worked hired an consultant analyst who literally charged for everything - including the 30p it cost him to use the toilet at the train station) is as bad as not charging them.
If they want you because you bring value they will happily pay this cost. On the other hand if they are put off by this added fee then they are probably not the sort of client you want - especially as those costs are probably a small portion of what they are paying you for a days work!
On the other hand; if you soak up expenses to get that contract you are a) in the mindset of letting them set the rate (even if they never knew about it) and b) eating into your profits. Neither is a good situation to be in (next time they might want you all week, and that can get expensive fast).
However; I don't know about your situation, but if you don't live in the valley why are you trying to compete in the market there? I live in the countryside in the UK and used to believe my main market would always be London (~3 1/2 hours away by car, less by train). I've learned this is nonsense, and even the nearest towns to me have LOTS of developer work available.
You might also think that being out of the hub means less money. I've also found this to be untrue in practice, because no one works out here (they are all focusing on the big cities). Desperation for quality talent means that often, more money is on the table.
I quoted a project which I (thankfully) didn't get, based on the person I was talking to being in SC (few hours drive or short flight). Turned out the project would be onsite in North Dakota, which was a $1200 flight.
That was a lesson learned :)
Other than that, I still am primarily hourly, because I have multiple ongoing projects that don't lend themselves to 'day rate' work. Newer stuff I take on next year will likely be 'day rate' based, with travel and hotel expenses outside a short driving radius line-itemed.
Also, does this kind of value-driven work also work remotely, or do you always travel to customers?
You make mobile apps for businesses, right? So you're getting their brands carried on the trusted device that their customers hold their entire social selves on, which is carried in their front pocket 24/7, which they caress when in bed and which they can't bear to be separated from even when in the bathroom. And your app. Their brand. With them the entire time.
Or, if you're making apps with a transactional component to them, like say the Chipotle online ordering app, "Um, it's going to make you several hundred million dollars this year. This will be mentioned in your annual report. You're going to look like a hero for greenlighting this project." works, too.
Conversely; I have an engineering background but found it very easy to pick up the basics of good business, at least how it applies to consultancy. Of course, I'm not trained in economics, but I figured out enough to get by (you could make an argument business sense isn't really related to economics - some wildly successful businessmen have never been educated in even the basics, they just saw and opening and sold).
What you seem to be suggesting is that an econ/business person could buy a programming 101 book and start making big bucks as a consultant software engineer. In theory I'd like to say that's rubbish, in practice I know of several people who do this.
Can't condone it though: the underlying drive for a consultant should always be - "I have a valuable skill, here is what it is worth"
You do need sharp wits and problem solving ability to deliver this kind of value, you need your methods in place (e.g. testing and validating everything) and you need to know where to look for unknowns. A good pitch is not the whole story as much as problem solving abilities are not the whole story.
I've been in software dev for 18 years or so. I set up a small shop 12 years ago, went bust after 4 years, then went solo again in 2007. I've not expanded beyond myself (so far), but have been hopefully getting better at what I do, both in terms of software but also business skills.
A couple of years ago I started seeing an uptick in questions from people in the area: "How much do you charge? How do you decide what to charge? How do you write a contract? How do you get clients? How should I do XYZ? What tools do you use?", etc.
People who know me know I love to talk, so I'd happily answer. I started to realize though, that I was only giving one perspective. Even when I'd qualify that perspective as "this is just my experience", it didn't help them very much. I started getting other people I knew involved in the discussions, getting their perspectives, which were sometimes vastly different than mine, and they'd arrive at different conclusions. Eye-opening to say the least.
At the point, the idea of the conference (http://indieconf.com) was born - an event to bring people together to foster the learning, Q&A and networking which helps those questions get answered with far more perspectives than I could offer on my own.
Reading a book is not necessarily bad, but being able to ask questions about those books' ideas face to face, get answers, and have discussions about those topics has worked out decently for the conference over the past couple years.
I like avoiding two separate sets of price negotiations.
Ouch. It looks like they've got the skills and marketing figured out. I think there's a great lesson in there for all of us freelancers.
Would you not get paid?
No, of course you get paid. The client bears all execution risk. That's why, when you make them 10 million, they get the vast majority of that 10 million. If clients expect you to shoulder downside risk then they should expect you to capture much of the upside. (Here's words I like: "Well, if you expect me to bear the risk for this project, I want to share equitably in the rewards, too. My sense of equitable is that if I'm responsible for doubling the company's sales I should end up owning half the company. Or, you know, you could just pay my rates.")
That's pretty awesome. Have you ever had to use a line like that?
You could not talk in terms of profits (which could be eaten up by something else), but percentage reduction in unpaid invoices. Maybe look at reduction in overtime for AR staff, or number of invoices handled per staff member ("1.5 times as effective now!")
We're really not just blowing smoke here.
I'm not claiming you are. On the contrary, I agree your argument, under the right conditions. However, I am concerned that you are generalising way, way too much and you're setting up a lot of naive but entrepreneurial young developers for a nasty reality check.
Here in the UK, the vast majority of freelance/contract work isn't the kind of lucrative consultancy gig that various HN regulars seem to be arguing everyone should move towards. Obviously there is a significant amount of high-end consultancy work around, but mostly the freelance market is more about having a flexible workforce, where local businesses can bring in extra resources on demand without the overheads of full employment and freelancers retain a lot more flexibility than full-time employees working for a single employer. The freelancers are often still working with others, it's just for a specific project and with arm's length management etc.
Now, please consider that there is usually no way for someone in that position to demonstrate the kind of direct value contribution that is the basis for your arguments to clients that much higher rates are justified. If nothing else, it may be impossible to properly separate the value of contributions from different contractors working on the same project.
Moreover, it's all very well arguing that your contribution has raised £X for the client (for some impressively large X) and so you are worth a significant chunk of that £X in fees, but this relies on the fact that the client can't buy a contribution of equal worth to them for a lower price elsewhere. There are numerous highly skilled freelancers who by their nature are always looking for the next job, and unless some sort of mass unionisation happens or you're talking about an extremely specific niche where literally only a tiny number of consultants could do the job at all, you simply aren't going to be competitive at 10x the going rate. Sure, maybe you're worth it, but that still doesn't help if any of 20 other people with a similar skill set is willing to do the job to a similar standard but for only 2x the going rate.
So while I have no objection to pointing out that developing valuable skills and then pitching yourself as a consultant in a certain field can be extremely lucrative relative to being a freelance code monkey, I do think it's misleading at best to suggest that all, or even most, freelance software developers can just put their rates up rapidly and change themselves into consultants in the way that worked for you guys (and to some extent for me, I suppose). The strategy doesn't scale to the freelance software development industry as a whole, and in many cases it would never work if individuals tried to do it alone without taking the relevant part of their profession along with them en masse. Even if it did, it would probably mean doing a very different job and potentially giving up some of the benefits or choices that motivate many people to turn to freelancing in the first place.
This is why Mr. McKenzie is forever telling people "don't be a commodity." You are describing competition among commodity programmers. Don't be a commodity. You can - and I am paraphrasing him here - take yourself almost entirely out of the "commodity programmer" pool by a number of simple changes, such as not calling yourself a programmer, quantifying the business value you're adding, and negotiating confidently (part of which is not anchoring the price of your work to the price of commodity work).
You have more power than you think to stop being an interchangeable part. Being an interchangeable part sucks, you're right! Mr. McKenzie is trying to point out to you that you can stop.
I've never noticed Patrick himself use that exact phrase, so I'm a little wary of putting words into his mouth here, but let's consider your point in isolation.
The basic principle here is that in order not to be that kind of commodity programmer, you must have some combination of skills, knowledge and resources available that is both rare and valuable.
Programming is hardly an esoteric skill set, and neither is being able to speak "business" to business people. Do these skills have value? Absolutely, often a great deal of it. And sure, not everyone in software development is a great developer, and not everyone in software development is good at communicating with non-technical people who play other roles in the wider organisation. But for the argument to work in more than a handful of exceptional cases, it doesn't need "not everyone" to have those skills, it needs "almost no-one" to have those skills. If what you offer isn't rare, chances are you're offering a commodity service whether you realise it or not.
In reality, there are many, many people out there with the technical and communication skills to make the kinds of high-value contribution that Patrick and co talk about. Many people do it all the time, whether as freelancers or employees. And while a lot of those people would have difficulty formally quantifying the value they offer, not least because they might be working as part of a team whose results are only measured in aggregate, I don't think the real problem is a lack of recognition from smart management (those wonderful people that consultants like to call "good clients") of the contributions made. That is usually only a factor if you're working for someone who really is a bad employer/client, in which case there are many employers/clients you could work with instead who would acknowledge your contribution more honestly.
But even in a positive environment, it is not easy to stand out and change how you are viewed. You can't just raise your rates dramatically above most other people's rates if you're working in a competitive market, which freelance/contract software development certainly is. So you have to create a new market, where the rules are different. But at that point, you're not really doing anything like freelance/contract work any more, you're building a complete new business, with all the pros and cons that come with that.
Now, I don't think anyone would disagree that running your own independent business is by far the most lucrative way to make money in a field like software development. I certainly wouldn't, and on HN of all places I don't have to tell anyone about the potential returns of entrepreneurialism. All I'm saying is that it's a completely different job to being a freelancer/contractor who happens to charge much higher rates and put "Senior Consultant" on their business card, and I dispute any general claim that the transition is necessarily either possible or in the best interests of most people who work successfully as freelance contractors today.
http://news.ycombinator.com/item?id=3261769
http://news.ycombinator.com/item?id=4555558
http://news.ycombinator.com/item?id=4556091
Those are only the most recent.