Rebuild Your Team
Evaluating career levels/promotions boils down to imposing some ordering on the performance of employees. It seems like a pretty difficult problem to solve from first principles, but it's something you can do in less than 5 minutes if I phrase it this way: "Your boss has just offered you a high-stakes, high-visibility project that will get you a guaranteed promotion if you deliver. At the same time, you need to keep the lights on and keep other product owners happy, so you can't put your entire team on this project. Under these conditions, which people would you choose for the elite team, the business-as-usual team, and the maintenance team, and why?" If you can't answer this question with less than 5 minutes of reflection, you probably aren't a very good manager and are not qualified for the task that's been given to you. When you start to justify why you would put a given team member on team A vs. B vs. C, you start to realize the attributes that you value and which you perceive to be essential to good delivery. However, you will probably notice that the combinations of attributes varies from person to person even on the same team, and this is where it gets complicated.
You can and should solicit feedback from the engineers themselves (you didn't say what industry you were in, but your language strongly implies engineering in general, and software engineering in particular). Not only do they certainly have some strong opinions, but if their views don't line up with yours, that's a big red flag that you need to spend more time understanding their perspective. One way to do that is to pose the same question to them, as a survey with private responses. My guess is that you will find a surprising amount of uniformity in the responses, because folks generally have an intuitive perspective of levelling. You can frame this survey as a kind of informal peer review that does not correspond to any actual restructuring. Be honest and say that you are asking for their help in formulating a levelling guide, and this is one step in the process. Some of them will probably want to give you direct feedback on defining levels, which you should incorporate.
Also, you need to expand your scope by considering folks outside of your team. If you could poach staff from another team, which ones would you go after first, and why? Who are your rock stars that you jealously guard from poaching? Who would you be happy to lose? Which folks around the company are in demand by other managers? Talk to other managers and see if your perspectives align (ask them what their company-wide dream team would look like, etc.). Obviously, there will be both similarities and differences among managers, but also across organizations which have different demands, products, and responsibilities. You need to take into account the varying motivations when evaluating feedback.
I think simbabque's answer covers this decently well. I agree that Monzo's definitions are clear, clean, and a good example to help you make sure you didn't miss anything obvious. Of course, you will want to adapt it for your company/industry, but that should be pretty easy.
What I will add is that while many large companies define parallel tracks for managers vs. individual contributors, those same companies usually stop the IC track well short of the highest manager levels. Obviously, few CEOs will accept an IC that is considered a direct peer on the org chart. And some companies will argue that when an IC gets to a certain level, the scope of their responsibilities is so broad as to be equivalent to a [S]VP/President anyway, so might as well give them a management title. I personally think this is a mistake, because while the broad scope may be true, people who wish to fill those roles don't necessarily want to lead an entire VP org or larger, and giving them a title without an org dilutes the levelling definitions for VP+.
Thus, if your company has a substantial engineering force and many manager levels, I would suggest that you push to define parallel IC levels as high as the upper management will tolerate. Even if you have no engineers who are currently qualified to fill such positions, defining them gives folks something to aspire to and provides more steps on the career path than just plateauing at your typical IC mid-level cap (somewhere near the middle of middle management).
What should an IC at such a level do? Well, they shouldn't just be heads-down working on their pet projects with no oversight. They should be peeping in on significant projects being executed around the company, offering consultation and working to provide consistency around design and architecture across orgs. But they should also be able to pop into any meeting of same-level executives and give a technical briefing about the projects managers wish to discuss. Many times managers conceive of project ideas with little engineering input, and invent fanciful deadlines and expectations. Other times, managers will oversell a project because they are a smooth talker, and a credible technical voice can lend a more realistic perspective without looking like managers sniping each other for position (because other managers can often tell when a project is getting oversold, but calling that out comes with political consequences).
Many times there are broad technology choices which have impact across the whole company, and leaving these decisions to managers who consult with their tech experts turns it into political football rather than a pursuit of the best solution. Having high-level ICs to offer technical perspective can mean the difference between choosing the best solution vs. choosing the solution championed by the most influential up-n-coming manager whose IC rock star chose it as their pet project. But that also means making sure that you promote the best people to such levels, exactly because their actions can have an outsized effect on the rest of the company.
I would also encourage you to rethink the idea that "more reports == better manager". I think most folks here can tell you about a manager who ran a large org, but poorly. The reasons for getting promoted are sometimes only tenuously related to performance, and actually dominated by networking and personal connections. The fact that you led with that example suggests that perhaps you are not willing to think deeply enough about the topic to do a good job. Try to think if you can identify any managers you know who are running an org which is "too big for their britches". I would be surprised if you can't name any. Then think about how they got there.
My personal yardstick for "good managers" is: "promotes good people, and weeds out the bad apples." Promoting good people sounds easy, and yet, I can name lots of times when I saw a less-than-good person get promoted because they are good at "personal sales" more than actual performance. But even more important than promoting good people is getting rid of bad apples. This is one of the hardest, least appreciated aspects of being a manager. Bad managers know when they have someone who is slowly (or quickly) poisoning their team, but simply don't act because they lack the spine and wish to avoid conflict. Of course, a good manager has to know when such a person is killing their team, their org, the manager's reputation, etc. But acting on it is even more challenging, because it involves doing something unpleasant with a person who is, by definition, not fun to deal with.
Sometimes, the bad actor is just on the wrong team, has personality clashes, and could succeed on another team. Finding that other team and helping them to transition successfully is the mark of a truly great manager. That's turning an all-around bad into a win-win. Other times, the person is just a bad apple, and needs to leave the company for the good of the company. Getting rid of those folks is both the least pleasant and most difficult task for any manager. But the managers I respected the most are ones who did exactly that. Getting rid of a bad apple can improve the quality of life for dozens of employees, no matter how much it sucks.
You may find, when talking to your ICs about levelling ideas, that some things you think are important really aren't important to them, and the things they bring up may be surprising and enlightening to you. Unless you have already excelled in their role and have substantial experience, you should listen to their feedback carefully and with an open mind. After all, when you choose to promote someone based on the levels you helped create, you want everyone on your team to say: "Yeah, that was a good promotion. I see a clear path for myself here." If that happens, you'll know you succeeded. The peers are often the final judge.