Is rotating the lead developer a good or bad idea

I hate having support teams and development teams.

When this happens the developers start to look down on the support people (it is a less glamorous role). People get tagged as suppport and then can't get back to doing development where the better pay and promotions tend to be.

Additionally the development team doesn't feel the pain of their mistakes (which is critical to getting better!) and tends to do the same things repeatedly that the support team ends up fixing. This ends up with them thinking they are great developers (they never hear otherwise) and the support team thinking they are idiots.

The other disadvantage is that the orginal developer can often find and fix a bug in a complex system faster than a support person who has to get up-to-speed on what was done and why before fixing. Further, I have often seen support people break things more because they didn't understand the why of something in the first place. This is especially true when you have developers who just do what they are asked to do without questioning it or pushing back on a bad requirement. So when the customer asks for something that conflicts with another requirement they don't know about because they didn't work in that part of the system, the change is made and something that used to work doesn't any more. It's true this can happen when the original development staff does support as well but is less likely to becasue they have more of the backgroupnd information internalized.

I don't see the problem as being how to minimize admin time for developers but more how to get them to do the needed admin work at all! I do think that in planning work, you should only plan for 6 hours a day of productive time. You need to account for leave, jury duty, admin work, meetings, etc., and if you think you will get 8 hours a day in determining your deadline, you already have either a deadline that will not be met or will be asking your people to work continous overtime or not allowing them the time off they need to have to recharge. A tired developer is an inefficient developer. Don't plan to force people to work exhausted.

I do suggest that if your application is database centric, you should have several database developers (not DBAs but people who write database centered code and design databases, especially people with performance tuning knowledge). Your application will work better if you have these people from the start in the design phase. You will also want to read about database refactoring and set up a process where database changes can properly be made as needed.

A contract GUI designer is nice to have around as well. This kind of designer is often not needed full-time, but it's handy to have someone you know you can hire when a major redesign of the user interface is being done.

A good business analyst is a must. A bad one can destroy a project and the team. Do not keep a bad analyst for longer than you need to process the paperwork to fire him. This person can do more harm to a project than virtually anyone else. He will add months and years to projects trying to work around the garbage the devs are given to work from and you will find yourself pushing releases that work but don't do what is needed ruining your credibility.

The greater the risks, the more you need "air cover". This is what a manager is really supposed to provide. While the team does the work, the manager is supposed to ensure that there is nothing that will keep the team from achieving team goals. Whether it's tweaking the schedule, running interference between the team and the sales staff, or simply making sure the team are paid on time and that the coffee machine remains in working order. A really great manager allows the team to function almost as if the manager isn't there.

The reality of course is that most managers utterly fail at this. They either micromanage, or they are rendered obsolete so that the upper echelons of the company can control things more directly, and the truly great managers are a rare bird indeed. As far as a software team is concerned, there are some pros and cons both ways when it comes to having a hierarchical or flat team structure. If the team is very small, and the work done requires very little overlap (and by that I mean everyone has an independent project), then it's been my experience that a flat (aka unmanaged) team structure can work very well if all of the team members are disciplined. It's also been my experience however that where there is a great deal of overlap in the work that the team members do, where there are two or more relatively strong personalities, or where there is a relatively stressful working environment with a busy workload, then having a team leader or a manager with clearly defined responsibilities is generally essential.

There are a lot of factors involved, however it really boils down to the personalities involved, their individual motivations and career objectives, and the example and guidance provided by upper management that will determine how necessary a manager or team leader position is. Generally, if there is any chaos, and when the team is asking for it, then the team clearly needs leadership. If things generally tick along ok without management input, then perhaps the team can manage within a non-hierarchical structure for a time... at least until the workload and schedule becomes too difficult to manage.