Well firstly, congratulations! This is a fun and interesting opportunity to grow as a human being. You will make mistakes and learn a ton. Your most important job is to be an enabler/force multiplier supporting the success of the team.
1) Make sure the team fully understand the goal and are directing their efforts at the simplest possible way to achieve the objective. Engineers are famous for spending time on bikeshed arguments that don't matter and making heroic efforts to do interesting wrong things rather than boring things which lead to success.
2) Related to the above, but try to ensure that people are pointed at tasks which enable them to grow while still leading to team success overall. This is an incredibly interesting optimisation problem that will occupy your mind and hone your judgement.
3) Act with absolute integrity. Don't succumb to the temptation to weasel out of tough situations. If you've made a mistake, own up to it. If something is hard, say it's hard, but don't use that as an excuse to not take the important decisions you need to take. You got the title now you need to do the job.
4) Your poor verbal skills are going to be present some challenges but here's some specific tips
- always start with a verbal conversation whenever you can (even if doing so makes your skin crawl) and immediately follow up by email setting out specifics and allowing them to comment. This prevents all kinds of misunderstandings and ensures you are in complete sync. The harder the conversation, the more important you do it face to face first
- Learn some patterns which help to ensure people don't misunderstand key conversations.
- Start with the important part and state it as plainly as possible.
- Don't attribute intentions, but talk about impact. Say "When you do x, the effect on the team is y and that's bad because z", not "you're always x, I think that's because a b c".
- Be as specific as possible about what your expectations are and what people need to do to fix things. eg "I need to see x by Friday and if that doesn't happen, the consequences will be y".
- If you're giving someone a verbal warning or other feedback that could lead to changes to comp, affect future promotion or lead to dismissal _make sure the person can not possibly be in any doubt as to the gravity of the situation_ even if it seems heavy-handed. I have started conversations with "thanks for coming. We need to talk about something that will affect your future at Yoyodyne Inc." and follow up with an email ccing HR.
5)Following on from that, don't surprise people. They should always know whether they are doing well, poorly, what they need to do more, less of, what your expectations are etc. Don't assume they know. I always assume people can read my mind and they really cant.
6)Think strategically about your team and how they can be even better than they are: more/less/different people, more/different support and interaction with other teams, fewer meetings wasting time/more investment in getting in sync preventing time wasted doing the wrong things.
7)Think strategically about your people: What they like/hate doing, what they are good/poor at, where their blindspots are, what the right next step should be for them. Getting good at this will make you into a superhuman zen master of a manager.
8)Read "Managing Humans". It's fun and you'll find it helpful, and I consider Rands (Michael Lopp) to be a friend so you'll be giving him a small royalty.
9)Get really good at interviewing and learn from your hiring mistakes. You're looking for people who add to your team which means not everyone is going to have the same strengths and weaknesses. Try to think about where the gaps are and what the missing jigsaw pieces look like. Recruiters will try to influence you to hire someone who looks exactly like the last person they placed with you. That leads over time to a team who all do and think exactly the same.
The fact that you understand the job of a developer is great. Try to avoid the easy temptation to play up "us vs them" ("team" vs "management" or "product" vs "sales" or whatever) and instead help your team to see how their work fits into the broader mission and how the work of non-technical colleagues (eg salespeople) is important too.
Finally: Having stuff in common with your team is completely unnecessary and often unhelpful, leading to groupthink and bro-management nonsense in the worst case. As you grow your team it should become less and less of a uniculture over time anyway. I make it a rule to seldom if ever socialise with my team- their downtime/drinks/whatever can be spent moaning about me and blowing off steam if they want. I'm not trying to be people's friend- this can be very uncomfortable and as the power dynamic widens can lead to lots of very difficult situations that are best avoided entirely.