Just one simple advise: sell software as if it were hardware.

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.

Besides the books others have mentioned (peopleware and mythical man month should be required reading for all managers in my opinion), I would also suggest thinking about the following:

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.

The problem with The Mythical Man Month is that it contains brilliant observations about software development in general, as well as brilliant observations about developing huge mainframe operative systems at IBM in the 70s.

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...

I think you could argue in favour of Peopleware as the "practical" complement for MMM.

Although I'd be curious to hear of any recent books that hit the level of these two.

As physical books, 'Becoming a Technical Leader', 'Quality Software Management, vols 1-4' and others condensed Jerry Weinberg's experiences as a software developer, manager, and consultant down to practical, thoughtful suggestions for managing software projects by managing yourself and others. He's now bundled the writing as the 'Quality Software' e-book bundle [0]. One stop shopping for a lifetime's worth of suggestions.

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.

[0] https://leanpub.com/b/qualitysoftware

The key is effective product management, which can then lead to effective project management. Specifically, someone needs to know what the product is and where the product is going (road map). Often the product is at the mercy of the loudest sales person, demanding the feature to make their sale. SalesPersonX needs FeatureY to close a $50,000 deal, when CustomerA, CustomerB, and CustomerC have all requested ImprovementD, maybe they'll renew without it, maybe not.

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

The Mythical Man Month. I've worked on at least 3 projects that went disastrously wrong and could have been fixed if the manager read that book.

If you're a founder, I'd suggest Peopleware and have your engineering and product leaders read The Mythical Man Month

Should you ask people here? I think it's better to ask this question of actual entrepreneurs than engineers. I wonder if there's any successful startup (assuming you're not hoping to build a lifestyle business) that got there without code debt.

I think the hard part is the search for the product that solves problems. Not technical debt.

Besides the books recommended below, check out Peopleware if you haven't already, as well as Joel On Software (skim the blog list to only read the ones related to creating a good work environment).

You might like this reading list I put together towards creating and sustaining High Performance Organizations:

https://github.com/pdfernhout/High-Performance-Organizations...

The Clean Coder is a good guide for individual engineers, but I don't know one for managers.

Check out the book Lean Thinking.