You need to maintain some slack to be able to react to change quickly. Driving your developers at max capacity will bite you. You want them to have some spare e

You need to maintain some slack to be able to react to change quickly. Driving your developers at max capacity will bite you. You want them to have some spare energy and time. Also, have some indirection between "what I want" and "how to build it." Let software people manage the software. My last non-technical cofounder did neither of these things. He always wanted to-the-hour estimates, granular checklists so he could "see progress," and he would prescribe implementation and write pseudo-logic instead of focusing on business need. Part of that last part was he was kind of a control freak. If things didn't turn out as he expected, he would complain and it would take a whole debate to convince him the minutiae he wanted weren't worth the cost. I left that startup several years in. Well before we really got anywhere. That's the other thing about software developers. You are managing them and telling them what to do, but turnover of the wrong people at the wrong time hurts.