Here is the scenario: I am working on a large project for a client. Being a large project, we are a team of people from more than one organisations. The manager here is from Client company who is managing all of us from different organisations. Recently, there was a new proposal to add a new feature for this project. The manager worked with me to get technical design ready and we had a discussion on planning/process to get this new feature work started. (I guess he would have discussed this with other team members from other organisation too).

After that The manager reached out to two organisations (mine and another from where we have people working on existing project) to get new hires to build the new feature. The other organisation won the bid and new team is being created with people from that org for the new work.

At this time I felt very bad that my organisation did not get the work even though The manager took my help to come up with the strategy.

After this he called a kick off meeting, and asked me to lead the technical part of the project and make sure the new feature being build is technically good.

Now, I am very confused. I don't feel like giving my 100% to this. I am only one from my organisation on this project. I am not able to concentrate on it. How should I go about it? Am I wrong in my feeling?

  • When you say more than one organization, do you mean different groups within the same company or different companies?
    – cdkMoose
    Oct 6, 2016 at 16:38
  • @cdkMoose I mean different companies working for one client..
    – mehta
    Oct 6, 2016 at 16:39

4 Answers 4


First off, yes it is less than ideal that your company lost the bid. However, you are still there, which means that you are valued in this team. Your contribution has been recognised. This is a personal win and is great for your professional reputation.

Unless there is open hostility between the two companies, you should absolutley give 100% to this. It will show just how professional you are. Remember, this is purely business, nothing personal. This team is now made up of colleagues, not competitors.

In addition, once the project is complete, you will have a number of new additions to your professional network. Nepotism is alive and well throughout the world, so make the most of it.


When you are being paid to do a job, you do the absolute best you can at that job.

If you feel that the combined relationship between the client and the multiple companies is not advantageous for your company, then speak to your management about whether or not your company needs/wants the work given the situation.

Until that is decided and/or changed, you do the best job you can for your client.


Certainly a cross-organizational project like this is always more challenging - but in some industries, it's a standard practice. I did quite a bit of this when I worked in small-scale government defense contracts.

Here's some thoughts to cope with the situation:

1 - Talk to your supervisor in your actual company.

Not the Client company manager for this project -- the person who oversees your work or arranges contracts on your behalf in the same company that signs your paychecks. What does that person see as your role? What does doing a good job mean to him/her? Are there company interests that you should be protective of? How does this person see the recent bid process where your company lost out to another company?

Get a sense of your company's perspective before you draw your own conclusions. In situations like this, there's usually a lot of politics to be aware of.

2 - Separate the business from the technology

Usually in a situation where you are working under contract cross-business on a technical solution, you have to separate the competitive nature of the business from the work to implement the technology in order to successfully collaborate with people from competitor companies. In a bid cycle, be competitive... when the bids are accepted and decided, be collaborative. Generally, the folks from your competitive company are also decent and skilled people who are paid to get the job done. Until you learn otherwise, start with giving them the benefit of the doubt that you'd give any new hire in your own company.

3 - Keep the communication clean

When you're working cross-company, make sure that everyone is very clear on the work, the deadlines and who owns what. Schedules, requirements and issues should be clearly documented in a trackable way and written down in a way that is is accessible to everyone - both in the original mission and any change that are made as time progresses. Preferably with timestamps that are beyond everyone's control.

In a good team, all the clear communication is just a very nice benefit that helps everyone do good work and maintain trust and accountability. In a team with disincentives to collaborate, and/or people with inadequate skills - it serves as a very good way to make sure that YOU are not the one holding the blame for other people's mistakes and it often can even eliminate parts of the blame game, because it's very, very clear who should be accountable for what.

This goes double for your relationship with the customer... the customer side should always be aware of who's doing what, and when it will be done. And when there are problems, they should know what they are, and what actions are being taken on the part of all participants. This takes a lot of time, but it's well worth it.

4 - Know your limits

To be sure, this approach takes a particular kind of mindset. If you have an internal definition of loyalty that is strongly tied to your company, and not to the project - this may not be a good business for you. There's other work out there, and maybe it is time to talk to both your company supervisor, and to folks who can give you other opportuntities.

I'd say you should feel at least a little bit flattered - the customer is showing a high degree of trust in you in asking you to be a technical lead when they've hired the rest of the staff from another company - it's usually easier to staff all the work with one company, so there must be a certain high degree of confidence in your work and your competence - at the very least, feel a bit flattered!


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .