It is not easy to change your habits. I can only share what helped me most to transition to what I do today. I was lucky that I got my role about 2-3 months before the yearly review at which time I got the (anonymous) feedback that developers felt I was not available enough to support them. I remember at the time I responded with the natural reaction of somebody who newly obtained a lead position, I balanced the feedback against all positive feedback which was on the technical front (proven to work architectures defined, technical achievements, technology assessments, etc.). I also said I was available they just needed to ask.
My manager carefully explained that indeed my skills as a technical engineer were phenomenal, but they already were before I got the role of architect and everybody knew this. The problem for him was that I don't scale and he couldn't clone me. The only option for me to scale beyond what I already did was to scale through people. This means for him teams signalling they were blocked because I wasn't available were major. Availability did not mean me sitting at my desk, it meant the developers would not feel blocked because of me. No matter the reason. He made this an objective for me.
The next year I actively worked on this. As you, I struggled letting go my old behaviours. Right up to the moment of the next feedback round mid-year I felt I was not as productive as before. I spent hardly any hours on what I thought was "actual work" (i.e. having my code editor or enterprise architect open) but instead was coaching and instructing or attending meetings discussing issues or designs, or issues with designs. I felt sometimes I did not have enough time to spend with a single person to completely go over the issue at hand. What completely changed that feeling was the mid-year feedback I got. Literally every team reported very positive feedback on my availability. They felt empowered and trusted by me only guiding them (whereas I felt I didn't give them the complete picture). At this mid-year my manager discussed the "seven levels of authority" [0]: (1) tell, (2) sell, (3) consult, (4) agree, (5) advise, (6) inquire, (7) delegate. Where the scale is an increasing level of authority owned by the team or individual. He explained that every individual, and at larger scale every team, is on a different level of authority and I would need to recognize their current level of authority and gradually increase it as their experience grows.
The last half year I kept running my routine of my earlier comment and in addition started paying attention to the signals that belong to the different levels of authority. You quickly notice some people you need to check-up on more often or even co-develop/co-design for a part whilst others have enough from a 30 minute meeting. You also notice some people rather spend 3 days struggling through code than ask a question whilst the latter would help them do the work in half a day. By pro-actively checking up on those people you make sure not to miss those opportunities.
The end-year review was again positive, this time not only from direct feedback of developers but also from team-leads who reported their team members competencies were growing/increasing. Our project dashboards (agile) reported less blocked tasks and more throughput.
In the end nothing can help you change as fast as getting (positive or negative!) feedback. If you struggle it might be good to request something like a 360 feedback (anonymous feedback from direct colleagues on all layers of the hierarchy). See where you stand. Together with your manager figure out actions to remove the negative feedback and improve the positive, and act. In 6 months to a year do the same and see where you stand.
P.s. Let your manager know you struggle. I suspect my manager acted upon my struggles and made sure the team (competency) leaders of respective teams also let their developers know that they should not feel bad about requesting help, even when I looked busy.
P.p.s. bit of a long story without too much structure but I hope it brings you anything :).
[0] Mangement 3.0: https://management30.com/ (didn't like the book too much but it has its parts).