You can do it by learning the concepts and understanding them well. Then at least doing the "hello world" of the concepts you have learned.

There is some insight you get from implementing the "hello world" of the concepts that no amount of reading the theory alone can teach you.

By "hello world", I mean the smallest thing you can build practically to demonstrate your understanding of the design or architectural concept. You can then decide if you want to go deeper. But the "hello world" is a must. Your reports will trust you more.

For example, for software design and architecture, your devs might build entire services with lots of business rules over many weeks.

Your job would be to know how to design interactions between multiple scalable services, monitor them and derive insights. If you can create really small prototypes of services that just serve up one api that says "hello world" and connect those services with queuing systems, then set up monitoring for them, define slos and create simulations of failures and triggering alerts. A dummy project like that. You will learn a lot and can actually support your team when they get stuck. You can do this over the weekends, and you will get better over time creating simulations of design problems.

Also, 14 people, do you manage them all directly? You might be spending all your time just managing projects and people. Probably time to reorg? You might want to start training some people (seniors who actually have great people skills) to take some of your direct reports and those new managers report to you? Your leadership will then still cover fourteen reports but then you manage a fewer number of directs.