One very useful outcome of setting relentless deadlines is forcing engineers, who are rather prone to overengineering and analysis paralysis, to just do 'good enough' and unblock themselves.
Its a mental trick to get them to focus on outcomes instead of the journey. Far better to let them mutter darkly about perceived 'technical debt' that is incurred delivering business value than to actually let them try and do things their way :D
This doesn't absolve management of picking the right problems to solve etc, nor absolve engineers of solving those problems in a competent manner.
But what it does is make good engineers work on the right thing, because lots of engineers have a tendency to not see the business wood for the trees and go off solving the wrong problems if self-organising.
Of course it is not nice to be an engineer and see how, as a generalisation, we can all be manipulated like this :)
There is also the opposite. It works well for some time, then after a hundred or so sprints with deadlines and no down time, engineers pick up and leave. When there is no time to rework and address some tech debt, suddenly features take longer to develop and UAT becomes a game of whac-a-mole. If at least the management could also focus on delivering real tangible value, mercilessly cull all the nice-to-haves that introduce too much complexity, and prioritize work that will help bring out a stable and polished experience (albeit with less bells and whistles) instead of pushing new half baked features to satisfy the self imposed OKRs and stroking their vanity to move up the ladder.
The reality is mostly against that benefit though. I've seen so many bad decisions to be made in a short timeline to keep up with the deadlines, which leads the project to be dead soon later. There's always a deep balance to be tracked on.
I understand the parent comment like this: "they gave me 30 days so they must be wanting the X solution" vs "I have to finish this today so its ok to do Y instead". The latter works better most of the time because you can do a second, third iteration of the solution with real feedback.
You can also just coach engineers to ship iteratively directly, rather than treat them as hopeless basket cases and use deadlines as a workaround. I mean stuff like, teach them to ship when it's better (and not when it's perfect), how to break work down in tiny parts, etc. These are learnable skills. The fact that few people graduate from college with these skills doesn't mean they can't be taught in a straightforward way.
> about perceived 'technical debt' that is incurred delivering business value than to actually let them try and do things their way :D
Aye.
Some day I will write a detailed account of the worst code I've ever worked with. 1000 lines of spaghetti inside a single if-block; 20,000 blank comments; a whole pantheon of god classes; etc.
And yet, it was a very successful *product*. Much more so than the carefully engineered and architected codebase in an ISO 9001 (or was it 9000?) employer.
"""It was the best of code, it was the worst of code; it was the age of delivery, it was the age of technical debt; it was the epoch of rapid prototyping, it was the epoch of unmaintainable legacy; it was the season of boundless innovation, it was the season of endless refactoring; it was the spring of shipping features, it was the winter of debugging nightmares.""" etc.
Always doing "just good enough" logically results in a product that's barely good enough. Customers may find a competing product that's better than barely good enough.
Its a mental trick to get them to focus on outcomes instead of the journey. Far better to let them mutter darkly about perceived 'technical debt' that is incurred delivering business value than to actually let them try and do things their way :D
This doesn't absolve management of picking the right problems to solve etc, nor absolve engineers of solving those problems in a competent manner.
But what it does is make good engineers work on the right thing, because lots of engineers have a tendency to not see the business wood for the trees and go off solving the wrong problems if self-organising.
Of course it is not nice to be an engineer and see how, as a generalisation, we can all be manipulated like this :)