1. Hire the best developers you can find - Three excellent developers are better than 9-10 average developers for both quality and quantity I've found in may many years as development manager with multiple companies.
2. Communication is crucial - Whenever possible talk face to face or video conference, if not talk on phone, if you email or text something will get lost in translation.
3.Keep reasonable hours - Developer quality drops significantly as it gets latter, and if done too often or expecting people to work late you will get high turnover which costs you more in the long run.
4. Make sure your developers have the right tools and hardware to do their jobs efficiently - Great example of this is my rule of at least 2 monitors per developer, hardware is cheap - time is not. Note: Studies show 10% increase in productivity and 26% fewer defects with just 2 monitors.
5. Reward Success - If someone does something you want to encourage make sure you reward them. Sometimes just a simple thank you is remarkably effective. Gift cards tailored to their hobbies is another idea to show you appreciate them and know them well enough to give something specifically for them.
6. Balance workload - All developers want to work on new feature and new technologies but that is not realistic. Make sure to try to balance each developers' workload with some undesirable work (there is always undesirable work) as well as desirable work. Encourage them to get undesirable work out of the way 1st so they are motivated to get to the things they want to work on sooner.
7. Understand WHY a new feature is wanted - if you understand the reasoning behind a feature, developers and UI people will often figure out better ways to display and design/implement it than any requirement statement can tell you.
8. Implement the SDLC that fits your business requirements not the newest or perceived best SDLC for JUST development team - While I've used waterfall, spiral and agile/scrum and they all have their inherent advantages and disadvantages but I've yet to see one followed to the letter. The reason for this is that every business values different things. Some are time driven (It ships June 1st no matter what) or feature driven (We will ship when all these features are complete). Regardless, Figure out what the priorities of your business and choose whichever one most closely fits Business model and culture. (Note: Extra credit given if everyone in the company knows your SDLC)
9. Never underestimate the importance of a reliable and customizable build system as well as the people who develop and support it - If you are working in an environment that does not use a repository get that in place immediately. Make sure you have builds versioned and you can recreate an older build easily. Make sure you can compare versions of the builds and its changes. IF people are going to download product (who doesn't?) make sure you have a system that digitally signs product/installer. I've generally found you can gauge a development group based on these factors as high quality developers will usually insist on certain criteria being met in this area.
10. Develop for the world - Whenever possible begin localizing your project from the very start. Learn the best way to localize in your toolset to accomplish this as some languages and tools have built in mechanisms to make it easier than others. The longer you wait to do this the harder (and more time-consuming) it will be. If someone tells you that it will only ship in USA tell them how costly it would be to do it later and that they are excluding 95% of the market. Lastly, remember it's not just changing strings from one language to another, its different date formats, currencies, time zones, etc.