• I work for a large corporate providing HW/SW that often lacks alignment between sites across the world.

  • In the past three years I was fortunate enough to be allocated to a corporate project where we managed to get good R&D software results for a specific AI-based function with a small but fierce team. We are close to productizing our research outcome in a closed-source SW library.

  • In the extended corporate environment there are teams we communicate our results to; one of these teams in another continent has repeatedly asked for access to our assets, including data and code. They admittedly work on the same function with a lag of 1 year (estimated) and a slightly higher head count. We have regular syncs in which we share reciprocal advancements but we always show more than we receive, and feel we are looking at a snapshot of discussions we had a year ago.

  • This project is rather important for my career; our budget is also not going to improve considering the tech situation. The competing team is close to a potential client but seems to be wanting to favor “their stuff first” even with our close to production results.

  • Is there any management level strategy or argument that could be adopted to persuade the competing team to use our product (closed source) instead of wasting time to develop a likely identical solution with 1+ Years of delay?

  • 1
    This is VTC - as you are asking multiple questions - so if you can focus it down to a specific question - we can answer. Commented Feb 6, 2023 at 23:33
  • Tried to narrow down the question, let me know if insufficient
    – Eventide00
    Commented Feb 7, 2023 at 7:24

3 Answers 3


The reason I was a bit quick on the VTC - was because you've described something I'm rather familiar - big multi-national company with multiple competing silos all of whom have re-invented the wheel several times.

Firstly - consider this - the reasons why you want them to use your in-house developed product may be the exact same reasons why they want to use their in-house product

That is to say, without an external user, their team will have questions asked of them and whether or not their continued employment at the company has any value.

With that in mind, we re-frame the requirement - not 'How do I get them to use my stuff', but 'Why would they want to use my product?'

If the main requirement for them to continue to develop their product is work for the sake of work, then you are probably going to have a hard time to convince anyone to switch - unless you run it far enough up the Flagpole that a mandate from up high comes down - but that is a high risk strategy.

But let's assume that this isn't the case.

You say you sync and share regular updates - have you actually demoed a finished product to them yet? Or at least an MVP release? If not, that would be my first recommendation - show the Managers what you have and how it's working.

Next, depending on what you use to track progress - what you could do is look at their ticket/task/job queue and find a number of tickets that they have recently logged that and find the similar/corresponding ticket that you logged and solved a year ago - and then present that to Management to prove that there is double handling going on.

The angle I would take is along the lines of suggesting a collaboration - that the end-product has slight differences and but that your team can help the other team with bringing them up-to-speed and your team could help with the extra Horsepower.


Reading through a few times, I was not able to clearly ascertain if you had official funding for your research or whether you did it in a more stealth way, under the funding of some other project, hoping to perform a massive present in the future and reap large rewards?

This second team, do they have official funding and official release dates scheduled? The other team may be after the same "important to my career" trophy, so may never want to publicly take yours.

So it comes down to who officially is funded for this research and who is officially tasked to produce the product. If it is not you, you cannot convince the second team of anything. You will be expected to help and that is it.

Escalating upwards may be your only recourse.

  • Thanks, I don't directly see what suggests "stealth" in my post, I can assure you there was literally none. We shared monthly our status towards other teams. The difference in status is, our project has tentative releases (and one core library it is released as part of), theirs does not, but they are placed closer to client and could go about it on their own, just with more delays. I agree and hear that escalating upwards is the only option, and I will, thanks.
    – Eventide00
    Commented Feb 7, 2023 at 7:26
  • Perhaps stealth was the wrong word. Generally a project which has official funding, from my exp, has reports going to executive level. I have never seen a project with official funding that executive team knows about, not being reported to them, but instead reporting to another team doing the same thing, except time dilated. It is this that had me question if the other team has official support whilst your team does not? If your product is better, a year ahead, ready for release and officially funded, it should be an easy thing to have yours take the lead. If not, something strange.
    – Chris
    Commented Feb 7, 2023 at 14:59
  • The thing is we operate on a big-enough company to have different reporting chains, and even if the teams have similar mandates, we would have to go several layers up, up to very high management that propagates orders to two different entities. Moreover, the money does not exactly come from the same place. It is the same org but my division gets money from one source, while theirs ... I haven't fully understood where they get money from but it's not the same source.
    – Eventide00
    Commented Feb 8, 2023 at 8:34
  • 1
    I get you on where the money comes from situation. Generally though, when you are talking about a product getting released to the world, very high management is in the loop and generally, my experience is that there is generally one technical leader who runs the show architecturally. If the upper echelons know that there are two teams running the same game, well then this is strange to me. Seems more probably that they do not know about the two teams situation. If the 'second team' is reporting to upper echelons and you are not, they may be pulling a fast one on you.
    – Chris
    Commented Feb 8, 2023 at 16:16

Welcome to the realities of large-company development. It could easily be worse; your competitor might have released, and patented, your new functionality...

Duplicated effort comes from incomplete communication, and company confidentiality often limits communication.

Once duplication exists, it's common for people to prefer the version they are most familiar with. This mindset is often described as NIH, Not Invented Here.

In the short term, unless you can find a manager whose tree includes both groups and is willing to tell people that they must collaborate, there isn't much you can do about it.

In the longer term, consider this an internal competitor; you need to be able to show that your solution does everything the other one does and more, is cleaner or more performant or better supported/documented or has other clear advantages, and can easily be retrofit into code originally written against the other version. And even that may not be a convincing enough argument for existing code; your best hope is to become the preferred platform for future projects. Again assuming that there isn't something else competing for attention by then.

This is inherent in having a large enough company that you don't know in detail what every other employee is working on. Yeah, it's frustrating. But all you can really do is accept that this happens and take pride in doing your best work whether someone else picks it up or not, and trust that your own management recognizes the value of your work even if the other manager doesn't.

Not all work makes it to product status, no matter how good it is. That's just life.

  • 1
    So basically, just hard work and no certainty on the outcome :) that is indeed just life :)
    – Eventide00
    Commented Feb 7, 2023 at 7:28
  • 1
    I've had another team ask us to implement something, and then turn around and say "Yeah, that's about how we plan to do it; I just wanted to check that we weren't missing anything." Yeah, I felt like they'd been wasting my time and that if all they wanted was to discuss approaches we could have done that at much less cost to the company... but there wasn't much I could do about it at that point except hint that my own manager might want to complain to his manager about it and hope that a correction came back down the other side of the management chain.
    – keshlam
    Commented Feb 9, 2023 at 16:14

You must log in to answer this question.

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