A. Let your engineers know they will never have to look or explain this code to anyone, and
B. Their job isn't on the line if it doesn't work.
The reason your engineers want clean, testable, fast code is because they know that the project manager won't be up until 3AM debugging the system because it's down and there's a giant pile of hastily written code and technical debt.
(I agree with what someone else said that developing and selling your own product really clarifies the importance of getting things out the door, but in those circumstances the pain of no customers is more than the pain of the 3AM debugging session.)
If the decision maker (project manager in this case) doesn't feel any consequences for their decisions, then they won't have any incentive to make good ones.
Not to mention iterating or doing changes is easier with modular and tested code than with shitty code.
-- Lean Startup 2012 Conference
Perfect is the enemy of good enough, and all that. Especially as a startup, there's no guarantee you're going to be in business in a few months, and time = money. I'm not saying you shouldn't have well-tested code, but you probably shouldn't spend weeks perfecting something when a good enough solution can be done in a day.
Once you get beyond the basic crud-webapp-twitter-clone the ability for a new person to simply pick up and start working becomes increasingly more difficult. This is a cost that you will pay. You'll pay for it when one of the three people that understand the system decide to quit or when you have to put new hires through eight months of training before they can write a single line of code.
I've worked with systems that were written by people that have decades of industry knowledge. Every class, method and comment is using their lexicon and entire chunks of the system rely on assumed knowledge. Suddenly ranked_pct(std_dev_norm(userid,norm,v,arr,false,get_data(userid))) is returning 0.24 when it used to return 0.51 and the BA/PM would like to know what changed. That's when you'll realize that your growth has been severely limited.
My previous code shop maintained a fairly large rails base and we mitigated that risk by doing as many things "the rails way" as possible, even if it took more time than some ruby hack.
When you consider how quickly new hires could pick up the project, it easily outweighed the extra effort designing code in a well-understood format.
Leave the meetings and reporting to managers. Some of the best teams I have worked in have managers who buffer/cushion every trivial externalities from the rest of the team. This is crucial for the sanity of many developers.
My ideal engineering state is heads-down-leave-me-alone. I can write some awesome code in that place.
At the same time, when a compromise has to be made, I want to know as much about the problem space as possible.
You can expect most people to acknowledge the problem - briefly - and then return to complaining about your solutions.
It's painful for an engineer to be told to do MORE with less time and less "quality", but the business cares about more than just code.