Ask YC: Salary vs. Hourly for the Startup | Hacker News Reader

Ask YC: Salary vs. Hourly for the Startup

12 pointsiamdave18 comments

I was talking with a friend earlier today who works in IT, and we got on the topic of Salaried pay versus Hourly. It was a good conversation given the scope of his employment, constantly working extra hours (overtime as he's on salaried pay) which lead me to wonder:

How would a startup work with payment as funding and financing are always questions of concern?

Discuss.

View on HN

I think it depends on where the startup is in its development. If there is no income, and the startup is very young, there should be no employees. The founders should all take a salary, even if it's just a token salary of their living expenses, for tax purposes.

In my opinion, anyone working on building the primary product of a company (the hackers) should be a founder, or have a significant equity share in the company, especially if the company has yet to earn a profit (assumed if the primary product isn't build yet).

If the startup is at the point where they are earning a steady income, and needs to hire additional people, then it depends on the role needed. Secretaries, customer support, and other administrative work should be hourly (or even better, contracted out). Sales should be commission (to the extent permitted by law). Additional hackers should be on salary with stock options and the expectation to do a lot of work beyond the typical 40 hour work week.

I'm interested in hearing what others think about my suggestions. Please let me know what's worked/worked better for you.

People do what you reward them for doing.

If you pay them per hour, they will work a lot of hours.

If give them decent profit-sharing, they will work on making your company profitable.

If you pay them per widget made, they will make a lot of widgets.

If you give them an equity stake in the company, they will be invested in being able to cash out that equity.

I have been at startups and established small firms with every thinkable permutation of pay, stock, and required hours. Frankly if you are at a point where you are ready to hire people, a FAIR salary (not even thinking of future profits or the potential value of stock options) is the only arrangement that aligns your interests with that of your staff.

Expecting people to work long hours routinely is a great recipe for failure, unless you are doing something totally uninspired and brainless to start with, in which case having zombies do the work is sure to work just as well.

If someone needs to be paid extra (hourly) in order to stay one extra hour in the evening, they're probably not an ideal startup employee.

Here is my two cents:

Salary, in USA, usually means an exempt worker, which is for those professions (software engineering included), where you can't directly measure their output. So, you pay somebody a fixed early salary, then the person can work 30 or 50 hour or whatever, that's something between you and the employee.

A non-exempt employee is sombody that the work can be measured directly (QA, secretaries, call center help support people, factory workers), and they are usually paid hourly, with overtime kicking after 40 hrs of work.

The only time you see a software engineer working hourly, is when they are hired in a contract basis (i.e. work for a given amount of time, 3-6 months etc.). Even this contract can't be longer that 18 months, as you will be breaching labor laws, as this person should probably be considered as full time, exempt employee.

Now,in a startup, if you hiring somebody full time (not contract work with fixed amount of time), you are probably breaching labour laws. A graphic designer working hourly is ok, a software engineer, no no.

In most startups I know, when the first employees are highered, they usually are highered salary basis, so they can work as many hours it is needed.

founders- salary for sure. I don't think you can really measure a founder's contribution by the hours they put in. As Founders, its understood we're putting in insane hours. If we were "charging" by the hour, most startups would be broke.

One off work- For development maintenance, some design work,etc. definitely go with hourly. Have your shit together when it comes to specs, design, what the project entails. If things go overboard, you might be kicking yourself. It's also a good way to see if that person might be worth joining the team, without making a huge up front commitment.

Hourly pay makes sense for disposable employees.

You are likely asking for trouble when applying it in a startup.

A case study from Charlie Munger:

One of my favorite cases about the power of incentives is the Federal Express case. The heart and soul of the integrity of the system is that all the packages have to be shifted rapidly in one central location each night. And the system has no integrity if the whole shift can't be done fast. And Federal Express had one hell of a time getting the thing to work. And they tried moral suasion, they tried everything in the world, and finally somebody got the happy thought that they were paying the night shift by the hour, and that maybe if they paid them by the shift, the system would work better. And lo and behold, that solution worked .

I find this interesting because I actually had a friend who worked the night shift there one summer in college (around 4 years ago). He was paid hourly.

A startup will need to hire strong talent and retain them during critical periods to have a hope of success. The enticement needs to go beyond a simple deal of annual or hourly agreement. Bonuses based on completion of goals and other kinds of benefits are important. Shares in the company is even more important. If you don't have the enticement, you can just quit tomorrow and paid just as much somewhere else. The cost to the employee who quits is a tiny amount of risk in transitioning to a new job. The cost to the startup can be huge due to delays in hiring and ramping up new employees.

For founders and employees, salary without question. Contractors are different and usually paid on an hourly basis or given a retainer that's supposed to correspond to some set number of hours. But if your core team wants to be paid hourly, something is terribly wrong--they either should be given more equity or simply don't have the right mindset.

When you can influence productivity via payment: Don't pay for time but for units of work done. That motivates the employee and gives you a better performance control.

But that's not true for supporting jobs (e.g. secretary) where it's up to your cost accounting whether you pay for time flat (monthly) or by workload (hour).

Careful about paying per unit of work. Your workers might throw quality out the window in order to get more quantity and thus more money...

Specify the unit's quality. Payment depends on compliance to the specification. One can agree to pay a basic monthly salary (we're talking about employees who are motivated by some income security) and make all else a variable income. One needs to find of course the balance between loyalty to the company (monthly steady income stream) and productivity (income by units). So it depends on both the startup and the workforce where to set the priorities.

Measuring quality of work in a startup is equivalent to predicting in the future how much of a contribution some work is making on the outcome.

Conformance to rigid specifications is not the way to go.

My entire text was "roughly speaking" because it depends on the startup's context and the founders' knowledge and abilities. I'm not talking about book-long specifications, but for sure you should have some requirements on unit functionality and code quality. And the unit's value is not about predicting the future but derives from your sales plan. This is about a startup already in a situation when it hires employees, so they usually have some historic data on the market and their own performance to base their guesses on.

Wait, wait. What is the appropriate unit of work for programming?

Lines of Code? We've been down that road, and it doesn't work well. Especially if you improve the project by deleting unneeded code - did you just do negative work?

Features? Some features are wildly more work to implement than others.

Bug fixes? Besides not being a sufficient measure of work making new code, making a bug fix the work metric penalizes conscientious programmers who find and fix all their bugs very quickly before they check in, or if they report them then they're wasting time writing about bugs that took less time to fix than they did to write about.

I think in an ideal world programmers should get paid by work units, but I don't think there's a way to measure it that doesn't create more overhead than it is worth. In the end, people get paid by the hour not because it's be best way, but because hours are easy to measure.

Think of employees as subcontractors. Their basic monthly salaries are your costs of having them on standby to work on your assignments. Then you can (more or less) calculate the value of a unit to your company / project and that's what you pay for it. Roughly speaking. So "unit" won't translate into "work unit" (like LoC and similar quantities) but into "subproject". And so we're talking about capital budgeting. A good hacker can understand and apply this creatively after some good books or courses (or the VC advisors provide the knowledge), 'cause in the end it's just some basic concepts + formulae.

If i was my startup, i would pay salary. You get so much more bang for your buck out of your users. Startups work day and night, that would cost too much at an hourly rate.

Reply on news.ycombinator.com