These are how you appear to developers as a _useful_ architect. Sure, there is a lot of other tasks that they do involving design and planning for the future - but the only way as an architect to actually impact software development is to take a hand in building it.
Every architect that I have worked with (my title has been "architect" for awhile now) that didn't spend at least 50% of their time in code was more or less a pretty picture generator - whose documents were ignored by anybody actually building the application.
I think the big point is that developers should trust you. One of the best ways to achieve that is to participate in coding a little. My experience says the architect should avoid the critical coding and focus an quality topics. For example, style unification or linter fixes.
A corollary is that you also need the trust of other stakeholders.
For managers I'd say you need to communicate confidently and deliver. The trick with delivering is to lower expectations early.
It depends on the organization what other stakeholders there are. That is a good separate point actually: Know your stakeholders. Make a list and ask them about their expectations.
These are how you appear to developers as a _useful_ architect. Sure, there is a lot of other tasks that they do involving design and planning for the future - but the only way as an architect to actually impact software development is to take a hand in building it.
Every architect that I have worked with (my title has been "architect" for awhile now) that didn't spend at least 50% of their time in code was more or less a pretty picture generator - whose documents were ignored by anybody actually building the application.