I read a book called The Principles of Product Development Flow. I do not recommend this book for the casual reader. It is filled with math and graphs, but the ideas are pretty interesting and very applicable to startup entrepreneurs.
My first question when I am reading about something new is, how can I apply this to give myself an advantage in whatever I am working on? So I called up a friend of mine that is working on delivering web sites to small and medium businesses.
I launched into the central idea: how long it takes you to get individual projects finished and out the door determines how quickly you see the economic benefits. The studies and math show that the closer you get to 100% utilization of each developer, the longer each item waits in that developer's queue being blocked by other projects.
When the project depends on different people, then queue size can really slow down getting anything finished. Unfinished work doesn't make you or anyone else money. In web startups many people are involved in developing a new idea or feature: creative art, layout, browser code, server code, and database work to name a few. If each person that needs to work on the idea is scheduled to be busy 100% of the time, then total time to finish any single project goes up dramatically.
The counter intuitive answer is to have more idle time. That way when the high priority work comes through it gets done immediately by each worker. Being busy all the time equals not having time to push through critical items in a timely manner. Also choosing wisely the work with the highest economic payoff or greatest risk reduction has a huge impact. The group has to understand this or they won't work on the most important projects leaving projects waiting.
Another key idea is what the author called cadence. This means if there is some part of the project that requires a group decision, having a regularly scheduled meeting that is automatic makes the overall progress faster, as you don't have to wait for everyone to schedule infrequent meetings. This sets a tempo for getting work done. Otherwise more features get crammed onto a release which things makes the release recede into the distance. This is also counter intuitive, as you would think regular meetings would slow down things. This is one reason daily releases can work, as they set a regular tempo for pushing out work.
So my friend and I started discussing these ideas. Immediately he started rethinking his business. He had been focused on having 100% of his hours booked. This led to lots of projects that are not totally finished, which means he can't get paid. Now he is approaching clients with a new proposition. Blocking off a definite time frame to start and finish the work for a better rate. He gets better cash flow and the client gets the project finished so they can realize the economic effect. He is even thinking of charging more if the client slows down the turnaround thus gumming up his project completion time.
He has been doing this for 2 weeks and starting to see happier clients who want to do more business with him and a fatter bank account. It is unusual when you find a book that seems written for huge companies and realize that it also applies at the startup scale.