Scene: Wise TA sups their coffee of a morning.
A supplicant developer approaches.
Supplicant Developer: Oh wise and all knowing Technical Architect! Answer our question! What colour should our self-immolation machine be? Red or Blue? We bring offerings of biscuits and everything!
TA: Have you considered maybe not building a self-immolation machine?
SD: I... What?
--
There is a tendancy in organisations to treat Technical Architects as the all-seeing wise sage who knows the answers.
Which is of course nonsense, as we're likely just as confused, plagued by doubt or unsure as the next person. Hopefully we have a bit of experince, have seen a few problems before and know how to solve a fair few things technically, but there's no gaurantee. We're all limited by our own context, needs, biases and experience.
There is a further tendancy to only bring the questions to you that are pre-framed in the context the team already have. We want you to choose between technology A and B may be the question, but that's just what they've decided to bring to frame the discussion. Part of your job is to dig a bit deeper and ask why that's even the choice.
This can be frustrating to people who just want an answer.
But part of the job of a TA is to zoom out from the current context, look at the wider landscape and see if the decision they want made is actually the one they should even be looking at.
What problem are you trying to solve?
Do the options presented address the cosmetic surface of that issue or the underlying cause. The "five whys" can help here. Drill down to work out what led people to think that the self-immolation device was the right course of action. Was that what the Customer asked for? The Product Owner? The Lead Developer? What information did they have at that point?
Too often people fixate on the symptomatic solutions, particularly in cultures that are wedded to a micro-waterfall where the first a developer hears of an issue is when a ticket arrives to build a specified solution. Where the decisions were made without them. One of the things to constantly do in such environments is push to a "technical" view to be heard earlier in the process, and that's often the best place to push to have your voice heard as a TA. So that you can avoid situations where by the time the decision reaches you, your deciding between two or more equally bad options.
People also often have a desired outcome when they bring you a question. How they frame it often is a tactic to get the outcome they want. Consider how often you might hear "should be use this industry standard technology or this other thing?". The same with "best practice", for whom and in what context is it best practice? That matters. Facebook's problems are not your problems and visa versa. I've seen React kill products that could have been a simple web form, but it was implemented because "that's what the industry is doing" rather than because it was a suitable solution for the context at hand. It depends. Always.
Take the time to step back. Look at the bigger picture. The upstream causes and the downstream consequences. Find the underlying problem for real people and look at that. You might need that immolation machine, but maybe it doesn't need the self part.