You're not a 10x engineer. You're a 2x who hasn't figured out yet how to teach other engineers what you know. It sounds like it's past time you got started, for your own sake as much as that of those around you.
> So on average, the other team members complete about 3.2% of the work, and he does 71%.
Without further context, though, those numbers are meaningless. There's been spans in my career where those sorts of numbers would apply to me but not because I'm an nX developer but because, e.g., a lot of the stories were related and it made sense for me to do them as part of an ongoing sequence whilst the others handled, e.g., bug fixes in other areas.
It might be helpful to think about what you mean by “help.” It sounds like people fairly frequently come to you for your opinion, to get an answer to a question or to solve a problem. It is extremely easy to give them what they’re asking for (the answer, a solution,) and it even feels helpful in the moment.
This doesn’t help people grow in the long term, though. It builds dependence on you and your skills. You can quickly become the bottleneck (unintentionally!) and the “smartest guy in the room” by virtue of handing out answers and hoarding domain knowledge instead of developing the people around you.
I don’t know you, so I don’t know if this is what’s going on. If it sounds familiar though, I have two suggestions. First, read The Phoenix Project and pay attention to the character arc of Brent and see if his journey rings any bells. Second, next time someone comes to you for help, or asks for your opinion, instead of giving them the answer directly, coach them through the problem solving process by asking questions until they arrive at the answer themselves. This will help develop that problem solving muscle that they need and help them to level up.
It's its own kind of skill, and takes deliberate effort to develop just as with any other. Being a great engineer, as you evidently are, is no guarantee of being a good mentor, any more than of being a good pilot. You should expect and intend to work hard at it.
It's reasonable to expect it to feel weird at first, especially if you're not used to or comfortable with working closely with others. The good news there is that that gets much easier with effort and practice, too.
It can be easy at first to want to just do stuff while people look on. You want to watch out for that; it can be gratifying, but doesn't much help anyone learn.
The key, I think, is instead to find the right balance between talking through your analysis of a problem and how you work through it, and giving whoever you're working with opportunities to practice doing the same with you as a sounding board and counselor.
It sounds basic, maybe, put like that. But it isn't; "problem" here can mean anything from "implement a function to add two numbers" to something that extends across an entire software stack and touches every level of infrastructure. It can be building an MVP from scratch. The point is that it's what your current mentee is ready for, or maybe just a little past that if you think they've got a habit of undervaluing themselves and could use a chance to build some confidence.
Above all else remember that your essential purpose as a mentor is to make yourself no longer necessary to the person you're mentoring. You are trying to engineer yourself out of this job, because to have done so means you've succeeded.
You needn't worry too hard about what comes next, I think. A good mentor never wants for work, and it's a surprisingly good way to keep your own skills sharp, because you can't teach like this unless you really understand what it is you're teaching.
Too, demonstrating you can work well with other people this way makes it very easy to continue into management, if that's what you want - and it is worth thinking about that, at our age. Some folks stay great engineers all their lives, but not all. And hell, after a few decades doing the same kind of work, some folks just find they want a change.
