Just as a minor PSA: I get that certain consultant types around these parts are always saying "raise your rates", and I get that a lot of people who work freelance do undercharge and often significantly, but the advice has very limited value unless it has some sort of quantifiable element attached to it. Otherwise, with due respect to those consultant types, it sounds a lot like "We're obviously smarter than you, because we charge enough and we're sure you don't" without any real data to back up such a claim.<p>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.<p>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?
Happy to answer questions, to the extent possible.<p>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.)
Bits that were not obvious in retrospect and not previously covered in Patrick's writings or just obviously really important.<p>1. Patrick's consulting rate has more than septupled since he began consulting (or possibly just this year, can't remember.)<p>2. The longest he has ever waited to get paid by a client he would be happy to work with again is nine months.<p>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.<p>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 <i>commendable</i> attitude that making payroll is sacred you should have $30K set aside for “Despite cashflow issues, we made payroll” purposes.<p>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.<p>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.
This was my favourite Podcast so far. A few things I really took away from it ( which I'll be implementing in my own freelancing /consulting business ) in no particular order<p>1. Charge more.....<p>2. Sell yourself as someone who solves business problems, not as someone who implements technical solutions<p>3. <a href="http://thunderboltlabs.com/" rel="nofollow">http://thunderboltlabs.com/</a> - 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.<p>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.<p>5. When you're teaching a potential customer new things in your sales pitch you've already won the sale.<p>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.<p>There's more hidden gems in this Podcast and I'm sure I'll be reading / listening to it again before the days out.<p>So much to learn.... being self employed <i>is</i> awesome.
I would love to hear more about shifting the "offering commodity skills" to "I produce measurable business value" mindset. From Patrick or other HN'ers.<p>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.<p>I know this is a <i>extremely limiting</i> mindset, but breaking free to a new viewpoint has proven difficult.
<i>Your paycheck is, occasionally, a burnt-offering to the gods of Trusted Third Party Opinion, just like it is sometimes a magical talisman against Blowback If This Goes Sour.</i><p>Worth it for that line alone. There's a special art in being the one who gets the idea through <i>purely</i> 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 ;-)
Talk economics to me, baby.<p>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).<p>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>.<p>I'll try and update my post later after I've finished the podcast.
Ok, let's do a concrete example. All of this seems very hand-wavy to me.<p>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?
SHAMELESS PLUG: While I understand not everyone can attend, <a href="http://indieconf.com" rel="nofollow">http://indieconf.com</a> is a conference dedicated to these sorts of topics, and Brennan will be speaking there. If you'd like to meet him face to face, this is an opportunity to do so, while also meeting with other solo consultants/freelancers looking to grow.
<i>So if you’re dealing with, say hypothetically (not a client), Bank of America, you will not budge the Bank of America purchasing department, because they just don’t care</i><p>ProTip: Make friends in the purchasing department and learn their rules. There are often ways to game the system...<p>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 <i>much</i> happier ;-)<p>(edit: Also - you <i>never</i> punish people for late payment. You <i>reward</i> people for early payment. Of course the numbers may look the same either way ;-)