To be honest numbers are slightly less I put 8/5 by scaling the current technical team to a little bit more to keep it anonymous (I might be paranoid but my team mates reading HN as well!)
But still it's clear that my management skills are not top notch and I didn't hire right people.
We are building a (fairly expensive) desktop software in a quite niche area, releasing about 4 updates per year and it's been about 2 years we are doing this.
That is a killer release cycle. It is a inefficient as hell. It encourages people to hide in the long deadline. Switch to 2 week releases, even if it is only internal. Eventually switch to two week releases to customers. They will get new goodies every two weeks and they wont have to wait months for bug fixes. Who knows, the discipline might solve part of your problem.
Internal releases all automated so daily, hourly whatever in every commit and it's almost forbidden to keep your code more than a day at home! even if it's broken I force people to commit to keep it alive. If one code takes more than a day there is generally something with (design, task splitting etc.) unless we are introducing a big feature.
However based on comments I think focusing on important couple of features and try to deliver them in weekly of 2 weekly periods makes a lot of sense and should motivate people better.
But still it's clear that my management skills are not top notch and I didn't hire right people.
We are building a (fairly expensive) desktop software in a quite niche area, releasing about 4 updates per year and it's been about 2 years we are doing this.