Comment by wrs
15 hours ago
This is a starker tradeoff, but still the same logic that engineering leaders have used for years to eliminate time for exploration, learning, mentoring, role-switching, and every other activity that makes a better engineer but doesn’t move tickets off the queue. These developers are all going to work somewhere else in a few years, so why should we invest in growing their skills? This isn’t a charity, after all.
I’m sure you’re smarter than that, but a lot of leaders aren’t. And that’s based on the past, when they had an established playbook they could choose to follow, not the situation we’re in now where you have to make it up as you go.
I absolutely see your point there, but I don't have a better answer. It feels like the table stakes for feature development speed have risen all of a sudden, whether we like it or not.
Well, only if the increased speed doesn't result in a quality or staffing time bomb. Which none of us really knows at this point. You could always write code faster if you don't care if it works or is maintainable (and indeed many companies work that way for a while), and you could always put your developers in a pressure cooker until they leave from burnout.