performance based pay

I am looking for any insights as to how to implement a performance based pay system for software developers.

I am taking on a couple of new people and want them to be paid 50 / 50 (with a higher than market rate pay if they make all 100%)

But I am unsure how to quantify the deliverables in a way that is fair to the company and the employee.

Has anyone worked in or set up a system like this that worked well (or badly?)

Can anyone recommend and literature?

Thanks for any ideas Ralph

Reply to
Ralph Mason
Loading thread data ...

Offer them a low salary and one or more of the following: a) non trivial royalties based on sales b) non trivial equity in the company c) non trivial cash bonuses at mutually agreed upon milestones (eg, end of feature add, end of test phase, first customer ship, etc)

Or, you might might give them a decent salary up front and let them know that you'll fire them if you aren't delighted with their performance.

Kelly

Reply to
Kelly Hall

pay

(with

Pay them a bit more than they are worth. Then they will owe you. You get your money's worth.

You don't want a situation where they think you owe them.

Don't play little games and tricks with people's pay. You want your developers worrying about your problems, not theirs. Give your employees a straight deal and they will return the favor.

It's also easier to deal with, as evidenced by the fact that you are now clueless about how to quantify their work, and are asking Usenet about it. Under these circumstances I highly doubt you will ever reach a system that they believe is fair.

Performance-based pay is basically the employer saying "We think you can't do as well as you say, and we're betting *your* paycheck on it." Just give them a salary and get to the real work at hand.

Reply to
Garrett Mace

Try being a software developer for a while and then see how you would feel about it. Too many things are out of control of the developer. OS bugs and poorly documented features. Libraries from multiple vendors. Chips with problems that the manufacturer doesn't really want to talk about. The list goes on. Add to the mix the inherent issues in realtime embedded systems. Any developer that is any good is smart enough to run away from such an offer. It rarely works out. Quantifying the deliverables isn't too difficult but the schedule is a challenge.

Doug

pay

(with

Reply to
Doug Dotson

I agree. If you can't tell how good a job your employees are doing, then you've got bigger problems than how much to pay them. Decide how bad you want to keep them and pay them enough that they're not going to want to leave.

--
Grant Edwards                   grante             Yow!  The PINK SOCKS were
                                  at               ORIGINALLY from 1952!! But
 Click to see the full signature
Reply to
Grant Edwards

Apart from what the other posters said, you are asking for something that heavily depends on your quality control and your post did not left the impression here that you know what this means in this context.

Just as an example of what I mean, what does it help if code is written in time, seems to be working - even over wide areas that are most often used, but as soon as situation X apears (say one year from now) the code totaly breaks and analysys showes that a total different aproach must be made to handle these special situation thereby rendering 50% of the project useless?

With your aproach, some of your people will have made good money by this time, and those that were willing to address unexpected problems most likely got less money. After time however it would become aparent that you were paying the money to the wrong people.

Out of my experiance in 20+ years of software developement I can tell you that I never ever finished a resonable project without multiple unexpected problems. Your aproach would actually motivate people to hide such stuff which definately would lead to situations like I described. You would end up with lot's of "finished" software that looks and feels good, but that would not cover all requirements. Just my 2¢ though.

Markus

Reply to
Markus Zingg

wrote

to

So the salary of the hardworking developers will be dependent on management and sales and how they screw up the company......

Meindert

Reply to
Meindert Sprang

I agree. And all these valid 'reasons of failure' are almost never understood by management of sales people.

Meindert

Reply to
Meindert Sprang

management

Exactly. Isn't this always the case for engineers who aren't independent contractors?

The original poster wants to implement "performance based" pay. This could mean the performance of the company in general, the performance of the product in particular, or maybe the work-performance of the engineer themselves. I thought I did a good job of suggesting monetary ways to reward any of these performance criteria (ie: company equity, product royalties, or milestone bonuses).

Kelly

Reply to
Kelly Hall

This is very difficult and always leads to arguments about what should be measured and how it should be measured. It can easily be devisive which is not what you need when trying to build a team spirit.

The only one I was involved in was profit related. That meant everyone had to pull their weight and those that did not were soon spoken to bt their peers.

Ian

Reply to
Ian Bell

Not a good idea because a) it is too far away in time and b) because it relies on the efforts of others (sales) whom the developers have no influence over.

Good idea. Works extremely well.

Not so good as there is no means to ensure continued effort.

You might get away with that in the US but it would be illegal in the UK.

Ian

Reply to
Ian Bell

That doesn't work with a lot of engineers. I tried it. Paid the guy 50% more than current market rate. End result? he overvalued himself, took a side job in breech of contract, delivered my job late because he underestimated the effort required on his private work (which I only found out about after he left) blamed it on poor everything but him, demanded a payrise to compensate for all the extra hours he claimed he'd have to work to catch up (which he never got). Left me to fix the up the mess, thinking he'd go and con someone else next. now unemployed.

