My experience as Unity3d team lead

Delegate
First thing that you need to do is to delegate your responsibilities to someone else. There are plenty of people who might need some help from you: VFX artists, tech artists, level designers, quest designers, project manager, producer, other developers. The question can vary from something common about Unity3D Editor and working with GIT to something that you are not quite familiar with, especially if you started to work over the project after a few years of development. So you need to treat your time with care. You can pick one person from your team who can help with VFX and tech art, one who will take care of the level and quest designers, another one who will take care of GIT, etc. You need to delegate to keep the structure working and to have time for more important things. Otherwise you will simply burn out and leave the company in a few months.

Share experience
Most of the time the team lead is the person who is the strongest developer in the team. It's very rare that a team lead is a mediocre developer with managing abilities. Because great developers are always in the spotlight for managers or producers. And they often take the promotion even if they don’t have required skills or don’t want to, but the meaning of promotion is so tempting.

I had a lot of times when the producer said that he wanted me to implement certain features despite having other developers in the team. And I think that it's something we should avoid, because irreplaceable people are bad for any structures. Also great teams are functioning mostly on trust and equality. You need to raise your teammates to at least your level so you can delegate more effectively. 

Also don’t forget to share some “special knowledge”, how to release, how to update some stuff, etc. So when you get sick, someone will take the lead for you and release the product, take care of blocker bugs, do the right architecture for new features...

Plan together
Use a planning poker. It’s quite a simple tool and quite effective. First, you need to buy a planning poker cards. Then you sit with your crew and everyone has this set of cards with numbers on them. When the team needs to provide estimates, they flash cards with numbers on them and you conduct a discussion until everybody agrees on estimates and flashing same value cards. Because there is often such a situation when one of the team mates knows about some of the pitfalls and he will have the ability to share it.

You can plan in hours or in abstract numbers. It doesn't matter. Until you use a fibonacci number: 1, 2, 3, 5, 8, 13, 21, 34, etc. And round it to a bigger number. For example, you need to implement something that will take two days, that’s 16 hours, but as you can see there is no such estimate in sequence, so you use next bigger, it’s 21 hours. The bigger the estimate, the bigger the buffer for mistakes. Which is pretty cool, because a lot of developers are optimistic about their estimations.
I believe that the person who provides estimates is responsible for making things on time. If you estimate alone then you can’t ask your developers why it takes so long and apply any sanctions to them in any way. 

1 on 1
Here you will need to define points of interest for the developer and for the company and make them cross. And your role here is more like a mentor, that means that you are not telling what to do, you are asking the questions so the person will be more motivated because it was their decisions and thoughts. It’s one the most powerful tools that you can use to grow your team.

Conflicts solving
Good team is acting as one entity. Even in such minor (at the first glance!) events like going to team building at some pub, you should make sure that everyone is happy with chosen location, beverages, meals, etc. It’s not an acceptable situation when someone is not taken into consideration.

1% improvement
When you become lead developer it’s always tempting to do things completely different. And often brand new lead is a bit arrogant and because of it falling into effect of Dunning-Kruger. They basically overestimate their abilities and do a lot of harm to the team and product. Also a lot of developers are pretty conservative and often freshly hired lead didn’t gain enough trust to do something radical.

Help business
Any business is working with one particular goal: to make some money. And your salary often depends on how successful the company is. So you need to take care of business as well, because we are all in the same boat. 

So when making a new feature and you see how you can implement 80% of it for 20% of time don’t hesitate to discuss a shortcut with people who are interested in this feature. Because often it’s enough to test theory and understand if there is any necessity to implement the feature without all that fancy nitty-gritty details.

And I know that a developer is launching his game thousands of times per day. But don’t forget to actually take a time and play the game. Don’t use any cheats, just play as it regular player will.

Also spend some time researching the business. Read the news about industry. Get closer with players. It will help not only business but you as well.