The "no" is bc challengeable reasons, which are useful to be explicit about
"This would take resources away from delivering X and limit devs ability to collaborate, so we need a way to motivate the budget precedence / growth and a way to afford 50% + 6mo per dev productivity hit around retraining"
"Database x is a VC co toy that risks dying, acquisition by Oracle, and losing customer data when we do not have time for self-inflicted nonsense. We need ways to mitigate the risk such as $10M in NIH DB dev budget in case the likely case happens. We already spent our innovation budget for X, so need more to motivate doing it again on Y."
Less than gate keeping, this is a great way to help mature early/mid career devs / job hoppers who haven't had the chance to live with many self-inflicted senior-level mistakes yet
"This would take resources away from delivering X and limit devs ability to collaborate, so we need a way to motivate the budget precedence / growth and a way to afford 50% + 6mo per dev productivity hit around retraining"
"Database x is a VC co toy that risks dying, acquisition by Oracle, and losing customer data when we do not have time for self-inflicted nonsense. We need ways to mitigate the risk such as $10M in NIH DB dev budget in case the likely case happens. We already spent our innovation budget for X, so need more to motivate doing it again on Y."
Less than gate keeping, this is a great way to help mature early/mid career devs / job hoppers who haven't had the chance to live with many self-inflicted senior-level mistakes yet