I empowered the Dev Team, now I'm afraid of the decisions they are taking

> I'm a bit scared of following this path. If we fail it

> will be an horrible mistake.

> Am I doing something very dangerous?

Of course you are. That's precisely why you need to time-box and control the risk in Sprints.

The PO should have an understanding of risk appetite, and of what empirical evidence is needed to mitigate it.

Also when we talk about empowering and allowing teams to self-organize, they should but within a boundary. We cannot allow a self organizing team to convert a Banking business into an E-commerce.

I stepped aside as technical director and gave full authority and responsability  to the dev team on technical decisions.

Dev team seems to me very responsible  and skilled. However they immediately decided for a rewrite from scratch of our software, and for a completely different technology that they never used.

I'm a bit scared of following this path. If we fail it will be an horrible mistake.

Yes, it seems to me that you're doing a very dangerous team. Is there a reason you're giving the responsibility to the dev team to rewrite your software? And why are you accepting a technology the team has never used? Is there any historical data of the success of this new technology? You need to mitigate the risk involved in doing this as well.

but within a boundary

=> Which kind of boundary? By which mean(s)?

With in a Sprint, the Sprint Goal sets the boundary. For a product, its Product Backlog and Vision sets the boundary