(...)
That can certainly happen, but I haven't seen any of that. Mostly, the super star is the de facto head of the design team and makes all the important technical decisions. He's also the one that stays long hours, blows away vacations, and passes judgment on everyone elses performance. The official project manager is often just a clerk to track progress, and report to upper management without disturbing the "super star". I've seen such people in various forms, with various methodologies, but always at the center of design and development. Were they to be subject to chasing diversions, management would be unlikely to trust them with running a project.
I'm certainly not a "super star" engineer. At best, I'm the personification of mediocrity. What I do best does not qualify me for running a project or making important decisions. So, I follow along, and do my best. However, I too can be tempted by diversions and distractions. At Granger Assoc, I decided that I needed to learn how to use the newly acquired Applicon 2D/3D CAD system (which incidentally ran on a DEC PDP/11-34 and later a VAX 11/750. I think this was 1982 or so. In the guise of learning the system, I was actually designing an alternative product to what I was suppose to be designing. I would spend 10 hrs/day, 5 days per week, on the real project, and 2 hrs per day on the CAD system. The problem occurred when the division VP started looking over my shoulder at what I was doing, liked what he saw, and assumed that was the produce we were designing. When he finally saw the real product, he was seriously disappointed and rather angry. Oops.
I never even suggested that one was necessary. I indicated that in several of the companies where I was employed and worked as a consultant, there was almost always a "super star" and an organization designed to support the "super star". In the one example where one was missing, was a dysfunctional mess. A "super star" is probably not necessary, but I found enough evidence that I might suggest that it's an effective organizational structure for engineering.
Incidentally, so my point doesn't totally get lost in the topic drift, I believe that the trick questions supplied by Google for employment interviews are more geared for hiring "super stars" than for mere mortals and ordinary employees.
I wish I could say the same. The most effective method was for managers to hire former associates from a previous employment. At least they were hiring a known quantity. That didn't always work when they hired on the basis of friendship rather than competence, but otherwise, it was effective. Unfortunately, it's also inefficient and rather limiting, so there were plenty of recruitments, job faires, experiments, interviews, ordeal processes, and filters. For technical people, I noticed that a senior level engineer, had a much better idea of the abilities of someone with less experience, than the reverse, where a beginning manager might be hiring someone with far more experience.
Again, I which I could say the same. At one company, the product manager hired a friend as a test engineer. Instead of designing the test plan into the production cycle, he sat on his posterior and played games on the computer all day. When I complained that I needed some help building a pilot run, I got him. It then became my job to find something for him to do. I failed. However, that's an extreme case. In general, even random hiring practices were at least 75% effective, which suggests that almost any hiring tests and recruitment method will work well enough if one leaves open a method of getting rid of the losers.
Incidentally, at the same company, I was handed an engineering technician. Just one problem. He couldn't solder, had limited mechanical abilities, could barely read a schematic, didn't know anything about RF, hated Jews, and had a really bad temper. He had just been kicked sideways out of production and into engineering because of his bad temper. He was also a former police officer and fully capable of seriously injuring me, should he be so inspired. My job was to get useful work out of him, and survive.
I tried him out at just about everything that I had control over. He couldn't build anything. Running test equipment was a problem. Documentation was not within his limited abilities. I was about to give up when I noticed that he had some interest in running the computer that ran the test system (HP 9816): The HP supplied software worked, but could use some customization. Overnight, he learned how to run it, followed by learning how to program it. Within 2 weeks, he knew more about it than me. I kinda over-did the programming requirement in order to keep him busy, but he did well with everything I threw at him. When we parted ways, he was going to go back to skool, get a degree, and eventually become a programmer. Nice.
Moral: You can't always hire what you want. But if you try real hard, you might get what you need.