Earlier quoted context omitted.
A lot of people are building big systems these days and in many cases we have a guess at what is a reasonable amount if time for all of the steps in the process to take if we want an answer in 600 ms. While your trick makes you look good, setting the times to match the budget might be more honest. And when the app slows down you can blame the people who take 250ms to do their part when we agreed to 100ms.
100ms?! That’s insane, if we set the bar at 1000ms then maybe 25% of our requests will qualify.
As several other people on HN have pointed out more eloquently, it's the variability that kills you faster than the average throughput.
The 100ms was not about end-user response times, it's referring to internal response times between servers. To make a page in 1 second you can't have 3 different services taking 700ms to respond, even if you can make all three calls in parallel. And if you have to call a bunch sequentially, you need the 75th or even the 95th percentile for those services to be pretty good otherwise your 95th percentile for the entire interaction will be very spiky.