Hacker News Reader

Hiring people to sell is dangerous. Effective salespeople are money-printing machines. If they didn't know that about themselves, they wouldn't be effective salespeople. So there is a serious adverse selection problem here: the most effective salespeople have their pick of who to work for. The hiring pool for salespeople is full of --- dominated by, probably --- salespeople who are much better at selling you on why you should keep paying them despite them closing no deals than on selling your customers anything.

You should learn how to "sell". That means a bunch of different things depending on how you decide to sell and is a basic business decision you should make early on. Make the decision such that your team can do the sales work. Hire sales when you have your process proven and nailed down.

37signals really got hiring right: you should (generally) hire a role after you've figured out how to do it yourself and doing it over and over again is becoming a material drag on the company.

If you feel like you need a deposit to start a project, don't do the project. In 14 years of consulting, including software development projects, I've never taken a prepayment. I can't remember a real problem I've had. I can, however, think of a lot of clients I've said "no" to because they didn't seem to have their shit together.

No offense but on the pre payment thing you sound like someone who was fortunate enough to have a vast network of clients you already knew and trust. Which is not the case for most.

I've never asked for a pre-payment, but I've figured out a small project to do for them and made clear that at each milestone they're welcome to walk and I'll support their new person with whatever documentation they need though I won't offer "support" in the sense of hours of my life training people unless I'm getting paid, which is usually not a big deal. They don't seem to have a worry about paying you to train the new person, but do seem to worry that your emotions about being let go will impact the timeline.

Their real worry is that you'll suck and delay things, by making clear that you understand that such things happen and will help as you can if it does you improve trust. And you should really be doing that anyway ethically. And realize that sometimes you're just not the right person for the job and to help them find the right person if you want to build a strong network.

Things were pretty lean when we started, but sure, that might be true.

I've taken plenty of pre-payments. I agree that you shouldn't "need" one, but there's absolutely nothing wrong with requiring one. It sends the same message as a high rate, and gets everyone in the habit of paying for service / collecting payment for service from day one.

Otherwise, agreed on all points

