When I was Director of Vehicle Systems at Orbital Sciences, we did many projects and introduced many products one after the other. Here is an interesting comparison of the leadership on three separate but similar jobs, and the results obtained.
These activities started at the same time, and used many of the same people and methods, and had roughly equal complexity. Leadership styles were totally different.
Project: Maintenance Vehicle Mobile Data Terminal New Product Development
The development team and stakeholders developed a product spec in first month using heavy hitters. All affected parties contributed, argued, hard requirements, hard approaches.
Designers stuck to the spec as much as humanly possible during design and test phase.
Result :
Done on time, slightly over budget.
Used a lot of new people, some staffing mistakes, but otherwise new people worked out ok.
Product was successful. Reusable and well understood. A design update will be necessary to reduce recurring cost.
Lead engineer very uncomfortable due to pressure to incorporate new features and requests to reset the design during development. He stayed with the spec until it was completed and introduced, which was only a period of a few months. The lead engineer was very stressed at completion, and needed to decompress after the effort. The rest of designers were happy with output.
Sales not totally satisfied with results of the specification process, but they brightened up when the product began passing tests and satisfying customers on schedule.
Our early, available and high quality product drove several competitors out of the market.
Resulting product was easily applied to large and small opportunities by several teams. Product was a big hit.
This method used all contributors to nail down the specification. There were disagreements, and since only one product would be designed, there had to be winners and losers during the specification phase. Some of the losers took it hard, and didn't give up on their conflicting positions, creating dissension during development. There was a lot of pressure from stakeholders to change the direction during the design, but this would have delayed introduction, and schedule was important. Requests for changes that missed the specification phase were held off until the next version.
Project: Transit Mobile Terminal for Downtown Bus Routes New Product Development. Bus schedule monitoring and prompts. Must maintain performance during high occlusion of GPS satellites by high rise buildings, using alternate techniques (gyro, route learning, etc).
Consensus was sought for all decisions. All the experts on the job for the duration to evaluate every decision point. No major decision made without consensus, including interpretation of requirements and test. Examine all approaches and opinions, constantly evaluate suitability and evaluate new approaches as they become known.
Result:
At about 50% work complete, hit budget limit, effort stopped.
Completion date never settled.
No resignations, no personnel changes. Whole crew very happy with themselves, but all very unhappy with results.
Many fundamental system performance aspects were not defined even as the budget was nearing exhaustion.
Segment leads formed very tight personal bonds with each other.
Sales was happy with interactions, but became uninterested in product as the design progressed. They said the resulting design became too esoteric and all encompassing, the benefits were too hazy.
This was a very civilized activity, and all the marketing people and engineers felt good about that all issues and concerns were being fairly addressed. In other words, they worked hard at making sure there were no sore losers, like there were in the example above. Unfortunately, the effort as a whole took too long to meet the market need, and in the end the total result was incomplete, and the effort was stopped because the final product anticipated was attractive to no one. The product had been camelized.
Project : Transit Mobile Operator Terminal, All in One New Product Development
One top guy in charge, he makes all the decisions, everyone else on a need to know basis, all decisions in flux until last possible day. Top level requirements were the only ones written down. Many were waved aside. All other direction was word of mouth from the Project Lead, who put in a heroic effort.
Result:
Designed very well for high volume production, test in volume was a bit of a problem. Not well integrated with production test methods.
Met all technical and recurring cost goals.
Successfully incorporated a few in-process change requests from stakeholders, making them very happy.
Did well on budget, except way over engineering budget in areas that the Project Lead was weakest in.
Engineers reasonably happy, one person (of five) replaced due to performance.
Sales was optimistic about applicability to multiple opportunities, however there was no spec for the unit. As such, it was difficult to apply. Reuse involved asking the lead engineer (the king) whether it would work or not on every issue. He had to be intimately involved in any applications of the product. This limited the ability to apply the product to multiple opportunities, due to resource constraints (only one application engineer). #1 above was reapplied to at least 7 other successful systems in a very short time. The product developed in #3 was bid as part of several proposals, but only one was a win.
People were happy on this job, although I did get some "is this another job where (fill in name) makes all the decisions, and we do everything else?" comments. However, everyone knew where they stood, and the product was turned out in very large quantities for a small number of opportunities.
It depends on your personnel.
If you have someone who has the background to call all the shots, method #3) is pretty good. But it has to be someone that can actually do that, not just someone who thinks they can. The people required to support the lead do not have to be that talented, or even motivated. If there are gaps in the skill set of the lead, it is good to try to find a teammate or two that would fill those. And he will have a hard time disengaging to design the next product, since the design decisions and trades won't have been made public, and the lead will have to continue to support any reuse of the product. Some people like this situation, and support the product for years. Some find it career limiting.
Method #1) produced the most reusable product, but many stakeholders did not like settling on the design before starting the designers. Making a decision on a product four months before it would be sold, and sticking to it, was just beyond their kin. Method #1) was developed by our company specifically to deal with changes in market. If you could design a product fast enough, you would not have to worry about the market changing before you got the product out. It would also be useful if you had a lot of new people, which we did.
The engineers liked the process of #2), where they had constant input and design changes were regularly incorporated, but did not like the result. Emotionally, it was much better on the engineers, but someone or something has to be the heavy when it comes time to move ahead with the design. That is built in to the the other approaches: either (#1) we don't start until we agree on the spec, or (#3) I'm the king, do it because I say so.
Some customers like #2), especially if they would like to be involved in the design. This does drag things out, because in general, most customers cannot keep up with the pace of decisions that a crack design team can maintain. So #2) is expensive, generates an optimized product, and provides decisions that are well documented, but is not for anyone in a hurry, or is worried about budget.
Marketing and Sales liked #2) and #3), during the design phase, because they felt they could influence the design in progress more easily. They respected the "King" status of #3). But they liked the overall results of #1) better. They ended up with something easier to scale and apply to multiple customers.
So to get a product out, there is a fork in the road that is made clear in this example. You can either:
Choose a point direction, either by negotiating a spec, or following the vision of an individual. This will get the product out quickly. This can be hard on engineers and other stakeholders, in that some ideas for the product cannot be implemented based on program constraints, and someone has to be the heavy, to resolve conflicts. The strategy here is to get hard feedback on the product, and obtain design wins early. The design will have its weak spots, and a redesign is expected.
Allow the system to evolve through consensus. This can track the needs and ideas of the engineers, marketing and the customer much better, but the process is much more involved and lengthy. So this is easier on the engineers and other stakeholders, and shows progress every day, but the closure criteria is a serious issue that in the case above, severely impacted and finally killed development.