The 20 / 80 productivity rule
So I have been working at a startup company for about two months now, and I already learned many great things. I am not talking about new frameworks or programming tricks, but about peer-interaction and productivity. Coming with an academic background to a fully-pragmatic startup is not easy, and I had to learn some lessons the hard way. The best one to date has been the 20 / 80 productivity rule.
The 20 / 80 productivity rule was explained to me by one of my co-workers and is quite simple. In any task, the Effort vs. Result curve looks about the same: you can complete a task up to 80% with only 20% of effort, which means that the remaining 20% of the task will take up 80% of effort. While being an academic or when playing on side projects, it is probably fine to provide 100% of the effort for 100% of the result. However, while being on an agile team in a startup world, you want to reach that optimal 20 / 80 point on the curve, and spend time only on those 20% that give you 80% of the final result. This is really easy to understand, but trust me, it is not always that easy to implement, all the more so when it requires breaking well-established habits. I am not saying that one should be as lazy as possible. Here, “effort” is to be understood as a combination of time and resources.
So what did I learn? I learned that in the real world, perfection is an unnecessary commodity. It doesn’t matter if your algorithm is not super-fast, as long as it’s fast enough. It doesn’t matter if the design of your class is not the best, as long as it is good enough to be maintained and understood by another developer. The trick is to start a task by identifying the different steps necessary to achieve that task, and within those steps the different alternatives and their associated effort vs. result trade-offs. Then, for each step, pick the alternative that gives the 20 / 80 ratio, implement it, and move on.
Here is a graphical representation of this 20 / 80 trade-off that should make it clear: