Convincing management to redo work that's already been done
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty{ margin-bottom:0;
}
up vote
1
down vote
favorite
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.
team project-management meetings time-management
New contributor
add a comment |
up vote
1
down vote
favorite
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.
team project-management meetings time-management
New contributor
Welcome new user! I would urge you to click "Edit" and drastically shorten your question.
– Fattie
Nov 26 at 3:31
It's sounds like a non-issue, Brian. It's totally commonplace, the norm, that opinions differ vastly on the basic paradigm of how to do some web site or app. It's a non-issue. It's like saying "I'm a programmer, today i wrote some code." Just speak up freely and openly at any moment "Oh I happen to think this should be done with XYZ." It's worth noting by the way that a great many architects totally dismiss React/ecosystem as a total waste of time and money. Opinions mean little or nothing in software, everyone has one.
– Fattie
Nov 26 at 3:35
"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" - and how will he think of you, if you don't speak up & the whole thing ends in tears?
– Mawg
Nov 26 at 10:10
Sometimes you get halfway up the mountain, look around, and see that you are climbing the wrong mountain
– Mawg
2 days ago
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
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.
team project-management meetings time-management
New contributor
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.
team project-management meetings time-management
team project-management meetings time-management
New contributor
New contributor
edited Nov 25 at 17:29
New contributor
asked Nov 25 at 17:13
Brian
122
122
New contributor
New contributor
Welcome new user! I would urge you to click "Edit" and drastically shorten your question.
– Fattie
Nov 26 at 3:31
It's sounds like a non-issue, Brian. It's totally commonplace, the norm, that opinions differ vastly on the basic paradigm of how to do some web site or app. It's a non-issue. It's like saying "I'm a programmer, today i wrote some code." Just speak up freely and openly at any moment "Oh I happen to think this should be done with XYZ." It's worth noting by the way that a great many architects totally dismiss React/ecosystem as a total waste of time and money. Opinions mean little or nothing in software, everyone has one.
– Fattie
Nov 26 at 3:35
"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" - and how will he think of you, if you don't speak up & the whole thing ends in tears?
– Mawg
Nov 26 at 10:10
Sometimes you get halfway up the mountain, look around, and see that you are climbing the wrong mountain
– Mawg
2 days ago
add a comment |
Welcome new user! I would urge you to click "Edit" and drastically shorten your question.
– Fattie
Nov 26 at 3:31
It's sounds like a non-issue, Brian. It's totally commonplace, the norm, that opinions differ vastly on the basic paradigm of how to do some web site or app. It's a non-issue. It's like saying "I'm a programmer, today i wrote some code." Just speak up freely and openly at any moment "Oh I happen to think this should be done with XYZ." It's worth noting by the way that a great many architects totally dismiss React/ecosystem as a total waste of time and money. Opinions mean little or nothing in software, everyone has one.
– Fattie
Nov 26 at 3:35
"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" - and how will he think of you, if you don't speak up & the whole thing ends in tears?
– Mawg
Nov 26 at 10:10
Sometimes you get halfway up the mountain, look around, and see that you are climbing the wrong mountain
– Mawg
2 days ago
Welcome new user! I would urge you to click "Edit" and drastically shorten your question.
– Fattie
Nov 26 at 3:31
Welcome new user! I would urge you to click "Edit" and drastically shorten your question.
– Fattie
Nov 26 at 3:31
It's sounds like a non-issue, Brian. It's totally commonplace, the norm, that opinions differ vastly on the basic paradigm of how to do some web site or app. It's a non-issue. It's like saying "I'm a programmer, today i wrote some code." Just speak up freely and openly at any moment "Oh I happen to think this should be done with XYZ." It's worth noting by the way that a great many architects totally dismiss React/ecosystem as a total waste of time and money. Opinions mean little or nothing in software, everyone has one.
– Fattie
Nov 26 at 3:35
It's sounds like a non-issue, Brian. It's totally commonplace, the norm, that opinions differ vastly on the basic paradigm of how to do some web site or app. It's a non-issue. It's like saying "I'm a programmer, today i wrote some code." Just speak up freely and openly at any moment "Oh I happen to think this should be done with XYZ." It's worth noting by the way that a great many architects totally dismiss React/ecosystem as a total waste of time and money. Opinions mean little or nothing in software, everyone has one.
– Fattie
Nov 26 at 3:35
"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" - and how will he think of you, if you don't speak up & the whole thing ends in tears?
– Mawg
Nov 26 at 10:10
"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" - and how will he think of you, if you don't speak up & the whole thing ends in tears?
– Mawg
Nov 26 at 10:10
Sometimes you get halfway up the mountain, look around, and see that you are climbing the wrong mountain
– Mawg
2 days ago
Sometimes you get halfway up the mountain, look around, and see that you are climbing the wrong mountain
– Mawg
2 days ago
add a comment |
4 Answers
4
active
oldest
votes
up vote
6
down vote
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.
the thing I'd be wary of with this is the other lead is almost certainly going to disagree with changing anything, leaving us hobbling right from the get go. Is there a way to set accountability up so that we aren't taking blame for 'concerns' we warned them about but they opted not to listen to?
– Brian
Nov 25 at 17:37
@Brian the way to avoid the accountability is to lay out all of your concerns and have them documented via email. If and when it falls apart you wave that at them and say "I told you so". Any face to face meetings where no records are taken, you write it up in an email and send it to all parties involved.
– user1666620
Nov 25 at 17:38
1
The "what's in it for me" can complement this approach. This can also be useful when we talk about refactoring to business as he may ask "we spent this amount of money to do this and now you are saying we have to redo everything ?"
– Answers_Seeker
Nov 26 at 8:11
add a comment |
up vote
3
down vote
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.
add a comment |
up vote
0
down vote
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.
add a comment |
up vote
0
down vote
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.
New contributor
add a comment |
StackExchange.ready(function () {
$("#show-editor-button input, #show-editor-button button").click(function () {
var showEditor = function() {
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
};
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True') {
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup({
url: '/post/self-answer-popup',
loaded: function(popup) {
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
}
})
} else{
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true) {
showEditor();
}
}
});
});
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
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.
the thing I'd be wary of with this is the other lead is almost certainly going to disagree with changing anything, leaving us hobbling right from the get go. Is there a way to set accountability up so that we aren't taking blame for 'concerns' we warned them about but they opted not to listen to?
– Brian
Nov 25 at 17:37
@Brian the way to avoid the accountability is to lay out all of your concerns and have them documented via email. If and when it falls apart you wave that at them and say "I told you so". Any face to face meetings where no records are taken, you write it up in an email and send it to all parties involved.
– user1666620
Nov 25 at 17:38
1
The "what's in it for me" can complement this approach. This can also be useful when we talk about refactoring to business as he may ask "we spent this amount of money to do this and now you are saying we have to redo everything ?"
– Answers_Seeker
Nov 26 at 8:11
add a comment |
up vote
6
down vote
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.
the thing I'd be wary of with this is the other lead is almost certainly going to disagree with changing anything, leaving us hobbling right from the get go. Is there a way to set accountability up so that we aren't taking blame for 'concerns' we warned them about but they opted not to listen to?
– Brian
Nov 25 at 17:37
@Brian the way to avoid the accountability is to lay out all of your concerns and have them documented via email. If and when it falls apart you wave that at them and say "I told you so". Any face to face meetings where no records are taken, you write it up in an email and send it to all parties involved.
– user1666620
Nov 25 at 17:38
1
The "what's in it for me" can complement this approach. This can also be useful when we talk about refactoring to business as he may ask "we spent this amount of money to do this and now you are saying we have to redo everything ?"
– Answers_Seeker
Nov 26 at 8:11
add a comment |
up vote
6
down vote
up vote
6
down vote
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.
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.
edited Nov 25 at 22:51
answered Nov 25 at 17:25
user1666620
8,49473229
8,49473229
the thing I'd be wary of with this is the other lead is almost certainly going to disagree with changing anything, leaving us hobbling right from the get go. Is there a way to set accountability up so that we aren't taking blame for 'concerns' we warned them about but they opted not to listen to?
– Brian
Nov 25 at 17:37
@Brian the way to avoid the accountability is to lay out all of your concerns and have them documented via email. If and when it falls apart you wave that at them and say "I told you so". Any face to face meetings where no records are taken, you write it up in an email and send it to all parties involved.
– user1666620
Nov 25 at 17:38
1
The "what's in it for me" can complement this approach. This can also be useful when we talk about refactoring to business as he may ask "we spent this amount of money to do this and now you are saying we have to redo everything ?"
– Answers_Seeker
Nov 26 at 8:11
add a comment |
the thing I'd be wary of with this is the other lead is almost certainly going to disagree with changing anything, leaving us hobbling right from the get go. Is there a way to set accountability up so that we aren't taking blame for 'concerns' we warned them about but they opted not to listen to?
– Brian
Nov 25 at 17:37
@Brian the way to avoid the accountability is to lay out all of your concerns and have them documented via email. If and when it falls apart you wave that at them and say "I told you so". Any face to face meetings where no records are taken, you write it up in an email and send it to all parties involved.
– user1666620
Nov 25 at 17:38
1
The "what's in it for me" can complement this approach. This can also be useful when we talk about refactoring to business as he may ask "we spent this amount of money to do this and now you are saying we have to redo everything ?"
– Answers_Seeker
Nov 26 at 8:11
the thing I'd be wary of with this is the other lead is almost certainly going to disagree with changing anything, leaving us hobbling right from the get go. Is there a way to set accountability up so that we aren't taking blame for 'concerns' we warned them about but they opted not to listen to?
– Brian
Nov 25 at 17:37
the thing I'd be wary of with this is the other lead is almost certainly going to disagree with changing anything, leaving us hobbling right from the get go. Is there a way to set accountability up so that we aren't taking blame for 'concerns' we warned them about but they opted not to listen to?
– Brian
Nov 25 at 17:37
@Brian the way to avoid the accountability is to lay out all of your concerns and have them documented via email. If and when it falls apart you wave that at them and say "I told you so". Any face to face meetings where no records are taken, you write it up in an email and send it to all parties involved.
– user1666620
Nov 25 at 17:38
@Brian the way to avoid the accountability is to lay out all of your concerns and have them documented via email. If and when it falls apart you wave that at them and say "I told you so". Any face to face meetings where no records are taken, you write it up in an email and send it to all parties involved.
– user1666620
Nov 25 at 17:38
1
1
The "what's in it for me" can complement this approach. This can also be useful when we talk about refactoring to business as he may ask "we spent this amount of money to do this and now you are saying we have to redo everything ?"
– Answers_Seeker
Nov 26 at 8:11
The "what's in it for me" can complement this approach. This can also be useful when we talk about refactoring to business as he may ask "we spent this amount of money to do this and now you are saying we have to redo everything ?"
– Answers_Seeker
Nov 26 at 8:11
add a comment |
up vote
3
down vote
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.
add a comment |
up vote
3
down vote
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.
add a comment |
up vote
3
down vote
up vote
3
down vote
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.
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.
answered Nov 25 at 17:35
Kilisi
109k61242422
109k61242422
add a comment |
add a comment |
up vote
0
down vote
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.
add a comment |
up vote
0
down vote
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.
add a comment |
up vote
0
down vote
up vote
0
down vote
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.
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.
answered Nov 25 at 22:30
Monoandale
2,98241851
2,98241851
add a comment |
add a comment |
up vote
0
down vote
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.
New contributor
add a comment |
up vote
0
down vote
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.
New contributor
add a comment |
up vote
0
down vote
up vote
0
down vote
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.
New contributor
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.
New contributor
New contributor
answered Nov 26 at 1:06
Nate 8
1124
1124
New contributor
New contributor
add a comment |
add a comment |
Brian is a new contributor. Be nice, and check out our Code of Conduct.
Brian is a new contributor. Be nice, and check out our Code of Conduct.
Brian is a new contributor. Be nice, and check out our Code of Conduct.
Brian is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to The Workplace Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f123398%2fconvincing-management-to-redo-work-thats-already-been-done%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Welcome new user! I would urge you to click "Edit" and drastically shorten your question.
– Fattie
Nov 26 at 3:31
It's sounds like a non-issue, Brian. It's totally commonplace, the norm, that opinions differ vastly on the basic paradigm of how to do some web site or app. It's a non-issue. It's like saying "I'm a programmer, today i wrote some code." Just speak up freely and openly at any moment "Oh I happen to think this should be done with XYZ." It's worth noting by the way that a great many architects totally dismiss React/ecosystem as a total waste of time and money. Opinions mean little or nothing in software, everyone has one.
– Fattie
Nov 26 at 3:35
"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" - and how will he think of you, if you don't speak up & the whole thing ends in tears?
– Mawg
Nov 26 at 10:10
Sometimes you get halfway up the mountain, look around, and see that you are climbing the wrong mountain
– Mawg
2 days ago