Some people are just too greedy.

On the other end of the stick most engineers are greatly undervalued. You can hire monkeys, to sell your product (PG Tips did for 30+years) but not to create it, so why do people think they should be paid peanuts?

Al

Reply to
onestone

Especially when the schedule is based, as it usually is, on the fantasies of salespeople and not on the considered estimates of the engineers involved. And even when the estimation is done by the right people, it's seldom accurate. Engineers are optimists by nature (they have to be) and pessimists by training. When it come to estimating, nature usually seems to trump nurture!

Peter Bushell.

Reply to
Peter Bushell

pay

(with

I guess I should clarify here a little.

I am a software engineer of about 15 years, I know the inherent difficulties that are faced during software development. I also know that many of the problems are of the programmers own creation. But that's a different thread.

I know that PBP is a good motivator and has worked well on some companies. Although the best example I know of is a contract development company, which makes it easier in my mind to set the milestones for a given employee.

I can assess if someone is doing a good job and if someone is worth their wage, but given local employment legislation I cant just 'fire' some one, nor would I want to be having to do that. I can take someone on trial for 3 months by which time I will know if they are good or not, but I can not guess their motivation over time.

So all I am trying to do is figure out a way where there is an achievable goal that is reachable and gets the best from a person, but doesn't lead them to overvalue themselves (a high wage) or expect a PBP (as in a bonus scheme).

I think that share options can be too nebulous in a company that is of any size if it's not listed.

As for pay on milestones, it seems to me that that could only cause discord when trying to set it, I would naturally set the post high and the would be payee would want them lower.

Fundamentally PBP is a very good driver for many people, their actions directly affect their outcome. If it wasn't for this there would be no company and I wouldn't be in the position to offer position to people.

Ralph

Reply to
Ralph Mason

of

Every approach has good and bad aspects. The problem is that the owner wants the worker to work hard and "do the right thing" for the product and business, and the major tool the owner has is money, or sometimes, just the promise of money (eg, stock and stock options). Money is a great motivator, but it isn't perfect.

How do you reward a worker today or tomorrow for making a decision that might only show its value years from now?

Kelly

Reply to
Kelly Hall

Peter Bushell wrote: : : Especially when the schedule is based, as it usually is, on the fantasies of : salespeople and not on the considered estimates of the engineers involved. : And even when the estimation is done by the right people, it's seldom : accurate. Engineers are optimists by nature (they have to be) and pessimists : by training. When it come to estimating, nature usually seems to trump : nurture! :

I've learned the one tried and true software time estimation method.

Take how long you think it will take, add one, and go up to the next time denomination.

Example: 1 week = 2 months, 1 month = 2 years, 2 days = 3 weeks, etc

ttyl,

--buddy

: Peter Bushell. : :

Reply to
Buddy Smith

I think the answer to your question is no. The real problem is the culture of the company and one where there are targets/goals tied directly to remumneration you will end up with a peticular type of culture, one where personal gain comes before the group/company gain.

The best company I ever worked for operated a meritocracy. If you worked hard you were rewarded well. Of course this needs a fair management team and fair individual assessment plus the confidence to empower the team members to make decisions and get on with the job, not easy to achieve but not impossible either.

I worked with such a team of people for nearly 20 years. It made me rich and I retired at 50. Nuff said.

Ian

Reply to
Ian Bell

Ian Bell wrote in news:3f6eb5f7 snipped-for-privacy@mk-nntp-1.news.uk.worldonline.com:

You can't fire someone whose performance you are unhappy with? Or you can't let them know up front that you will do so? Or is it just illegal to give someone a decent salary up front?

--
Richard
Reply to
Richard

No. You have to give them several verbal and written warnings that their performance is not up to scratch, explain what they are doing wrong and what they must do to meet the required performance. If they then still do not perform THEN you can sack them.

You can tell them what the grievance procedure is (which may result in their being sacked).

Not illegal but pretty rare.

Ian

Reply to
Ian Bell

I'm not sure how you get from "guy" to "a lot," but I was aiming more for the 10% range rather than 50%. It's not a good idea to give the impression you're made of money. Then the jackpot effect kicks in, and they start worrying about nothing at all.

Maybe you could have kept a better eye on him, but the odds are you couldn't have done much to change what he was going to do. I don't think the high pay was entirely responsible for the inflated ego. It's always going to be a gamble when you hire one person to do something, because once they are well into the project you are trapped. Otherwise he presented a clear case for being fired, which you could have used if caught earlier.

Reply to
Garrett Mace

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.