This. Though, I think the exact example may be debatable.
The (appropriate) question was “We have 5 months of runway, does this make sense?”
Assuming the manager is halfway competent in listening to their team, then this should be a useful focusing activity for both the dev and the manager.
In business, and in life, it isn’t about what you “can” do, it is more about focusing on the handful of things that give you the biggest “bang” for the buck. Think Pareto law, and how you can get 80% of a result, for 20% if the effort.
So, in the context of the scenario, the developer should be asking themselves:
1. What problem does <insert tool/process> solve now or will solve in next 5 months?
2. How painful is the problem, and what is it’s frequency (High impact, but low probability; moderate impact, but high probability).
3. What is the cost of the new process/tool to the team? (Time, cognitive load, $$$ that could be spent elsewhere).
As long as ratio of value to cost is large (10X or more), in the timeframe that matters (in this example 5 months, for most companies time is measured in years), and you can articulate it, selling the idea should be a no brainer.
However unless you can truly get that 10X(or more) return, then it might be better to focus your improvement activities elsewhere.
All that said, I do think the “Command voice” at the end is a bit of an issue... at least for me. You are “pulling rank”. This is “okay” if you have built up the “rep”/karma/trust to do so, but unless you have, will likely make the dev (long term) run for the hills. It might take a bit more time/coaching to explain something like the above to them, but that is an investment in people that lasts a lifetime, whether or not the startup lasts past 5 months.