Convincing management to redo work that's already been done

Question

My agency has been developing an application that they're hoping will bring in a lot of revenue and they're going about it the wrong way. The agency usually only deals with wordpress and drupal type sites. Our typical client approaches us for 3-6 months of work on a custom theme and then follows up after that with maintenance work.

At the beginning of last year the agency took on a whole new type of client that wanted a web app built, both for desktop and a mobile version for phone. I was hired as a team lead because of my experience with React, React Native, and Node. This job scope is still pretty new to me. So for the past 18 months that web app has kind of been my teams life and we've been sequestered off from other projects.

At the end of last year the other teams started working on a new web app, however, as their main experience is in wordpress, they have attempted to build the entire thing in wordpress. My project is winding down and they've started noticing that the app we built acts much more like an actual app than a website and they want me to apply that to their project. The thing is, for the scale they want this applied to, the project should have never started in wordpress. They're trying to contort a CMS into something it's not. At the very least the only way react is going to play nice with their back end is to change the entire thing into a headless api.

This leaves me with telling them that the months of work they've put into the project were kind of a waste of time as they used the wrong tools from the outset. It's not that they didn't use react but that they didn't use any framework. Almost all of their front end manipulation is done by very hap hazard jQuery. The other issue is that they want to apply some very heavy data analysis to the back end and wordpress was never meant to do things like that so it's causing a massive slow down of the whole thing.

The person who would make the final decision on this has a very profit focused mind though (as a business owner should) and will really focus on 'time to market'. The idea of me saying the concept is great but the whole thing needs to be refurbished will immediately cause him second thoughts on anything I say after that. More so, as many of the original team members are unfamiliar with react, angular, or any other framework it puts them at an immediate loss. I can definitely understand the strength of building in what you know vs learning something new.

For example last week while discussing an npm package we'd used for the mobile version of our previous app the other team noticed we'd solved a big problem they were having and asked us to implement it for them. After looking at their code that's when I realized there was no way to use this npm module without setting up webpack or browserify in the project and they weren't about that at all. After 3 days we were able to write a vanilla js script that did what they needed but I have a feeling this uphill battle is what we'd be in for the entire time.

What is the best way to present all of this to them. I don't want to just say straight up "no we won't work on this as it is" but I also don't want my team taking ownership of the front end of the project only to take blame a few weeks or months from now when it can't perform as they want. Basically I feel like this is going to set us up to fail monumentally.

Answer 1

Build a consensus amongst the technical team. Take what you've written here and bring it to the lead dev of the other team and see what they say. Preface it with "We can do it, but I have some reservations" and lay out your concerns.

If you get the other person to agree with you, you both bring it to the boss presenting a united front. For business decisions, you need to lay out time estimates and costs associated with either course - the one that brings the most financial benefits will usually be chosen by a rational actor.

On a business level it doesn't matter how pretty it is so long as it works sufficiently well that enough people are willing to pay for it to make a profit, and everything else is subordinate to that.

After that, you see what the boss says. If they agree, good. If they don't you do your best. At the end of the day it's not your company, all you need to care about is getting paid.

Answer 2

You don't get involved with another teams project over which you have no control in terms of enforcing what is used and how.

If they request something, you refer them to decision makers who can then ask you if they want. If they do then this is the point at which you treat it as your teams project and let them know what would be required, timeframes etc,.

Ideally you wouldn't touch it unless it becomes your responsibility along with the authority to do it your way.

Answer 3

If the company culture allows it, I would have an open chat with the decision maker and, without slandering the other team, explain that you reviewed the requirements, and to apply your better performing solution the most efficient way is to recreate the other project from scratch. Nobody wants infighting or to make another team feel like crap, and the other team lead would probably get defensive, as he should, because of the original, suboptimal choice. So: talk to the decision maker, and let him make the decision. But make it clear that you don't want to cause a rift in the relationships with the other team. This is a massive exercise in politics, but you seem to have the right sensibility to make it.

Answer 4

Another possible outcome is that the manager decides the feature isn't important after all, or not important enough to rewrite what they have. You mention it will require great expense, but not how much it will help out.