In a comment, you say
in the current example the dev lead seemed to have proposed a solution but the dev still can't make it work. I'm chatting with the dev on a communicator trying to understand why he can't make it work but that's virtually impossible. He wants a call with me to explain, otherwise he can't explain. So I will spend an hour trying to understand the context why he can't make it work again.
As a manager, you are supposed to manage resources. You are not a backup dev lead. So what you should do when you get feedback like this, is talk to the dev lead (a human resource that you are managing). The dev lead should be the one helping the dev. The dev should be spending that hour giving the dev lead that context, not you. That's why the position of dev lead exists.
If you are going to have a phone call/meeting to discuss this with the dev, it should also include the dev lead. But it doesn't sound like you're to that point, because that's something you'd do not at the instigation of the dev but of the dev lead. You would do it not to mentor the dev (not your job, at least on technical issues) but to mentor the dev lead.
When you get promoted, it tends to be because you were good at the previous job. So if you were a dev who was promoted to dev lead as a good dev and then promoted to manager as a good dev lead, then it makes sense that you would be a better dev than the dev and a better dev lead than the lead. But you shouldn't be practicing as a dev or lead at this point. You should be helping the lead learn how to mentor. And the lead should be helping the dev.
What I have seen happen, and I suspect it is happening here, is that the dev is finding you a softer touch than the dev lead. I.e. you give more help. So the dev would rather talk to you than the dev lead. Unfortunately, I don't have better advice than to stop doing that. When the devs are asking you for help, you need to push them back towards the dev lead. And then follow up with the dev lead to make sure that the lead is helping the dev (so a five to ten minute phone call with the lead instead of an hour phone call with the dev).
It's possible that the dev lead is feeling too busy to help the devs. If that's the problem, then you need to set priorities (a management responsibility). A dev lead should be spending at least 20% of the time leading. If the lead is instead doing a developer's job, then you need to refocus the lead on helping the other developers. If this leaves you short on developers, then you need to hire. Or set more appropriate expectations about what work your team can do.
Others have noted that pair programming is another alternative. That's certainly true. But I don't know that it helps you now, as you've already started down the dev lead path on this problem. At this point, it's the dev lead who should potentially be pairing with the dev so as to implement the existing proposed solution. For future problems, you might encourage developers to pair with other developers before escalating to the dev lead (or suggest to the dev lead to encourage pairing). And again, discourage developers from escalating technical problems to you. Help them by encouraging the dev lead to take the time to mentor, not by substituting for the dev lead. Or by assigning another developer to help.
Anyway, my point is that you should immediately go talk to the dev lead to find out what the lead sees as the issue. Is it that the lead doesn't have time to work with the dev? (Free up the lead's schedule.) That the dev is too stupid to understand? (This is when you might meet with both and take the hour to get the full context, to find out if the dev is a bad student or the lead is a bad teacher.) That the dev hasn't asked for more help? (The lead should follow up with the dev.)
In fact, IMO, you should have already done this. That that wasn't your first reaction to the situation is a big part of why you are struggling. Because you are trying to act as a dev lead rather than as a manager. And you're right, you don't have time to be a dev lead if you are the manager. As a manager, you mentor the dev lead. Delegate (technical) mentoring of the developers to the lead. You set priorities, allocate resources, arrange help with impediments, and interface with other managers.
It's your responsibility to see that the dev gets mentored. It's not your responsibility to do the actual mentoring. Delegate that. As a manager, delegation is your job.