It's an awkward position to be in. It will require that you perform at your absolute best and that you exercise a very high level of people skills. This is a great opportunity for you personally to show that you are competent and capable.
As such it is in your personal best interests to do a great job of this. You will most likely gain a lot of soft skills and you will have a chance to shine in front of 3 different companies.
It is best to approach such a project from the perspective of they are your team (so you would give them the same level of support you would give a team of people from your own company) and we all work for Client A and to try to ignore the fact that you work for different companies. Remember the last thing that Client A wants is for this to turn into some sort of company competition to prove who is best. No one looks good when that happens.
The first thing you and your new team need to understand is that it is in the best interests of both of your companies to get along. Hostility makes it more likely the client will throw both away and go for a third company.
You will need to get to know not only the people involved, but the processes they typically use as their corporate culture is likely to be much different than yours. They may use different software for source control, different project management tools, etc. Their team may be located in a different geographical area and even if you are used to dealing with people in your own company from say India, if they use developers from Russia, that is a new country work culture to learn about. Since the majority of the team is from the other company, as much as possible use their systems and adjust to their culture. You may need to coordinate with their IT group to get access to what you need especially concerning code.
One thing you need to do, and make sure happens publicly, is to show that you will listen their input and support them up the chain of command to the client when they are right. You will have far less hostility, if you find something to praise about them to the client. You will find it easier to get them to make changes based on your input if you have listened to them. Save your changes from how they want to do things for the really important items. Build credibility with them first.
You probably will want to work with their manager and your manager before starting to work with the team to set out the ground rules of who is responsible for what. If there is a senior person on their team that you can work through, that might be most effective.
If you find there are quality problems with the way the code is being written, you will need to be able to clearly express what the problem is, detail what exactly needs to change and then insist they make the change. They will not get better if you fix all their bad work. You might even find yourself needing to do some formal training to get them up to speed on how things should be done.
Clear expectations of the way you want things done before coding starts will help. Once you have defined the design and made sure they all know how to do the work, then you have some basis for throwing it back if they don't follow through. And of course praise in public and criticize in private is of even greater necessity here.
Since you are technical lead to make sure your design is followed, you will definitely need to be involved in code review. In particular, you need to review the first code from every member of the team because you are not familiar with their personal capabilities. The sooner you can identify any weak areas and help shore them up the better.
If you discover that the team is very good, you may be able to later delegate some (but never all) of the code review. If you discover significant weaknesses, you need to code review everything and make sure nothing goes to production until it passes the code review.
I don't know how ,or even if, you do code review, but in this situation, I find it is best if you do the review where the person who wrote the code explains it to in a meeting and you directly ask questions and go back and forth until a consensus is reached. This will appear take longer at first than using some automated code review tool.
In the long run, the in-person discussions are the most valuable part of this and the way that you get people to understand what is going to be acceptable and what is not and that you have reasons for why you want things to change. This may be thought of as a training session as well if the code is not very good. But try to find something to praise when doing code reviews especially if you need to ask for a major change. You are not the direct supervisor of these people, you have to be able to deal with them cooperatively and that takes tact and finding things to praise helps that tremendously.
Most importantly, do not wait until the project is finished to do code reviews. You want to review some of their code as early as possible to ensure the direction is correct. Do not wait until things have gone to QA or UAT testing. Code review can be done after they have written any code even if it is not fully complete for that feature yet.
The sooner you find them going in the wrong direction, the easier it is to fix. This is especially true when the team works for a different company (or different part of your company). The closer to the deadline and the closer to what they consider complete, the more resistance to any major change is going to get. Reviewing the initial, incomplete code doesn't have to be as formal as a final code review for acceptance. You can ask them about parts they haven't gotten to yet and what they plan to do and then express how you want those parts done. It's best if you can do this one on one with only you and the developer, but political considerations may mean you need to also invite someone in a lead role from the other company.
