Mixing
How to handle complaints and suggestion as a middle man?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
2
down vote
favorite
Right now I'm working in a multinational company, basically the company headquarter located in japan for sales and branch company is located in southeast asia for development. Right now I'm acting as middle manager to become a bridge between the sales team and the developer team to do my job well I must stayed as neutral as possible.
But as I expected there'll be always a complain from the branch office, and I have to handle all the complaints and I have to find for a solution either from their suggestion or from the headquarters staff. But recently the number of complain is increasing because I think the level of trust between the main office and the branch is decreasing, and they're become more sensitive recently and complaining about little things.
My question is how do you guys usually handle complaints and suggestion? just take them all plainly and report to the top for solution? or try to filter it? or try to answer it by yourself if you think you know the solution?
Thanks!
professionalism management communication complaint
asked Nov 13 '13 at 10:41
Niko Adrianus Yuwono
1134
add a comment |Â
up vote
2
down vote
favorite
Right now I'm working in a multinational company, basically the company headquarter located in japan for sales and branch company is located in southeast asia for development. Right now I'm acting as middle manager to become a bridge between the sales team and the developer team to do my job well I must stayed as neutral as possible.
But as I expected there'll be always a complain from the branch office, and I have to handle all the complaints and I have to find for a solution either from their suggestion or from the headquarters staff. But recently the number of complain is increasing because I think the level of trust between the main office and the branch is decreasing, and they're become more sensitive recently and complaining about little things.
My question is how do you guys usually handle complaints and suggestion? just take them all plainly and report to the top for solution? or try to filter it? or try to answer it by yourself if you think you know the solution?
Thanks!
professionalism management communication complaint
asked Nov 13 '13 at 10:41
Niko Adrianus Yuwono
1134
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Right now I'm working in a multinational company, basically the company headquarter located in japan for sales and branch company is located in southeast asia for development. Right now I'm acting as middle manager to become a bridge between the sales team and the developer team to do my job well I must stayed as neutral as possible.
But as I expected there'll be always a complain from the branch office, and I have to handle all the complaints and I have to find for a solution either from their suggestion or from the headquarters staff. But recently the number of complain is increasing because I think the level of trust between the main office and the branch is decreasing, and they're become more sensitive recently and complaining about little things.
My question is how do you guys usually handle complaints and suggestion? just take them all plainly and report to the top for solution? or try to filter it? or try to answer it by yourself if you think you know the solution?
Thanks!
professionalism management communication complaint
asked Nov 13 '13 at 10:41
Niko Adrianus Yuwono
1134
Right now I'm working in a multinational company, basically the company headquarter located in japan for sales and branch company is located in southeast asia for development. Right now I'm acting as middle manager to become a bridge between the sales team and the developer team to do my job well I must stayed as neutral as possible.
But as I expected there'll be always a complain from the branch office, and I have to handle all the complaints and I have to find for a solution either from their suggestion or from the headquarters staff. But recently the number of complain is increasing because I think the level of trust between the main office and the branch is decreasing, and they're become more sensitive recently and complaining about little things.
My question is how do you guys usually handle complaints and suggestion? just take them all plainly and report to the top for solution? or try to filter it? or try to answer it by yourself if you think you know the solution?
Thanks!
professionalism management communication complaint
asked Nov 13 '13 at 10:41
Niko Adrianus Yuwono
1134
asked Nov 13 '13 at 10:41
Niko Adrianus Yuwono
1134
asked Nov 13 '13 at 10:41
Niko Adrianus Yuwono
1134
asked Nov 13 '13 at 10:41
Niko Adrianus Yuwono
1134
1134
add a comment |Â
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
1
down vote
accepted
Very few employers really understand how long it take or what is involved in getting software to work. We are seeing a particularly public and embarrassing situation with 'healthcare.gov' and the people that legislated the project - this schedule was driven by election deadlines, not by project managers. Thus one can see the usual litany of developer complaints - vague specifications, insufficient resources, continually changing objectives, pressure to get stuff out, etc., etc. If you're working across national boundaries and 'home office' people have little respect for the 'foreigners', this can erupt into serious chaos. The best thing to do would be to have the senior people visit the location on a regular schedule, and talk directly to the people doing the work. If 'they can't afford it' then they can't afford the project at all.
A good way of understanding this is 'assume you've hired a contractor to remodel your kitchen'. Your initial guess is that it will take two weeks to redo the kitchen. You have the new sink, countertop, and cabinets selected, so this is just straight out, straight in, right?
At any rate, every thing is pulled out and then one discovers the plumbing and wiring has to be shifted around. Then it turns out that the color of the flooring and the cabinetry doesn't make sense. Then the fridge sticks out too far, and the sink isn't centered with respect to the window. In short, the homeowner is changing requirements in mid-stream. The project bloats to 6 weeks.
The homeowner has never remodeled a kitchen before, and they hired the lowest bidder. Now there's a fight. Someone has to explain to the homeowner that changing specs changes costs, and that certain elements of this were unforeseen. If the homeowner isn't listening and doesn't care, then the contractor quits, leaving the homeowner in the lurch. Software projects end up in situations like this all the time.
Thus one has to deal relatively firmly with the people that are making the plans and paying the bills. The first thing to do is set up very short 'deliverables' cycles so that some progress can be demonstrated every week or two. The next is to abandon any idea that there is a fixed time and fixed budget - the planners should determine at what point the project can no longer pay it's way, and pull the plug at that point. If the bid is for $1 million and the opportunity is $10 million, the client should be prepared to spend $2 to $3 million if they can still get the $10 million payback.
A point should be made to the home office - very few employers are successful at managing software projects, but those that are make a lot of money (insert names of huge Silicon Valley companies here). Therefore, it is really worth it to keep trying until they understand how it's done. The last thing they can afford to do is demand that the budgets and schedule remain constant if the objectives are fluid.
answered Nov 13 '13 at 12:45
Meredith Poor
8,8661730
I agree with you, your explanation match my current condition and your parable is very good! thanks man!
– Niko Adrianus Yuwono
Nov 14 '13 at 2:04
add a comment |Â
up vote
1
down vote
It is part of the definition of my work, so what we usually do is to forward them to the other party with comments on how we think it could/should be fixed. But of course ultimately it's up to the recipient to decide, since we are just in the middle.
But it sounds like they are expecting you to solve the issues? In that case just do the same, but participate more actively in the incident management by collaborating with the other party. If you are the responsible party, then you must follow it through in the end. In other cases, just do your best - especially when under heavy loads.
Perhaps you could have weekly/monthly meetings with the representatives of both teams, and go through the recent issues and work on a solution that works for both parties.
answered Nov 13 '13 at 11:47
Juha Untinen
1,5261018
Yes, sometimes both of the sides expecting me to give a neutral solution for the issue, thanks for the advice man!
– Niko Adrianus Yuwono
Nov 14 '13 at 2:05
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
Very few employers really understand how long it take or what is involved in getting software to work. We are seeing a particularly public and embarrassing situation with 'healthcare.gov' and the people that legislated the project - this schedule was driven by election deadlines, not by project managers. Thus one can see the usual litany of developer complaints - vague specifications, insufficient resources, continually changing objectives, pressure to get stuff out, etc., etc. If you're working across national boundaries and 'home office' people have little respect for the 'foreigners', this can erupt into serious chaos. The best thing to do would be to have the senior people visit the location on a regular schedule, and talk directly to the people doing the work. If 'they can't afford it' then they can't afford the project at all.
A good way of understanding this is 'assume you've hired a contractor to remodel your kitchen'. Your initial guess is that it will take two weeks to redo the kitchen. You have the new sink, countertop, and cabinets selected, so this is just straight out, straight in, right?
At any rate, every thing is pulled out and then one discovers the plumbing and wiring has to be shifted around. Then it turns out that the color of the flooring and the cabinetry doesn't make sense. Then the fridge sticks out too far, and the sink isn't centered with respect to the window. In short, the homeowner is changing requirements in mid-stream. The project bloats to 6 weeks.
The homeowner has never remodeled a kitchen before, and they hired the lowest bidder. Now there's a fight. Someone has to explain to the homeowner that changing specs changes costs, and that certain elements of this were unforeseen. If the homeowner isn't listening and doesn't care, then the contractor quits, leaving the homeowner in the lurch. Software projects end up in situations like this all the time.
Thus one has to deal relatively firmly with the people that are making the plans and paying the bills. The first thing to do is set up very short 'deliverables' cycles so that some progress can be demonstrated every week or two. The next is to abandon any idea that there is a fixed time and fixed budget - the planners should determine at what point the project can no longer pay it's way, and pull the plug at that point. If the bid is for $1 million and the opportunity is $10 million, the client should be prepared to spend $2 to $3 million if they can still get the $10 million payback.
A point should be made to the home office - very few employers are successful at managing software projects, but those that are make a lot of money (insert names of huge Silicon Valley companies here). Therefore, it is really worth it to keep trying until they understand how it's done. The last thing they can afford to do is demand that the budgets and schedule remain constant if the objectives are fluid.
answered Nov 13 '13 at 12:45
Meredith Poor
8,8661730
I agree with you, your explanation match my current condition and your parable is very good! thanks man!
– Niko Adrianus Yuwono
Nov 14 '13 at 2:04
add a comment |Â
up vote
1
down vote
accepted
Very few employers really understand how long it take or what is involved in getting software to work. We are seeing a particularly public and embarrassing situation with 'healthcare.gov' and the people that legislated the project - this schedule was driven by election deadlines, not by project managers. Thus one can see the usual litany of developer complaints - vague specifications, insufficient resources, continually changing objectives, pressure to get stuff out, etc., etc. If you're working across national boundaries and 'home office' people have little respect for the 'foreigners', this can erupt into serious chaos. The best thing to do would be to have the senior people visit the location on a regular schedule, and talk directly to the people doing the work. If 'they can't afford it' then they can't afford the project at all.
A good way of understanding this is 'assume you've hired a contractor to remodel your kitchen'. Your initial guess is that it will take two weeks to redo the kitchen. You have the new sink, countertop, and cabinets selected, so this is just straight out, straight in, right?
At any rate, every thing is pulled out and then one discovers the plumbing and wiring has to be shifted around. Then it turns out that the color of the flooring and the cabinetry doesn't make sense. Then the fridge sticks out too far, and the sink isn't centered with respect to the window. In short, the homeowner is changing requirements in mid-stream. The project bloats to 6 weeks.
The homeowner has never remodeled a kitchen before, and they hired the lowest bidder. Now there's a fight. Someone has to explain to the homeowner that changing specs changes costs, and that certain elements of this were unforeseen. If the homeowner isn't listening and doesn't care, then the contractor quits, leaving the homeowner in the lurch. Software projects end up in situations like this all the time.
Thus one has to deal relatively firmly with the people that are making the plans and paying the bills. The first thing to do is set up very short 'deliverables' cycles so that some progress can be demonstrated every week or two. The next is to abandon any idea that there is a fixed time and fixed budget - the planners should determine at what point the project can no longer pay it's way, and pull the plug at that point. If the bid is for $1 million and the opportunity is $10 million, the client should be prepared to spend $2 to $3 million if they can still get the $10 million payback.
A point should be made to the home office - very few employers are successful at managing software projects, but those that are make a lot of money (insert names of huge Silicon Valley companies here). Therefore, it is really worth it to keep trying until they understand how it's done. The last thing they can afford to do is demand that the budgets and schedule remain constant if the objectives are fluid.
answered Nov 13 '13 at 12:45
Meredith Poor
8,8661730
I agree with you, your explanation match my current condition and your parable is very good! thanks man!
– Niko Adrianus Yuwono
Nov 14 '13 at 2:04
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
Very few employers really understand how long it take or what is involved in getting software to work. We are seeing a particularly public and embarrassing situation with 'healthcare.gov' and the people that legislated the project - this schedule was driven by election deadlines, not by project managers. Thus one can see the usual litany of developer complaints - vague specifications, insufficient resources, continually changing objectives, pressure to get stuff out, etc., etc. If you're working across national boundaries and 'home office' people have little respect for the 'foreigners', this can erupt into serious chaos. The best thing to do would be to have the senior people visit the location on a regular schedule, and talk directly to the people doing the work. If 'they can't afford it' then they can't afford the project at all.
A good way of understanding this is 'assume you've hired a contractor to remodel your kitchen'. Your initial guess is that it will take two weeks to redo the kitchen. You have the new sink, countertop, and cabinets selected, so this is just straight out, straight in, right?
At any rate, every thing is pulled out and then one discovers the plumbing and wiring has to be shifted around. Then it turns out that the color of the flooring and the cabinetry doesn't make sense. Then the fridge sticks out too far, and the sink isn't centered with respect to the window. In short, the homeowner is changing requirements in mid-stream. The project bloats to 6 weeks.
The homeowner has never remodeled a kitchen before, and they hired the lowest bidder. Now there's a fight. Someone has to explain to the homeowner that changing specs changes costs, and that certain elements of this were unforeseen. If the homeowner isn't listening and doesn't care, then the contractor quits, leaving the homeowner in the lurch. Software projects end up in situations like this all the time.
Thus one has to deal relatively firmly with the people that are making the plans and paying the bills. The first thing to do is set up very short 'deliverables' cycles so that some progress can be demonstrated every week or two. The next is to abandon any idea that there is a fixed time and fixed budget - the planners should determine at what point the project can no longer pay it's way, and pull the plug at that point. If the bid is for $1 million and the opportunity is $10 million, the client should be prepared to spend $2 to $3 million if they can still get the $10 million payback.
A point should be made to the home office - very few employers are successful at managing software projects, but those that are make a lot of money (insert names of huge Silicon Valley companies here). Therefore, it is really worth it to keep trying until they understand how it's done. The last thing they can afford to do is demand that the budgets and schedule remain constant if the objectives are fluid.
answered Nov 13 '13 at 12:45
Meredith Poor
8,8661730
Very few employers really understand how long it take or what is involved in getting software to work. We are seeing a particularly public and embarrassing situation with 'healthcare.gov' and the people that legislated the project - this schedule was driven by election deadlines, not by project managers. Thus one can see the usual litany of developer complaints - vague specifications, insufficient resources, continually changing objectives, pressure to get stuff out, etc., etc. If you're working across national boundaries and 'home office' people have little respect for the 'foreigners', this can erupt into serious chaos. The best thing to do would be to have the senior people visit the location on a regular schedule, and talk directly to the people doing the work. If 'they can't afford it' then they can't afford the project at all.
A good way of understanding this is 'assume you've hired a contractor to remodel your kitchen'. Your initial guess is that it will take two weeks to redo the kitchen. You have the new sink, countertop, and cabinets selected, so this is just straight out, straight in, right?
At any rate, every thing is pulled out and then one discovers the plumbing and wiring has to be shifted around. Then it turns out that the color of the flooring and the cabinetry doesn't make sense. Then the fridge sticks out too far, and the sink isn't centered with respect to the window. In short, the homeowner is changing requirements in mid-stream. The project bloats to 6 weeks.
The homeowner has never remodeled a kitchen before, and they hired the lowest bidder. Now there's a fight. Someone has to explain to the homeowner that changing specs changes costs, and that certain elements of this were unforeseen. If the homeowner isn't listening and doesn't care, then the contractor quits, leaving the homeowner in the lurch. Software projects end up in situations like this all the time.
Thus one has to deal relatively firmly with the people that are making the plans and paying the bills. The first thing to do is set up very short 'deliverables' cycles so that some progress can be demonstrated every week or two. The next is to abandon any idea that there is a fixed time and fixed budget - the planners should determine at what point the project can no longer pay it's way, and pull the plug at that point. If the bid is for $1 million and the opportunity is $10 million, the client should be prepared to spend $2 to $3 million if they can still get the $10 million payback.
A point should be made to the home office - very few employers are successful at managing software projects, but those that are make a lot of money (insert names of huge Silicon Valley companies here). Therefore, it is really worth it to keep trying until they understand how it's done. The last thing they can afford to do is demand that the budgets and schedule remain constant if the objectives are fluid.
answered Nov 13 '13 at 12:45
Meredith Poor
8,8661730
answered Nov 13 '13 at 12:45
Meredith Poor
8,8661730
answered Nov 13 '13 at 12:45
Meredith Poor
8,8661730
answered Nov 13 '13 at 12:45
Meredith Poor
8,8661730
8,8661730
I agree with you, your explanation match my current condition and your parable is very good! thanks man!
– Niko Adrianus Yuwono
Nov 14 '13 at 2:04
add a comment |Â
I agree with you, your explanation match my current condition and your parable is very good! thanks man!
– Niko Adrianus Yuwono
Nov 14 '13 at 2:04
I agree with you, your explanation match my current condition and your parable is very good! thanks man!
– Niko Adrianus Yuwono
Nov 14 '13 at 2:04
I agree with you, your explanation match my current condition and your parable is very good! thanks man!
– Niko Adrianus Yuwono
Nov 14 '13 at 2:04
add a comment |Â
up vote
1
down vote
It is part of the definition of my work, so what we usually do is to forward them to the other party with comments on how we think it could/should be fixed. But of course ultimately it's up to the recipient to decide, since we are just in the middle.
But it sounds like they are expecting you to solve the issues? In that case just do the same, but participate more actively in the incident management by collaborating with the other party. If you are the responsible party, then you must follow it through in the end. In other cases, just do your best - especially when under heavy loads.
Perhaps you could have weekly/monthly meetings with the representatives of both teams, and go through the recent issues and work on a solution that works for both parties.
answered Nov 13 '13 at 11:47
Juha Untinen
1,5261018
Yes, sometimes both of the sides expecting me to give a neutral solution for the issue, thanks for the advice man!
– Niko Adrianus Yuwono
Nov 14 '13 at 2:05
add a comment |Â
up vote
1
down vote
It is part of the definition of my work, so what we usually do is to forward them to the other party with comments on how we think it could/should be fixed. But of course ultimately it's up to the recipient to decide, since we are just in the middle.
But it sounds like they are expecting you to solve the issues? In that case just do the same, but participate more actively in the incident management by collaborating with the other party. If you are the responsible party, then you must follow it through in the end. In other cases, just do your best - especially when under heavy loads.
Perhaps you could have weekly/monthly meetings with the representatives of both teams, and go through the recent issues and work on a solution that works for both parties.
answered Nov 13 '13 at 11:47
Juha Untinen
1,5261018
Yes, sometimes both of the sides expecting me to give a neutral solution for the issue, thanks for the advice man!
– Niko Adrianus Yuwono
Nov 14 '13 at 2:05
add a comment |Â
up vote
1
down vote
up vote
1
down vote
It is part of the definition of my work, so what we usually do is to forward them to the other party with comments on how we think it could/should be fixed. But of course ultimately it's up to the recipient to decide, since we are just in the middle.
But it sounds like they are expecting you to solve the issues? In that case just do the same, but participate more actively in the incident management by collaborating with the other party. If you are the responsible party, then you must follow it through in the end. In other cases, just do your best - especially when under heavy loads.
Perhaps you could have weekly/monthly meetings with the representatives of both teams, and go through the recent issues and work on a solution that works for both parties.
answered Nov 13 '13 at 11:47
Juha Untinen
1,5261018
It is part of the definition of my work, so what we usually do is to forward them to the other party with comments on how we think it could/should be fixed. But of course ultimately it's up to the recipient to decide, since we are just in the middle.
But it sounds like they are expecting you to solve the issues? In that case just do the same, but participate more actively in the incident management by collaborating with the other party. If you are the responsible party, then you must follow it through in the end. In other cases, just do your best - especially when under heavy loads.
Perhaps you could have weekly/monthly meetings with the representatives of both teams, and go through the recent issues and work on a solution that works for both parties.
answered Nov 13 '13 at 11:47
Juha Untinen
1,5261018
answered Nov 13 '13 at 11:47
Juha Untinen
1,5261018
answered Nov 13 '13 at 11:47
Juha Untinen
1,5261018
answered Nov 13 '13 at 11:47
Juha Untinen
1,5261018
1,5261018
Yes, sometimes both of the sides expecting me to give a neutral solution for the issue, thanks for the advice man!
– Niko Adrianus Yuwono
Nov 14 '13 at 2:05
add a comment |Â
Yes, sometimes both of the sides expecting me to give a neutral solution for the issue, thanks for the advice man!
– Niko Adrianus Yuwono
Nov 14 '13 at 2:05
Yes, sometimes both of the sides expecting me to give a neutral solution for the issue, thanks for the advice man!
– Niko Adrianus Yuwono
Nov 14 '13 at 2:05
Yes, sometimes both of the sides expecting me to give a neutral solution for the issue, thanks for the advice man!
– Niko Adrianus Yuwono
Nov 14 '13 at 2:05
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f16653%2fhow-to-handle-complaints-and-suggestion-as-a-middle-man%23new-answer', 'question_page');
);
Post as a guest
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
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
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
