Wow, I can't say I'm surprised at the quality of the answers. I'll add a couple of my own:
.) be mindful that different members of the team are on different trajectories skill set wise. (beginner Exs -> juniors -> mids -> seniors -> etc)
I like to pair members with technology whose stability is inversely proportional to their experience.
More experienced engineers design tighter interfaces in the face of increased variability in final spec.
Whereas technology that is older will usually have a good breadth of info either in house or available on Stack Overflow which means the problems (and communally derived solutions to them) are accessible.
This I've found results in having to clean up less code overall, which helps build team momentum.
Which is my next point.
.) Team Momentum
You're leading a team, which can be assessed as a set of quantities at any given point in time (viz. velocity in Pivotal Tracker for instance).
The team however is a dynamic interplay of business expectations (from the principal, boss, client) technical debt (recurring known issues), and the team strength (which waxes and wanes based on moral, environment, etc).
Always look for ways to make the lives of the engineers around you easier.
-) build tooling
yeoman generators
build tools
etc.
enriching internal tooling makes each engineer more effective, which means it has a compound effect.
You can cover a lot of ground just focusing on addressing pain points in your team.
]) One last point actually, you're a leader so remember that means you're expected to have finer grain control over your ego, it helps if you take an objective view towards the technology that comprises your stack rather than a predominantly fanatical view.
Congratulations by the way!
Regards,
Dante Elrik