Realize that you are / should be in control. Make sure you get mandate from the higher ups, that you get to say yes or no based on your own judgment. But don't rely on yourself for everything, work with your team as well. Realize that you're a manager, you manage people, priorities, considerations, etc, and that for purely technical decisions you rely on input of your team a lot.
Make sure that technical decisions are documented (e.g. via an ADR), making sure to document what you and your team know and consider at the time of writing. This is a pushback to hype-driven development; you don't want to be stuck with a bad decision just because one team member showed up at work one day with a feature implemented in technology X without proving they've done the work for it. And you don't want to have to waste time with future employees explaining (again) why technology X is used - you can refer to the docs, and if they want to challenge it, have THEM come up with counterpoints, have them sell it to you and the team, and have them defend the time / effort investment to change the technology.
Re: hiring, always do a technical interview, even if you're hiring internally. Involve your existing team members, they have to work with the new candidate after all. Have the applicant do a small project (4-8 hours) representative of the technologies and context of your project in their own time, and challenge them during the interview (the goal being they can prove they wrote and understood the code they produced).
It stands for Architectural Decision Records. More info here: https://adr.github.io. We use this at my work to keep a record of our decisions, as the name implies ;-).
Make sure that technical decisions are documented (e.g. via an ADR), making sure to document what you and your team know and consider at the time of writing. This is a pushback to hype-driven development; you don't want to be stuck with a bad decision just because one team member showed up at work one day with a feature implemented in technology X without proving they've done the work for it. And you don't want to have to waste time with future employees explaining (again) why technology X is used - you can refer to the docs, and if they want to challenge it, have THEM come up with counterpoints, have them sell it to you and the team, and have them defend the time / effort investment to change the technology.
Re: hiring, always do a technical interview, even if you're hiring internally. Involve your existing team members, they have to work with the new candidate after all. Have the applicant do a small project (4-8 hours) representative of the technologies and context of your project in their own time, and challenge them during the interview (the goal being they can prove they wrote and understood the code they produced).