Can anyone recommend reading material for a founder who wants to get these things right from the start? Is there a definitive guide to creating an environment where engineers can thrive?
If you have it in store, you sell it, as it is. If you don't have it in store, you don't sell it. You can inform potential customers about next foreseen delivery, but do not act as if you _knew_ next delivery date.
Just realise how absurd it is to plan a fixed time for tests: either it works, and the tests will run smoothly the first time, or it doesn't work, and you can't know when it will work. If you knew when it will work, than you'd have understood which defects it has, which means that you'd have had it right on the first time.
make sure you align rewards with the results you want: if you talk about code quality and so on, however you incentivize your execs/manager for "ship quickly and fix later", that's what will happen.
When interviewing all your managers/execs ask them "assume your team leads told you that feature X will take Y months to develop, and I told you that for business reasons we need to deliver it in Y * 0.85 months, what would you do" and hire/nohire depending on how you feel about their answer and how it maps to the books above.
Make sure that if you have a deadline you are flexible on deliverables, there is nothing worse as an engineer than being asked to estimate how long something will take, and then be told that the delivery is fixed anyways. At the same time if you ask for a ballpark estimate, don't then assume your engineers will hit that 99% of the time and bet significant marketing/sales dollars on it.
Some engineers will thrive in environments where customer-is-first and backwards-compatibility is king, where code quality and cleanness are prioritized and code written lives a long life. Other engineers will find that stifling and instead will thrive in a write-fast-and-throw-away environment, make sure you assign each type of engineer to the right teams.
And finally make sure that your company culture is aligned with what you want to achieve: some engineers will thrive in a private-offices/business-is-business environment, others instead will prefer a open-office/work-is-gamified place, hire accordingly.
It's hard for most non-professionals to tell what's what.
I would have liked to write a readers guide or something, but I don't think it'd be as good...
Although I'd be curious to hear of any recent books that hit the level of these two.
I'd add, as others have or will, 'Peopleware', 'The Mythical Man Month', 'Code Complete', and 'Making Software', but Weinberg not only presents information and tells stories, he gives practical suggestions on how to 'check your work', adapted to your situation.
Someone needs to make this call: prioritize ImprovementD or FeatureY. Maybe they can both get done this year, maybe not. It's a business decision, either keep current customer happy or drive for sales. Usually SalesPersonX knows RockstarZ's number and calls him directly. RockstarZ get's burned out from the constant pressure and quits.
So, someone needs to be gathering feedback from customers and prospects, build a roadmap, then project management can concentrate on delivering features.
I have worked at one company that got this right and it was a joy. I didn't realize it at the time, but I've since come to regret leaving there.
Edit; I just realized OP asked for reading material, I opined instead. Sorry, leaving this here anyway
I think the hard part is the search for the product that solves problems. Not technical debt.
https://github.com/pdfernhout/High-Performance-Organizations...