Then you will need two senior devs. This is because rockstar devs rarely want to mentor junior devs nor attend meetings.
Most inventors are not professors.
The idea of a "rockstar" you seem to be referring to has, in my experience, been a dev who can go into a corner and pump out high volumes of code with little supervision or collaboration. That's great, except no one else can make sense of the code they pump out, so when it comes time for the next guy to add a feature to the rockstar's mess it takes 2 to 3 times as long as it should.
I've also had to clean up messes by rockstars who made unilateral decisions about incorporating new technologies into a product. Like building out a single part of the product in React with out asking anyone else. You see, the rockstar didn't like meetings and didn't want to make the case to the rest of the team for why we should all learn React and gradually switch over. Instead, he just stuck it into the code. So now, you have a couple of views built as React components, and the rest of the thing is in Backbone. No one else knows React or has time to learn it, cause we're blazing ahead really fast. They just get very confused when they have to change something in those components and it takes them forever. But the rockstar got to have his fun and play with new tech.
This conception of a "rockstar" isn't a great developer... it's a selfish, cocky developer. When you hear "rockstar" dev, you shouldn't hear great performer. You should think of Keith Moon trashing his hotel room and driving his car into the hotel pool.
A great dev knows the value of documenting their code and writing testable code. A great dev knows the value of taking the extra time to make code easily understood and easily modified -- that sweet spot between spaghetti and over engineering. A great dev loves to mentor junior devs, enjoys walking other devs through their code, is happy to discuss design decisions with the team, and willing to admit when maybe their idea isn't the best one.
A great dev doesn't think they are god's gift to code, they are humble enough to understand they are one part of a team. They put the team first and work hard to teach others what they know, while always remembering they don't know everything.
I have worked with a Musician with Phd in music who taught him self coding after an accident broke all the bones in his feet (drink had been taken)
It was fun in the pub when some hit tracks came on he would say ah I think that's one of mine :-)
Eventually in the 90s, some developers really took the rock star bit to heart and started plastering their own names all over their output (cf. "John Romero's Daikatana", "American McGee's Whatever-American-McGee-Is-Working-On-Now"), but for the most part, developers at the time hated the rock star characterization.
I don't disagree with your "great dev" qualities but there is more needed to make a "great dev". Otherwise all the documentation, code ease, mentoring, being a part of the team, etc. is not going to make the code useful to anyone.
Second, I hear this extremely often: Rockstar devs don't like to mentor, Rockstar devs don't like to write documentation, Rockstar devs don't like to write tests.
At what point do you need to reevaluate your definition of a rockstar dev?
The hiring filter is a powerful thing. It allows you to find very special people if you know how to look. It's also a feedback loop. Getting momentum with a program like this is the hardest part. Once it's going it practically self sustains. The biggest part of your role becomes quickly firing any mistakes.
Are you looking for someone who can parachute in with expertise on a specific tech and churn out working code themselves?
Or are you willing to accept more lag time and less initial code productivity in exchange for a deeper bench and sustainable team?
There are times and places for both of these developer types...
Rockstars are lone wolves, write unmaintainable code that works quickly for demos but gives the company pain for years to come as nobody can figure out how to make it stable or maintain it. A rockstar's reputation is self reinforcing because it's easy to get a lot of shit done when one doesn't have to worry about maintainability, communication with the rest of the team members or the company at large, and service.
Senior devs balance development work and "service", a term I'll borrow from academia - hiring, mentoring, speaking, writing docs, etc. They either find fun in these tasks as well (I legit enjoy interviewing and mentoring), or understand this is a necessary part of being a well functioning team player at a senior level.
Then you can hire some boring reliable folks from the khaki-and-polo brigade to help upgrade version 2 to version 3. This is when you have an opportunity to hire juniors and mentor them on what good software actually looks like, and how to make good-enough software better. The ninjas will probably leave at this point, and if they have done their job, the company will never need that level of expertise again in a permanent employee. The gurus will stay on to be an expert in your specific system, and teach the new people how to preserve its grandest traditions.
The problem is that a lot of companies never get to what I call "version 3". They might slap higher release numbers on it every so often, but if they never did a clean re-implementation of the quick-and-dirty prototype, that's still "version 1.X", no matter how high the numbers go. You put a junior in that environment, and they're not going to become a stable maintenance developer, and that's where the majority of the jobs will be for the foreseeable future, especially for inexperienced people.
To sum up: rockstars live fast and die young; ninjas quietly demonstrate incredible skills, and vanish; and gurus are the high priests for your established project, who will eventually pay off all your tech debt, if you let them.
There are different breeds of senior developer, and you really want the gurus teaching juniors when they start to run short of other useful things to do. If you don't have the kind of company that is mature enough to evolve a developer into a guru, you won't be able to handle juniors. And there aren't enough companies that can handle juniors. It may be because they aren't honoring the full software lifecycle that includes the long, long tail of maintenance mode.
I think the never getting there often happens because management isn't aware of the current quality of their software vs hypothetical quality of a rewrite.
And I get it: I imagine every one of them has been burned by an overly optimistic developer. "It'll be rewritten in 3 months and run 2x as fast" types.
As a discipline, inculcating "respect that the years of person-work in the current version weren't done by idiots solving unimportant niche use cases" would be very healthy.
When a person takes on for themselves labels like rockstar, guru, ninja, etc. I don't doubt that they can write code, but I certainly doubt that they can write code that fulfils the needs of those who will be using it.
Labels likes these are a detriment to the profession. If we want businesses to take note and consider those in the IT profession to be anything more than ignored, we need to lift our game a long way.
What is IT known for (in the general sense), games, social media, search engines and lots of crappy software that users have to fight to get anything done.
Yet we have people and companies that produce great software that fulfils the needs of those who use it in a way that is not detrimental to those users.
It's coming up to forty years that I have been involved with the industry and I hear complaints every day from users who are frustrated by the inconsistencies in the software they are using, whether it be social media, business software, games, etc.
In general, as an industry, we are far too arrogant about our own self-importance and what we develop. Whether it be the likes of Apple, Oracle, IBM, Google, etc, the industry has forgotten that they only exist as long as people will tolerate the bull dust that is thrown at them by these companies. We are always looking for the "next big thing", yet many of the actual needs that we could be filling are not being done. We like flashy and not substance.
The frustrating ones are those who talk a good talk about "doing things right" (and, generally, talk a lot...), but then work on something for an age and come back with a solution that's objectively worse than the "RIGHT NOW" solution we've been using in the interim.
The others can be "foundation developer", "transition developer", and "maintenance developer". It's still meaningless as long as different companies won't standardize on those titles.
We likely all know which category we belong to now, and which one we want to be. We also know that any company that asks directly for a "rockstar", "ninja", or "guru" is probably one to be avoided.
This is not a great example. In academia, that's because they are fundamentally different jobs in most cases.
Most of the professor roles are not teaching their research, and where they are, i would bet your best professors are the inventors. But most are researching x and teaching y.
By contrast, in software development, the devs should be teaching, because what they are teaching is what they are doing on a daily basis, and the knowledge they've learned in how to do that well.
The notion that people who refuse to mentor or attend meetings (assuming these are symptoms of the same "not team player" phenomenon, and not something else) are rockstars is, imho, pretty misguided.
Even if you assume the 10x people silliness is true, each person mentoring 2-3 new people and building them will make the organization more productive than your 10x person fairly quickly.
(Again, situation may be reasonably different if you only will have a team of one or two, etc)
I don't agree, senior tasks are often much more high-level and related to figuring out requirements/stories, or their tasks are hard enough that explaining them to juniors is not the most productive.
"hard enough that explaining them to juniors is not the most productive" I strongly doubt this. Most of the differences i've seen over the years are in approach to complexity, and not level of complexity themselves.
One aspect of teaching is explaining your inventions to your peers.
But another aspect is telling a new graduate what a version control system is and why you need one. Then doing the same for your build system, continuous integration system, staging environment, code review, bug tracker, style guide, and so on.
Seems to me those are quite different skills - I can easily imagine a person who is good at / enjoys one might not be good at / enjoy the other.