I hope you're an architect-level or at least getting there. I kind of feel sad for some architects though, they rarely get to code anymore, their existence is meetings, but presumably their ability to coordinate and prioritize the big picture outweighs having them apply their coding chops. For coders that can't give up coding it's a self-limiting move to resist that direction, lots of companies seem to have pressure that to advance you have to do 'less'.
When you do your big prototype solutions is it usually something you toss over the fence to the team that now takes on the rest of the dev/qe responsibility or do you try to work closely with one or two people on that team as you build it? I mostly ask because another sort of altruistic (or selfish if you're just killing time until the next round of meetings) thing you can do with your role is go around dropping mana on heads-down coding grunts by working with them directly on something; they'll probably have a nice feeling of appreciation like this person, who they aren't quite sure does what but must be very valuable, is taking time to work with them, and hopefully you teach them a few useful things from your deep knowledge to boot.
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).
When you do your big prototype solutions is it usually something you toss over the fence to the team that now takes on the rest of the dev/qe responsibility or do you try to work closely with one or two people on that team as you build it? I mostly ask because another sort of altruistic (or selfish if you're just killing time until the next round of meetings) thing you can do with your role is go around dropping mana on heads-down coding grunts by working with them directly on something; they'll probably have a nice feeling of appreciation like this person, who they aren't quite sure does what but must be very valuable, is taking time to work with them, and hopefully you teach them a few useful things from your deep knowledge to boot.