Productivity increases and sharing the pie
Posted by Ian Holsman
I’ve heard stories that doing rails and django development can cause your productivity to increase by up to 3 times, and that they result in better quality code.
But what does this actually mean?
Well for the company hiring the developer, it means they get a product cheaper and faster. yep.. thats good.
But what does it mean for the developer writing the code?
What does he get out of it? usually a pat on the back, and another project to work on, and if he is lucky a small bonus at the end of the year.
Have developers been able to successfully negotiate with their bosses to get a share of that extra productivity or is that all going to the bottom line and the owners pockets?
Now.. If a salesman for the same company became 3x more productive you KNOW he would be knocking on his bosses door and renegotiating his deal to take into account his productivity increase, and if he didn’t get it would be out the door and in another job the next day.
Why isn’t it the same with developers? why isn’t there some kind of incentive scheme for them tied to their productivity, and also the end result. Sales and profits.
Most developers would approach this issue in the following way:
-
eg… assuming I get $50/hour.
If a product took 300 hours to code, I can do it now in 100. I have just saved the company 200 hours..
That’s $10,000 just in my wages, and I should try and get more of that.
This isn’t right for a corporate developer. You (the developer) are a fixed cost. They have to pay you regardless. You need to approach it by thinking about 1 month of extra lead time where the company can be generating sales/revenue on that work is worth.
Remember when negotiating, don’t just think of your cost savings, think of that lead time as well.
When the project you are doing got intially proposed there should have been a ROI or some kind of benefit calculated.. you need to figure out how much that month is worth based on the ROI.
trust me .. your senior management is, they know what getting this done a month early means to their bottom line.
This kind of thinking isn’t new. This is how the construction industry works. They have LARGE bonuses if you can get the building up and usable before the estimated completion date.
BUT remember there are also penalties if you are late.
I think developers and IT projects should be rewarded the same way. I think people with ‘skin in the game’ perform better… and it will force the real ROI/benefit to be calculated more accuratly in the first place (ie.. less crappy projects that are just fluff)
Has anyone seen this kind of thing happen in their workplaces?
You could also use this kind of justification to get yourself onto a Rails/Django training course, or justifying why you think rails/django would be an ideal choice for the next project you start.
I have seen that. Penalties that is, but incentives, rarely.
And I don’t agree with the approach as it becomes an excuse to rush into a code-n-fix cycle and the quality is more than often terrible.
The major problem is that there has not been any way to quantify quality, thus global productivity ans its consequences.
Quality is a function of development time, bugs, performance, ease of maintenance and available documentation (which should not be quantified as well in the number of pages…).
The number of bugs is an interesting metrics that makes only sense if you can relate them to at least a couple of fixed variables: a similar application, an identical development team, an identical test team.
For instance, quality in opensource projects is pretty subjective and extremely hard to quantify. If JOnAS has 5 bugs open and JBoss has 200 open, does that mean that JOnAS is 40 times more reliable ? or is it simply because JBoss is 1000 times more used ?
You are actually stating your question of rase on the differencies between salesrep and developer.
And I can say that in the company where I have been working (PM) we have the way of benefiting developers who can make their dev quickier.
I have a bonus budget defined (its based on the percentage of the project profit-margin), that I can split among devs. This bonus definitely (the amount of percents) depends on the the success of the project.
Yes, you can ask, how the dev benefits from that, where he has his work done earlier then expected 100% time?
He benefits from the availability on working on another project and thus receiving yet another benefit!
To give an example:
project … 10 000 USD another project … 5 000 USD
A) 100% time … 24 hours. benefit 2% => 200 USD
Whole benefit in 24 men hours… 200 USD
B) using Django .. 8 hours. benefit 2% => 200 USD
working on another project … 16 hours. benefit 2% => 100 USD
Whole benefit in 24 men hours… 300 USD
So, in this case, when dev has a chance to use Django, he gets a chance to sell himself more.
I hope you see my point. These are my 0,02.
But anyway your topic is interesting.
Hi Stephanie.
my point here is that you should be rewarded on the success of the project by a percentage of the revenue it generates.
If your code is buggy and that translates to less money/savings coming in then you should be penalized. I agree with you about bug numbers don’t really meaning anything. If you could get a ‘buggy’ piece of software out the door which people could use to get 50% of the savings today, and then work on the bugs to get it to 100% you will still save the company money.
If you can manage to get the company $100k in extra sales by releasing a month early, then you should get your share of that $100k, as it is a result of your direct effort (speedier dev time)
Hi Radek,
what you mention is very close, and a great idea, but I would like to see the developer actually get a %ge of the deal, and see it more tightly correlated with the success of the project.. If you are working on crap and come in very early it isn’t as important as working on something profitable and coming in a day early. This also means that if you doing your bit faster doesn’t result in the product getting out any faster, then you don’t get rewarded either. (ie.. your not on the critical path)
What it does fail to mention is how to reward infrastructure projects which don’t directly affect the bottom line.
Hi Ian,
what you mention is an idea that some (small) SW house companies try once or twice and then stop it.
I have been working with both - salesreps and devs. Salesreps usually get %ge ftom the deal, so it seems to be very unfair to devs that they get %ge of profit-margin. The diff is based on the fact that sales are focused on selling from the very beginning. While devs (unfortunately) are usually not focused on selling (their knowledge and skills) at all.
IMHO it would be much better, when sales would have to buy development from the development (ie. some sort of internal contract with budget etc.).
Eg.
A) Sales want to sell the project for 100k
It’s a good project with planned profit-margin of 30k and 70k dev costs. However development would sell it to the salesreps for 85k.
B) Sales want to sell the project for 50k
It’s a crapy project with at forehand known loss of 30k and 80k raw dev costs without rewards. However development would sell it to the salesreps for 85k.
Then devs would be much more focused on selling themselves and interested in the result of their project without the trouble of price negotiations with different customers.
One more fact: I am talking about the custom dev projects of the SW house (so no shrinkwrap or internal).
Perhaps I’m missing something, but why should you get a % of the deal for finding a better tool for the job? Arguably, that’s all you’ve done. Your old time estimates were based on using rocks and your new time estimates are based on using nail guns (drawing on this construction analogue). Granted, you should be acknowledged for finding the better tool, but most companies build that in by paying you to do so. E.g., I’ve worked at several companies where I was encouraged to stay up to date with the latest and greatest things by getting paid to play around with them.
Furthermore, after the first project, I’d think the using of some agile webapp framework would become standard and all time tables adjusted accordingly. So, you won’t really be saving time any more, you just won’t be wasting time.
Hi Radek.
good ideas..
Hi Null.
your approaching it from a ‘cost’ point of view.
Finding a better tool, is just another way of increasing the value to the firm by shrinking the product development lifecycle.
If it is really ‘10x’ the increase, you have also enabled the product managers (marketing) to suggest a whole suite of new features/products which had a lower (but still positivie) NPV which they couldn’t do before as your cost was too high.
even if they use the new tool for the job on the 2nd project, the job of the developer is to remind them that without him they would be stuck with a java developer who wouldn’t be as efficent. the companies BATNA is much lower, so the developer can claim more of the surplus.