I once managed a mid-level data engineer who had come from a data science background.
He was technically strong: smart, curious, good at getting things to work. But he didn't really understand why we modelled data. To him, data was something you queried, and designing it felt academic.
Explaining didn't change that. An exercise did. We sat down together and worked through how an end user would actually try to answer a question with the data in front of them: which joins they'd need, where they'd get confused, what they'd have to know in advance just to get a sensible number out.
I didn't tell him what good modelling was for. He worked it out, and after that he started designing from the user's end. It changed how he approached almost everything.
The second problem
The second problem took me longer to spot. He'd grown in understanding but not in confidence. He'd bring me questions he already knew the answers to, because he didn't yet trust his own judgement enough to act without a second opinion.
So I changed how I responded. Instead of answering, I'd ask what he thought. When he told me, I'd tell him to go with it. When he was right, which was most of the time, I made sure he noticed.
That's one of the most useful things I've learned about developing engineers. There are two different blockers, capability and self-belief. From the outside they look the same, and they need opposite responses. Give more information to someone whose problem is confidence and you get a better-informed engineer who is still hesitant.
He's now a senior data engineer at another company. I don't think I taught him much he couldn't have worked out himself. What I did was give him room, and ask "what do you think?" often enough that he stopped looking for someone else to sign off his answers.
From the other side of the table
I care about this partly because I've been on the receiving end of it done badly. I've sat in reviews nodding along to development objectives that sounded sensible: stretch goals, real growth areas, a plan that looked well thought through. Then the work started and the support was thinner than the plan. I'd hit a gap or need a decision talked through, and find nobody had thought about how I'd actually get there. Six months later I was being measured against goals I hadn't been helped to reach.
An objective without the support to reach it isn't a development plan. It's a standard, and when someone falls short of it, the failure belongs to their manager.
When I set a development goal now, I plan the support at the same time. If I can't say how someone will get there, the goal isn't ready.