Oh, that's a long one.
Let's take two points of view:
they insist on faster delivery
Saying that TDD would decrease delivery speed is not necessarily true.
If you search for studies on this, you will find a mixed bag of conclusions,
highly dependable on the research methodology itself - this is the case because the code you write through TDD is not the same code you write with TLD (Test Last Development).
Thus, it's a false dichotomy - it depends on each particular context.
For a longer discussion on this, I suggest watching Bob Martin's Craftsman's Oath talk. In a nutshell, the argument is that developers have the duty to his/her of demonstrating what capabilities of the software and the duty to his/her developer colleagues to ensure the software is kept in a state that they can work.
And these two duties can only be achieved* through TDD (or maybe even Test-Commit-Revert - TCR as Kent Beck shows).
The first because TDD/TCR limits the developer to only make progress in the production code based on one demonstratable behavior - if more behavior is added without a previous failing test, it's not TDD/TCR. Bugs will exist, for sure - but not bugs because of a misunderstanding between the programmer's intent and what he/she codes, because he/she coded the behavior twice (as a specialized test and as generic production code).
The second because only through TDD you can ensure you can safely refactor. Without the limitation above, you may never know if there is some behavior not demonstrated by tests. Without this certainty, all refactoring work is in the hope nothing will unnoticeably break. Line coverage and mutation coverage analysis could help, but they are not as complete as the TDD limitation.
* "can only be achieved": A necessary condition, not a sufficient condition.
If these two points are not relevant for your context, then TDD/TCR loses most of its reason to be.
If you want to have fast delivery, you may want to consider Continous Delivery. The idea is to keep your software always in a deliverable state. No hidden long-living branches, no half-done features (meaning we are not sure if it works as intended), etc. CD is a consequence of a broad set of practices which include TDD, Continous Integration, etc. Dave Farley Youtube channel and book can give you a good introduction.
- Will the developers slow down when first learning TDD? For sure.
- Will the developers feel frustrated when first learning TDD? For sure.
- Is there anything worth learning that doesn't make you slow down and frustrated during the learning process? No.