Kind of. Due to some internal politics, we have an 'architecture team' being formed, by someone who I don't want to work for (but who wants to poach me). Meanwh

Kind of. Due to some internal politics, we have an 'architecture team' being formed, by someone who I don't want to work for (but who wants to poach me). Meanwhile I've been the de facto architect for a year and a half for software development. My actual title is 'backend tech lead'. As to approach, it depends. Occasionally I've written and hosted a solution, and given endpoints for people to test with, before then walking people through the specifics and bringing devops on board to move it to production, and then will still actively take a hand in making changes/fixes/etc. Other times I've basically just POC'ed it, and then suggested to a team "Hey, this looks like it will solve a problem you're facing, here's some POC code, maybe play with and evaluate this approach, see if it'll fit your needs?" and they have, and in the process have learned more about the particulars than I knew, so that they're in a good place to do the real evaluation and decide what direction to head in. And still other times, especially common with juniors, when someone hits a roadblock, I'll sit with them, seek to understand the problem, and either explain the nature of the problem, and some possible solutions, and leave it up to them to pick one (since they have the most domain knowledge), or work/talk with them to work to and understand an ideal solution (if it doesn't require domain knowledge I don't have).