In a similar vain, try to prevent your team from knowing when other members of your organization have quit or been let go. Also, do not announce in advance that a new person will be joining your team. Remember, you want to keep your team in a constant state of disorientation.
Make sure to have at least one subordinate with authority over the rest of your team who can be the "good cop" to your "bad cop".
Use burndown charts as a way to measure individual performance, and immediately point out a team member is "falling behind" when their velocity is even a smidge less than it was the last sprint.
Turn your daily standups into status updates that only you are allowed to be the master of. Discourage your developers from self-organizing and performing standups on their own when you're late or not around. If your developers take the initiative to give you notes on the standup you were away from, display a lukewarm demeanor that tells them that their notes will never be read.
Speak as if your team is in competition with other groups in your company. After all, why should they be collaborating when they should be working?
Frequently ask your team whether they know about some new and/or obscure tech they problably haven't heard of before. Even better if the tech is made up! Your team members must feel intellectually inferior to you at all times.
Randomly pull aside individual developers on your team and give them a pop quiz on how one of their fellow team members is doing. The point of this is not to learn anything about the other developer, but to sow distrust and subtly communicate that you know everything that's going on.
(^^ Yes, that's based on something I actually experienced)
If one of your devs writes some code that you don't like, subvert the team's code review process by insisting they have a one-on-one meeting with only you. If any of the other devs like the code you don't like, you definitely don't want them around to defend them. This is your team, so take full control of it!
When a developer implements something in a way that you don't like, compare it to some nebulous standards, guidelines, or systems that don't actually exist anywhere on paper. For example, you can say that the new UI feature "simply doesn't align with our design philosophy." That philosophy doesn't have to exist because, hey, you're in meetings all the time, so what difference is it to you? Make sure that it never exists because otherwise it can be used against you. The point is to look like you're the only person who truly knows anything for sure while disarming any arguments that will waste your time.