all things being equal, shipping a feature with a 2 weeks delay is certainly bad, but often all things are not equal: the slower dev does something more and the

all things being equal, shipping a feature with a 2 weeks delay is certainly bad, but often all things are not equal: the slower dev does something more and the does something less (I'm ignoring the case where the slower dev just slacks off). The faster dev may have skipped important things, things that can potentially sink the company, like security aspects. The faster dev may have been aware of that and still decided it was worth to complete the task even if the system as a whole wouldn't be ready to production. For example so that the feature can be seen in action in an environment where for example security is not perceived as to be a severe risk factor. By doing so, the developer plays with the definition of done, in a way that can be either advantageous or disastrous, depending on what happens down the line. Will product management understand that the system indeed still needs more work before shipping it to a wide audience? This is where the debt metaphor has its teeth. It allows to negotiate these tradeoffs, also across the engineering team boundaries.