The point of setting the expectations might solve a bit of "we are moving too slow/too fast". The arguments from both teams that you mentioned are valid because it sounds to me there were no expectations or clear vision of the final product.
An example of setting expectations would be:
- We have feature A.
- Its based on feedback from clients (X,Y and Z).
- This will save the user 30% of the time.
- We need an MVP or proof of concept in 12 weeks.
Now what the above will communicate to engineers:
- Its fine to make short-cuts and workarounds.
- Its time bounded.
- We will get more feedback when it is done then we will iterate and refactor, or even write from scratch.
- We will learn from it and get insights to make better decisions in the future.
Also, hire a VP of engineering which will have a fresh look at the team, spot the bad apples and build engineering culture.