1. get 2 mentors: a technical one and business one (doesn't need to be domain specific)
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.
Number 5 reads a bit like this: if an employee is not motivated enough, instead of trying to find the cause and mitigating, go on the hostile path and get HR involved.
In fairness, this could be a good advice for roles that are easy to hire for (e.g. minimum wage manual labour).
I'm of the opinion that dishonesty is serious because it's an irreconcilable breach of trust. There are many things I'm happy to deal with internally providing there's a frank account but once someone intentionally misleads another it makes individual management untenable.
Separately it's a HR problem because of the nature of certain types of work. I'm struggling to fit my view with neural diversity though - some devs say dishonest things without malicious intent because they lack skills to effectively communicate.
Sometimes people reframe mistakes or lapses in a "dishonest" way to save face. I think it's important to use those occurrences as opportunities to show that it's safe to be honest instead. Allow them to come clean and show that the highest priority is correcting the problem. Running straight to HR instead of creating a teaching moment could increase distrust and the incentive to be dishonest.
There is a line between this and manipulative dishonesty, of course. Bad faith (when it's clearly that beyond reasonable doubt) should be treated with close to zero tolerance.
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.