Duplicate project activities in corporate R&D

Question

• 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?

Answer 1

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.

Answer 2

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.

Answer 3

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.