You are listing ways to achieve certain "properties". One-on-ones are a way to give an outlet for people to talk openly about what concerns them most and be th

You are listing ways to achieve certain "properties". One-on-ones are a way to give an outlet for people to talk openly about what concerns them most and be there for them (and yes, each other too): basically a way to ensure you are in touch regularly. Almost any "zero tolerance policy" is simply an act of agression: you should strive to not make gossip or politics influence your decision making, thus reducing it to side-chatter of no significance (and yeah, it shouldn't hurt the team dynamics if two colleagues joke on account of someone's mix of wardrobe colors). TDD and continuous builds are not for a manager of engineers to decide on: they are tools to achieve iterative, piecemal delivery of value, and that should be the goal. Technical teams are fully capable of coming up with ways to satisfy this. Even your rule 4 is too rigid: you want to both praise and critisize publicly while ensuring nobody is getting singled out and shamed (if a critique will make it obvious who did something bad, private may be the way to go). You should publicly bring up failures to ensure we learn from each others' mistakes too. Sometimes you should also promote people on their potential, not on their results: some people might be great at architecting stuff or so you might believe, but there is simply no opportunity to put them into a role to show themselves off. You can either wait until they just move on from your company or team, or throw them into doing stuff they haven't done officially before (basically "promote" them, though the lines are very blurry in this example). The gist of good management is: 1. Open, transparent and direct communication with continuous feedback and discussion of personal and team goals, but also with some checkpoints to look back on a longer period 2. Nurturing an environment where it is welcomed and encouraged to challenge each other, and especially your managers! 3. Enabling and encouraging engineers to take ownership and responsibility for projects, by incorporating their feedback and ideas into your process and roadmap. 4. Leaving as much of technical decision making to engineers, even if you have a lot of experience from your "past life" as an engineer: do give them feedback and opinions, but let them make the call (unless they ask you to choose between two similarly viable options) 5. Keep the process minimal, and 6. Try to teach them how to recognize the next minimal step that brings value for any project to enable proper incremental, iterative development and delivery.