A few principles I've developed over the years. None of these are original — most are things I learned the hard way by watching the opposite fail. But they're what I come back to when making decisions.
The most common dysfunction I see is stakeholders arriving with fully-formed solutions and asking teams to execute. This wastes the team's experience and judgment. The people closest to the system usually know the constraints best. Good collaboration means bringing the problem to the table and figuring out the solution together.
I hold my teams accountable, and I expect them to hold me accountable right back. Leadership isn't a hierarchy of blame — it's a mutual commitment. If the team isn't delivering, that's as much my problem as theirs. If I'm not giving them what they need, I want to hear about it.
The worst architecture happens when it's handed down from a dedicated group that doesn't ship code. Architecture should be a shared practice — every engineer makes architecture decisions whether they realize it or not. My job is to make sure those decisions are informed, not to make them all myself.
The most expensive habit in software is building before validating. I've seen it for over twenty years and it hasn't changed — teams still architect for scale they don't have, optimize for traffic that doesn't exist, and polish features nobody asked for. Good planning needs real input. Ship something concrete, learn from how it behaves, then build the version that's meant to last.