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).
Cycling through implies (to my mind) casually being around your team, checking in, and helping where needed.
Working remotely its a bit trickier? My team and I dont use slack or other chat platform, so for me to check in would require calls, meetings, emails etc, which is a bit more formal and disruptive then "cycling through".
That are some things that readily come to mind. Probably you can find more if you think about it a bit longer.
You're not going to find out if somebody is happy by "casually being around".
“my default loop is "First, cycle through all my developers and make sure that I have equipped them to be happy and productive in their jobs. Second, find something to do. If possible, delegate it; if not, do it. Repeat."”
My biggest productivity gain was when I realized I should measure my productivity through the productivity of my developers. By the same calculation as done by the author I can only increase my own productivity so much but when I do the same for all my developers that adds another layer of multiplication.
This means I regularly enter the office and don’t even turn on my laptop (monitors) before checking if any of my developers need my help. Helping them be productive is my first priority. When nobody needs my help I pick up a task from my todo list but only if I cannot delegate it or it is a short task. I try not to pick up any task that is critical for my developers progress because my days do not have enough focus time to work on the same topic for more than 30 minutes to an hour without interruption.
This does not mean I do not take focus time sometimes, I do, but usually this is for getting my state of mind documented so I can share it with my developers and ask for their input to improve or reshape it. This helps again to have everybody understand the bigger picture so they can be more productive without my direct help and make decisions without requesting my approval. Also, because everybody involved contributed to the vision it feels better to work on it for all of us.
The same holds for meetings. If somebody requests my attendance in a meeting I request the agenda of the meeting and if the request is valid I’ll join as helping to unblock multiple people is important. If I’m not the right person I point them to the person they need to get into that meeting.
So, in short, I devote my time to helping my devs get 10% more done everyday and 1% better each year because that scales way better than just improving my own. (Though you could say that also improves my own?)