Got any tips for a newly minted Solutions Architect? Coming from a senior software engineer background but want to know some things to think about as I switch to a more hands off architecture role. Looking to take the next month soaking in some inspiration and advice.

My advice is don't be too hands off

@Crost yeah, I definitely want to be a grounded architect, stay current on coding so I don't lose touch

@Crost @raginggeek , guys, I have the opposite advice.
Imagine that GitHub copilot was developed circa 20 years ago, and there are about 500000 niche alternatives, each with it's own pros and cons and quirks.
And worse, you cannot use the same one twice at the same time.
This is life for an architect, at least in my experience.

You have to get used to "programming in English*", explaining to several people what you want and letting them be awesome on their own.

Yes, you have to save some time to do your own code review on their code, and update yourself on new tech, but implementations will not be exactly as you want them. Chill out.

Another thing, one dev can be sure to deliver 10 story points in a week, but an architect is responsible for 100+. You will never deliver it all, it's more like a range between 75 and 130. You got more risk, more uncertainty on your hands now.
But also one hack of a platform. Tune it up and make it your own!

* insert your native analog language here

@JsonBoa if you aren't hands on whatever you ask people to do will be misunderstood because very few people understand or have tried to learn about software design. Hands on != Micro manage, it means check in on people, spend time pairing now and then, work with developers to come up with designs and implement some of it with them. If you throw stuff over the fence to devs you may as well not be there as it won't be what you specified anyway.

@JsonBoa @Crost thanks for your input I can definitely see where getting hands dirty can bog you down in terms of being able to do the main job of choosing technologies and communicating across layers, and I can see where it is also important to have a good integration with the devs. I think both approaches can work and perhaps at different times in a team lifecycle. I suspect initially when I get on board this new team I will have to get a little dirt on my hands according to the manager there, but hopefully we can build a team I can trust and then code reviews and Personal POCs can carry me in terms of making sure I make good choices that the devs can take on and build awesome things with.