As much as possible, stay out of the weeds. On any team, if you're the leader, you need to save a certain chunk of your bandwidth for the crises and the big picture. Diagrams are good and coding standards are always sane, but setting up processes where people check each other's work is even better (cross testing, peer reviews, pair programming). Not everyone on the team needs to be a star - the team together can usually overcome any weaknesses in individuals.
The thing I'd recommend is that you resist the urge, as much as possible, to tell people what errors you see in their coding - instead, lead them to seeing it themselves. Remain a part of the collaborative review of development work, but make sure that you don't contribute more than other members. Instead, put the extra effort into encouraging people to see what you see and give plenty of explanations of why the things you see matter.
Don't worry too much about overlap - beyond a sensible breakout of work, you can ask team members to check in among themselves, and then just verify that communication happened. The team will quickly start to look to each other as a way to acheive consensus, and that makes your job about 20 times easier - then all you have to do is be the tie breaker when major areas disagree.
Then save your effort for looking at the team collectively. Each person will have some awesome strengths and some fascinating weaknesses. Ideally, you'll start throwing work at people that suits their strengths while still giving them a chance to work through their weaknesses in ways that don't disable the team's productivity.
The ultimate gold star of team leadership is making people aware of their weaknesses in such a way that they are motivated and well informed enough to start fixing them.