I'd just say this: our current business has sharply better cash flow than Matasano's did (Matasano also didn't require pre-payments, but it did work primarily with larger firms, where this business works exclusively with startups), and our business would not be possible with prepayment. I only see downsides to prepayment, and my bias is to assume the need for them comes from accepting clients you should be rejecting out of hand. But I concede that this may be a quirk of my own experience.

> our business would not be possible with prepayment

Not exactly sure how this is possible. Any mature business will split up a project into milestones. Whether payment is due at the beginning of a milestone or at the end, makes little difference to the business overall.

I prefer to charge new clients at the beginning of each milestone, starting work after they pay. Existing clients I'm happy to charge after the work is completed, because there's a working relationship there already.

Before I started doing this, I had payment issues several times a year. Since I started doing this, I haven't had a single payment concern and have never had to even think about it.

The problem is how to know which clients are trustworthy before the first project. For small shops, even one missed payment can mean a lot of trouble...

For new clients, I always do 50% up front. There’s no way I am doing a month of work on a handshake and a signature.

As far as I know, doing this is utterly routine among big-ticket consulting firms.

Oh, I guess they just call it a retainer. I guess I've never bothered.

No, I'm not talking about a retainer; in fact, a retainer is almost the opposite arrangement, where you take payment up front for a bucket of hours to be used (or lost, gym pricing style) over the period of engagement.

“Discovery” fee, of around 10%

Then paying 30% at three intervals during the project

Which is routine -- charging 50% up front?

Working for a month without prepayment, invoicing, and then waiting 3-6 months to get paid.

I fully understand that people starting out in consulting work don't want to do this, or can't. That's OK. But I don't think it's a good idea to build this constraint into your practice as a principle; it will keep you from growing your business.

The way Jeremy and I started Matasano --- it's probably more accurate to say the way Jeremy started it, since he's ultimately the person who founded Matasano, back when it had its original name, for his cat --- was to do "serious" consulting projects on the side while working a full-time job. I don't think he was taking prepayment for those projects, and if he was, I sure didn't see any of that money. So that's one way to maybe start consulting without depending existentially on up-front payment.

I also understand that there is a class of client --- one I think people new to consulting believe is much easier to acquire --- that can't reasonably be trusted without prepayment. I agree that's a thing, too. If you need these clients to boot up, that's fine, and I'm not dragging people for taking them. But here's a constraint you should build into your practice: your mid-term goal should be to say no to these clients, full stop, not trying to find a way to fit them into your pipeline.

Also: I can only tell you what's worked out for me and the weird group of people I know. I feel pretty confident about this stuff as business advice but I could obviously be wrong. I'm not going to waste everyone's time tediously disclaiming that though (this one tedious disclaimer excepted).

These are all excellent and were all things that I practiced/discovered in my consulting days.

The only thing I would add is: Never reduce your hourly rate for any client.

For repeat clients they will expect that rate again. Many of your clients may know each other. They talk to each other and soon many of them will be asking why you can't give them a discount. You can offer discounts in exchange for an action (like quick payment mentioned above).

Never devalue your time.

+1 - I gave a reduced rate to a client who was tight on funds as a favor. They began referring friends (thinking they were returning the favor) but the new clients had the expectation of low cost. Clients attracted by low rates are rarely the kind you want to attract.

I generally agree, although whenever a rate is reduced for any reason, it should be stated out loud and in writing and on every invoice with a clear end date or specification for the reduction. Never let the special deal be forgotten as anything other than a special deal and after the deal is up, raise your rates back to normal without hesitation or apology.

Never reduce your rate. Always make it clear on the invoice what your rate is, and apply a clearly explained discount to the invoice. Discounts are temporary, rates are sticky.

Just offer to help them scope something you can do within their budget, and maybe it involves training them to do it themselves. Or just a better (simpler) design anyway with better milestones and focus on deliverable prototypes.

> The only thing I would add is: Never reduce your hourly rate for any client. ... Never devalue your time.

I generally agree with this, but there are some exceptions:

1. For large, repeat clients that have demonstrated loyalty, it's okay to offer a modest discount, no more than 10%. You still cite your rack rate on the invoice, but at the end add a "Loyalty Discount" so they know they are getting this discount for a reason.

2. While you should not reduce your rate, it can be okay to write off your time. If it takes you 20 hours to do something, but you're afraid the client will balk at the bill and run away, rather than lowering your rate, invoice them for 10 hours, or whatever seems reasonable.

3. When you're just starting out, and have limited understanding of the value of your skills compared to the competition, you may not know what your rate should be. In these cases, you may want to consider flat rate arrangements.

> While you should not reduce your rate, it can be okay to write off your time.

Strongly disagree. This is a failure of communication. If you're billing by the hour, your client should have a general idea of how long something will take. A lower bound and an upper bound. Time-box all tasks.

As soon as you know you're going to break through the upper bound, stop work, inform the client, provide a new estimate, and let them make the call.

Eating the difference defeats the purpose of working hourly.

> you may not know what your rate should be. In these cases, you may want to consider flat rate arrangements.

Disagree with this as well. If you don't know what your rate should be, how can you name a flat rate? You should know what your competition is asking for and ask for slightly more, because you're better.

> If you're billing by the hour, your client should have a general idea of how long something will take. A lower bound and an upper bound. Time-box all tasks.

In a world with perfect information, you'd be right. Unfortunately, people have to make decisions with incomplete and potentially misleading information all the time. Demanding perfect time-boxing ahead of time is a recipe for disaster.

> Demanding perfect time-boxing ahead of time is a recipe for disaster.

Dear client, this task will take 2 to 6 hours. If I find out it will take longer than this, I will reach out.

Dear client, I am 1.5 hours into this task. Based on my experience, it look like it will take 7 to 10 hours instead. Should I continue?

For all of this to work well, you need to have experience in estimating well and also understand that whatever number pops into your head, multiply it by 2 and tell the client that. I have never had a client be pissed at me because I finished something for less time/money than they were expecting.

That said, this sort of thing should really be used for highly indeterminate tasks, like fixing bugs.

Only when you do the wrong things will you learn what's right.

There's something to keep in mind about the nature of time. It's possible to make a billion dollars in a day, but it's not possible to spend more than 24 hours in a day.

Why couldn't you work less hours? Was it just a matter of hourly rate being too low for you to be satisfied with the income on fewer hours or is there something else?

Saying "no" is a challenge for human begins in all levels.

yes the backend of busines has got to be taken seriously. getting invoices out, paying bills, billing people etc these are the things that will kill your time. i am fortunate in that my spouse is a wiz at this so i can focus solely on doing the job.

What’s wrong with fixed-fee if a fully specified statement of work is made with clear, objective test criteria?

As someone who's done over a dozen fixed-fee jobs - DON'T DO IT. There are too many unknowns, even in "simple" jobs. It won't be worth your time and you'll regret it. In order to make fixed-fee contracts worth it I had to cut corners. I hated doing that, but I preferred it to dropping the contract altogether (sunk costs fallacy).

I've also found the clients who insist on fixed-fee contracts to be very demanding and petty. They tended to interpret the specs liberally. It's not worth the hassle. Trust me.

As someone who's been on both sides of the table - client and contractor - I completely agree. I never do or ask for fixed-fee.

When I'm the client, I feel fixed-fee gives the contractor an easy backstop/fallback position - they figure they can half-ass the job and use the additional time to scout for more work.

When I'm the contractor, it's the same, but in reverse - fixed-fee makes clients feel like they can demand the moon beyond spec at no additional cost.

Hourly/daily rates make sure that BOTH parties have something at risk, which tends to be keep everybody in line. The contractor's at risk of the client firing them. The client's money is at risk if they keep demanding endless revisions.

Actually a good lesson for business in general.

What's wrong with it is that every spec will always be open to interpretation. You will interpret it as the minimum amount of functionality; the client will interpret it as the maximum. The only spec that isn't open to interpretation is the code itself. :)

That it's often extremely difficult and lots of overhead to have such a thing, and clients typically are larger than you and have less to loose by arguing about it endlessly.

That really depends on the project. One of the reasons I only take very small projects is that the scope is typically limited and clearly understood so it's easier to offer a fixed bid with little risk.

Nothing is wrong. Some of the best contracts I had were fixed cost (which is my preferred way to work over hourly). But - you need to be familiar with the system you'll be developing in, very good in what you do and price it at several multiples of your hourly assessment.

I really, really don't like working hourly - I'm not selling my time after all, but my services.

as the client, i would always split the project into 2 parts - a functional spec and a technical spec. my job was to interpret and write the func spec as a kind of pseudo-code version of what i thought could be built. then i would commission a fixed price job of interpreting the func spec and re-writing it as a technical spec ie, click a button and take the user to a summary of xyz turns into a bit of SQL. the tech spec must be written so that any programmer could use it to understand what needed to be done. then I'd ask for a fixed price quote to deliver on the assumption that i could get multiple quotes if needed.

the benefit is that my coder who wrote the tech spec should be very comfortable with what is needed and i get to sell a lower risk $$ to my managers.