Paul Hammant's Blog: A Cynical View Of Bonus Calculations
I have not had a job that has had even the potential for a bonus since 2001, so this isn’t from experience. It is from observation sparked by a recent conversation with a friend who told me about the bonus situation in his 40 person development outfit in fin-tec. I am sure there are companies that are outside fin-tec that do the same.
There is a class of company that is stuck in their own ‘Groundhog Day’ existence for the way they develop software, how that gets released, and the calculation of the annual bonus for members of the development team. Indeed through the bonus structure itself, the team is conditioned to self-repair back to status quo.
Anyway, I got to thinking could there be a formula for this. Any maybe I have an opportunity to amp up the cynicism for the sake of a blog entry.
Parts of the formula
Average extra hours worked in advance of a release
Hours Factor = GAMMA.DIST((Average hours spent in release week Mon-Sun - Normal working week hours)/10, 2, 4, FALSE) * 10.5
If a someone with experience of “sustainable pace” joined the dev team at such a company and attempted to not do the same overtime that teammates did, then they are not in line for a bonus. That is true even if they did everything else in the run up to that to ensure work was complete and defect-free in time for the release, though individuals in the team might appreciate it (and have their first realization that there could be a ‘better’ way of working).
Cynical advice for a high bonus: The easiest thing to do personally is working huge hours in the run-up to a release (visibility may be slightly more important than impact).
Number of planned releases a year
Planned Releases Factor = GAMMA.DIST(Number of planned releases a year * 1.8, 2, 2, TRUE)
With luck, you are on a team that does 4 or 5 releases a year for maximum bonus ROI. Note: As each release is a multiplier
on your OT commitment, then too many releases a year is too many hours for the money.
Number of unplanned releases per planned release
UnplannedReleasesFactor = GAMMA.DIST(Average number of unplanned releases following each planned release + 1, 2, 2, FALSE) *5.3)
Try to ensure there is exactly one unplanned release per planned release, as implicitly there are extra hours per unplanned release and you can’t do that every night for a week when you did it the week leading up to the release too. Besides, many bug fix releases per release do not look good to the business or exec leadership. One patch release following a planned release reminds everyone that the team can be responsive to a bug fix. Hmm, regressions should count negatively, but I’ve left that out of the calculations.
Putting it all together
Annual Bonus = Salary * Salary Factor * Hours Factor * Planned Releases Factor * Unplanned Releases Factor. Some examples:
Also, note that execs are involved in releases too, but have a different bonus structure.
Most likely, their bonuses build on the bonuses of their reports. They do need some release-related drama that requires their intervention and oversight, but their own overtime hours contribution is not the key factor to the resulting dollar amount.
Whether women are paid equally is a factor too. I have been lucky to have been in companies with women in senior executive positions and assume that gender anomalies have been eliminated. Where they exist in other companies, they might be base salary differences and/or a different factor on the base salary for the bonus calc.
Working your own numbers
Here’s the Excel sheet for the whole thing. The original is in Google docs but I can’t work out how to share it from there in a way that you can clone it, but not modify (deface) my version.
The way it should be
Teams should not be rewarded hours per release or so few releases per year. There should not be an ‘average hours per release’ bonus factor at all. Indeed if we have the team achieving no-drama releases, and an individual was doing unsustainable hours in release week, then it should be treated as something to investigate and correct.
Releases should be up at weekly, with teams who’s applications/services are not bound by audit driven sign-offs, aiming at daily releases or continuous deployment. The planned release factor should be from an S-curve function giving the incentive to progressively dial up release cadence.
Unplanned releases should very rarely happen (because of automation) and not at all for teams doing “fix forward” with their CD workflow. Regressions should never happen, because of the right branching model. Note regression is a bug, and regression testing is an activity (the two get confused).
North American corps: Hire me to assess your development processes, and make plans you can execute on to get to a higher-throughput reality. Particularly if Trunk-Based Development is a goal, as I have considerable experience getting enterprise/corporate teams there from their crazy branching models.