2. your job is transitioning from "doing" to "enabling". You'll be responsible for issues of governance AND operation. Learn the ropes equally. As you introduce successful operational concerns (bottom up) start to generalise them so they can be used as a top-down concern (i.e. i do devops -> we all do devops here, it's part of the training)
3. leading by example doesn't scale - stop. Embrace a teaching method that ends in trust: i.e. 1. introduce a concept to dev A, 2. get dev A to demonstrate it back to you independently (monitor and prompt as appropriate), 3. from afar passively observe future implementations of said concept and revert to steps 1..2 if required, 4. inform dev A that they are trusted explicitly with this concept and that it is theirs to run with - encourage them to onboard dev B in a similar fashion.
4. at the top you're more responsible for team morale than you can possibly imagine - random acts of kindness and/or direct conversations go a long way... whether it's donuts or "a quick catchup" over lunch, do it... regularly (if you find your postponing these kind of meetings you've got a priority inversion issue to sort out ASAP).
5. if someone is dishonest in any way take it to HR before they walk over you and your team/product/department suffers. In other words, with HR's help, address slow/no work or unapproved "wfh" days as a threat.
6. push back against harmful designs and rushed/skipped processes.