How to communicate a roadblock that has no solution until the breaking change is fixed?
I believe based on my online investigation for well over an hour, looking at Github issues that there is a breaking change that is keeping a project from moving forward.
I am still very much a greenhorn in "managing expectations", whatever that means and so I need some pointers on how to communicate a roadblock that has no solution until a fix has been produced by the team that maintains the technology utilized to move the project forward?
Should we reach out to the team and inquire about when a fix can be expected and communicate that up the chain and hope it is enough?
communication expectations
asked 2 days ago
DanielDaniel
476111
add a comment |
I believe based on my online investigation for well over an hour, looking at Github issues that there is a breaking change that is keeping a project from moving forward.
I am still very much a greenhorn in "managing expectations", whatever that means and so I need some pointers on how to communicate a roadblock that has no solution until a fix has been produced by the team that maintains the technology utilized to move the project forward?
Should we reach out to the team and inquire about when a fix can be expected and communicate that up the chain and hope it is enough?
communication expectations
asked 2 days ago
DanielDaniel
476111
2
what is your position and responsibility in regards to this issue?
– Kilisi
2 days ago
@Kilisi, I am responsible for completion of the project.
– Daniel
2 days ago
add a comment |
I believe based on my online investigation for well over an hour, looking at Github issues that there is a breaking change that is keeping a project from moving forward.
I am still very much a greenhorn in "managing expectations", whatever that means and so I need some pointers on how to communicate a roadblock that has no solution until a fix has been produced by the team that maintains the technology utilized to move the project forward?
Should we reach out to the team and inquire about when a fix can be expected and communicate that up the chain and hope it is enough?
communication expectations
asked 2 days ago
DanielDaniel
476111
I believe based on my online investigation for well over an hour, looking at Github issues that there is a breaking change that is keeping a project from moving forward.
I am still very much a greenhorn in "managing expectations", whatever that means and so I need some pointers on how to communicate a roadblock that has no solution until a fix has been produced by the team that maintains the technology utilized to move the project forward?
Should we reach out to the team and inquire about when a fix can be expected and communicate that up the chain and hope it is enough?
communication expectations
communication expectations
asked 2 days ago
DanielDaniel
476111
asked 2 days ago
DanielDaniel
476111
asked 2 days ago
DanielDaniel
476111
asked 2 days ago
DanielDaniel
476111
asked 2 days ago
DanielDaniel
476111
476111
2
what is your position and responsibility in regards to this issue?
– Kilisi
2 days ago
@Kilisi, I am responsible for completion of the project.
– Daniel
2 days ago
add a comment |
2
what is your position and responsibility in regards to this issue?
– Kilisi
2 days ago
@Kilisi, I am responsible for completion of the project.
– Daniel
2 days ago
2
2
what is your position and responsibility in regards to this issue?
– Kilisi
2 days ago
what is your position and responsibility in regards to this issue?
– Kilisi
2 days ago
@Kilisi, I am responsible for completion of the project.
– Daniel
2 days ago
@Kilisi, I am responsible for completion of the project.
– Daniel
2 days ago
add a comment |
3 Answers
3
active
oldest
votes
First, try to create the best compact but clear, factual rather than blame explanation of the issue you can, and ideally include a compact code fragment which demonstrates the issue. Writing good bug reports is a skill, but better reports get much better response.
Depending on who you report to, you may also need to create a second explanation of the issue in more everyday, less technical language. Sometimes a good analogy can help communicate the nature of the issue in a way that your audience can personally identify with.
Then, while waiting for response, if this has priority over anything else you could be working on, consider what you can do to help resolve the problem.
Can you roll back your version of the other code to a previous version before the breaking change? Or is the change too integral to anything else you might do for any progress made without it to be ultimately useful?
Can you get a formal or informal meeting with those from the other team to discuss the issue? Or it is a case where your supervisor will have to make a request through their supervisor? Even walking over and spending a minute or two trying to get a sense of how they feel about the issue (do they agree there even is an issue?) could inform your course of action.
Can you craft a workaround in your code, ideally demarcated by conditional compilation or at least good comments?
Can you work through the other code and perhaps devise a fix? Even if you aren't able to create one they could actually merge, a crude patch can still show what needs to be done in a way that lets the code owners focus effort on accomplishing that in the most fitting way. Make sure anything you do submit to them is a clean and quiet diff which only touches what you actually need to change.
If the change is inline with the strategic direction of your organization, be open to the idea that they may expect you to adapt to it. If this is going to be of unworkable cost, you'll need to present good strategic arguments to your supervisor which they can present to the other team's leader and potentially their mutual supervisor.
answered 2 days ago
Chris StrattonChris Stratton
713610
add a comment |
Communicate your steps forward
Just pointing to a different team and then twiddle your thumbs until it's fixed isn't very professional, and not something management looks forward to. It means they will have to step in to get things moving again.
Decide, with your team, how you are going to move forward. Can you rollback to a previous version? Can you code around the issue? Can you apply a (temporary) patch? Did you communicate the problems with the other team? What was there response? Those are the things management is interested in. They vastly prefer a team which can solve roadblocks -- they want to know about the roadblocks but they rather not have to step in.
answered 2 days ago
AbigailAbigail
3,98221121
add a comment |
Since you are responsible for the completion of the project you need to keep communication flowing on issues that impact on it.
Keep your research to yourself for now (unless you're a qualified expert with in depth knowledge of the problem) and ask for a status report on the block. If you don't see what you need, then dig deeper. But remember that these are the techs on the ground, they should already know what the problem is and be working towards a resolution.
You only step in if communications are failing and things are not getting done, until then you trust your people while keeping an eye on them. Don't be shy to follow up if you're not getting satisfactory replies.
answered 2 days ago
KilisiKilisi
1
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "423"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: false,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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%2f131819%2fhow-to-communicate-a-roadblock-that-has-no-solution-until-the-breaking-change-is%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
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();
}
}
});
});
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
First, try to create the best compact but clear, factual rather than blame explanation of the issue you can, and ideally include a compact code fragment which demonstrates the issue. Writing good bug reports is a skill, but better reports get much better response.
Depending on who you report to, you may also need to create a second explanation of the issue in more everyday, less technical language. Sometimes a good analogy can help communicate the nature of the issue in a way that your audience can personally identify with.
Then, while waiting for response, if this has priority over anything else you could be working on, consider what you can do to help resolve the problem.
Can you roll back your version of the other code to a previous version before the breaking change? Or is the change too integral to anything else you might do for any progress made without it to be ultimately useful?
Can you get a formal or informal meeting with those from the other team to discuss the issue? Or it is a case where your supervisor will have to make a request through their supervisor? Even walking over and spending a minute or two trying to get a sense of how they feel about the issue (do they agree there even is an issue?) could inform your course of action.
Can you craft a workaround in your code, ideally demarcated by conditional compilation or at least good comments?
Can you work through the other code and perhaps devise a fix? Even if you aren't able to create one they could actually merge, a crude patch can still show what needs to be done in a way that lets the code owners focus effort on accomplishing that in the most fitting way. Make sure anything you do submit to them is a clean and quiet diff which only touches what you actually need to change.
If the change is inline with the strategic direction of your organization, be open to the idea that they may expect you to adapt to it. If this is going to be of unworkable cost, you'll need to present good strategic arguments to your supervisor which they can present to the other team's leader and potentially their mutual supervisor.
answered 2 days ago
Chris StrattonChris Stratton
713610
add a comment |
First, try to create the best compact but clear, factual rather than blame explanation of the issue you can, and ideally include a compact code fragment which demonstrates the issue. Writing good bug reports is a skill, but better reports get much better response.
Depending on who you report to, you may also need to create a second explanation of the issue in more everyday, less technical language. Sometimes a good analogy can help communicate the nature of the issue in a way that your audience can personally identify with.
Then, while waiting for response, if this has priority over anything else you could be working on, consider what you can do to help resolve the problem.
Can you roll back your version of the other code to a previous version before the breaking change? Or is the change too integral to anything else you might do for any progress made without it to be ultimately useful?
Can you get a formal or informal meeting with those from the other team to discuss the issue? Or it is a case where your supervisor will have to make a request through their supervisor? Even walking over and spending a minute or two trying to get a sense of how they feel about the issue (do they agree there even is an issue?) could inform your course of action.
Can you craft a workaround in your code, ideally demarcated by conditional compilation or at least good comments?
Can you work through the other code and perhaps devise a fix? Even if you aren't able to create one they could actually merge, a crude patch can still show what needs to be done in a way that lets the code owners focus effort on accomplishing that in the most fitting way. Make sure anything you do submit to them is a clean and quiet diff which only touches what you actually need to change.
If the change is inline with the strategic direction of your organization, be open to the idea that they may expect you to adapt to it. If this is going to be of unworkable cost, you'll need to present good strategic arguments to your supervisor which they can present to the other team's leader and potentially their mutual supervisor.
answered 2 days ago
Chris StrattonChris Stratton
713610
add a comment |
First, try to create the best compact but clear, factual rather than blame explanation of the issue you can, and ideally include a compact code fragment which demonstrates the issue. Writing good bug reports is a skill, but better reports get much better response.
Depending on who you report to, you may also need to create a second explanation of the issue in more everyday, less technical language. Sometimes a good analogy can help communicate the nature of the issue in a way that your audience can personally identify with.
Then, while waiting for response, if this has priority over anything else you could be working on, consider what you can do to help resolve the problem.
Can you roll back your version of the other code to a previous version before the breaking change? Or is the change too integral to anything else you might do for any progress made without it to be ultimately useful?
Can you get a formal or informal meeting with those from the other team to discuss the issue? Or it is a case where your supervisor will have to make a request through their supervisor? Even walking over and spending a minute or two trying to get a sense of how they feel about the issue (do they agree there even is an issue?) could inform your course of action.
Can you craft a workaround in your code, ideally demarcated by conditional compilation or at least good comments?
Can you work through the other code and perhaps devise a fix? Even if you aren't able to create one they could actually merge, a crude patch can still show what needs to be done in a way that lets the code owners focus effort on accomplishing that in the most fitting way. Make sure anything you do submit to them is a clean and quiet diff which only touches what you actually need to change.
If the change is inline with the strategic direction of your organization, be open to the idea that they may expect you to adapt to it. If this is going to be of unworkable cost, you'll need to present good strategic arguments to your supervisor which they can present to the other team's leader and potentially their mutual supervisor.
answered 2 days ago
Chris StrattonChris Stratton
713610
First, try to create the best compact but clear, factual rather than blame explanation of the issue you can, and ideally include a compact code fragment which demonstrates the issue. Writing good bug reports is a skill, but better reports get much better response.
Depending on who you report to, you may also need to create a second explanation of the issue in more everyday, less technical language. Sometimes a good analogy can help communicate the nature of the issue in a way that your audience can personally identify with.
Then, while waiting for response, if this has priority over anything else you could be working on, consider what you can do to help resolve the problem.
Can you roll back your version of the other code to a previous version before the breaking change? Or is the change too integral to anything else you might do for any progress made without it to be ultimately useful?
Can you get a formal or informal meeting with those from the other team to discuss the issue? Or it is a case where your supervisor will have to make a request through their supervisor? Even walking over and spending a minute or two trying to get a sense of how they feel about the issue (do they agree there even is an issue?) could inform your course of action.
Can you craft a workaround in your code, ideally demarcated by conditional compilation or at least good comments?
Can you work through the other code and perhaps devise a fix? Even if you aren't able to create one they could actually merge, a crude patch can still show what needs to be done in a way that lets the code owners focus effort on accomplishing that in the most fitting way. Make sure anything you do submit to them is a clean and quiet diff which only touches what you actually need to change.
If the change is inline with the strategic direction of your organization, be open to the idea that they may expect you to adapt to it. If this is going to be of unworkable cost, you'll need to present good strategic arguments to your supervisor which they can present to the other team's leader and potentially their mutual supervisor.
answered 2 days ago
Chris StrattonChris Stratton
713610
edited 2 days ago
answered 2 days ago
Chris StrattonChris Stratton
713610
answered 2 days ago
Chris StrattonChris Stratton
713610
answered 2 days ago
Chris StrattonChris Stratton
713610
713610
add a comment |
add a comment |
Communicate your steps forward
Just pointing to a different team and then twiddle your thumbs until it's fixed isn't very professional, and not something management looks forward to. It means they will have to step in to get things moving again.
Decide, with your team, how you are going to move forward. Can you rollback to a previous version? Can you code around the issue? Can you apply a (temporary) patch? Did you communicate the problems with the other team? What was there response? Those are the things management is interested in. They vastly prefer a team which can solve roadblocks -- they want to know about the roadblocks but they rather not have to step in.
answered 2 days ago
AbigailAbigail
3,98221121
add a comment |
Communicate your steps forward
Just pointing to a different team and then twiddle your thumbs until it's fixed isn't very professional, and not something management looks forward to. It means they will have to step in to get things moving again.
Decide, with your team, how you are going to move forward. Can you rollback to a previous version? Can you code around the issue? Can you apply a (temporary) patch? Did you communicate the problems with the other team? What was there response? Those are the things management is interested in. They vastly prefer a team which can solve roadblocks -- they want to know about the roadblocks but they rather not have to step in.
answered 2 days ago
AbigailAbigail
3,98221121
add a comment |
Communicate your steps forward
Just pointing to a different team and then twiddle your thumbs until it's fixed isn't very professional, and not something management looks forward to. It means they will have to step in to get things moving again.
Decide, with your team, how you are going to move forward. Can you rollback to a previous version? Can you code around the issue? Can you apply a (temporary) patch? Did you communicate the problems with the other team? What was there response? Those are the things management is interested in. They vastly prefer a team which can solve roadblocks -- they want to know about the roadblocks but they rather not have to step in.
answered 2 days ago
AbigailAbigail
3,98221121
Communicate your steps forward
Just pointing to a different team and then twiddle your thumbs until it's fixed isn't very professional, and not something management looks forward to. It means they will have to step in to get things moving again.
Decide, with your team, how you are going to move forward. Can you rollback to a previous version? Can you code around the issue? Can you apply a (temporary) patch? Did you communicate the problems with the other team? What was there response? Those are the things management is interested in. They vastly prefer a team which can solve roadblocks -- they want to know about the roadblocks but they rather not have to step in.
answered 2 days ago
AbigailAbigail
3,98221121
answered 2 days ago
AbigailAbigail
3,98221121
answered 2 days ago
AbigailAbigail
3,98221121
answered 2 days ago
AbigailAbigail
3,98221121
3,98221121
add a comment |
add a comment |
Since you are responsible for the completion of the project you need to keep communication flowing on issues that impact on it.
Keep your research to yourself for now (unless you're a qualified expert with in depth knowledge of the problem) and ask for a status report on the block. If you don't see what you need, then dig deeper. But remember that these are the techs on the ground, they should already know what the problem is and be working towards a resolution.
You only step in if communications are failing and things are not getting done, until then you trust your people while keeping an eye on them. Don't be shy to follow up if you're not getting satisfactory replies.
answered 2 days ago
KilisiKilisi
1
add a comment |
Since you are responsible for the completion of the project you need to keep communication flowing on issues that impact on it.
Keep your research to yourself for now (unless you're a qualified expert with in depth knowledge of the problem) and ask for a status report on the block. If you don't see what you need, then dig deeper. But remember that these are the techs on the ground, they should already know what the problem is and be working towards a resolution.
You only step in if communications are failing and things are not getting done, until then you trust your people while keeping an eye on them. Don't be shy to follow up if you're not getting satisfactory replies.
answered 2 days ago
KilisiKilisi
1
add a comment |
Since you are responsible for the completion of the project you need to keep communication flowing on issues that impact on it.
Keep your research to yourself for now (unless you're a qualified expert with in depth knowledge of the problem) and ask for a status report on the block. If you don't see what you need, then dig deeper. But remember that these are the techs on the ground, they should already know what the problem is and be working towards a resolution.
You only step in if communications are failing and things are not getting done, until then you trust your people while keeping an eye on them. Don't be shy to follow up if you're not getting satisfactory replies.
answered 2 days ago
KilisiKilisi
1
Since you are responsible for the completion of the project you need to keep communication flowing on issues that impact on it.
Keep your research to yourself for now (unless you're a qualified expert with in depth knowledge of the problem) and ask for a status report on the block. If you don't see what you need, then dig deeper. But remember that these are the techs on the ground, they should already know what the problem is and be working towards a resolution.
You only step in if communications are failing and things are not getting done, until then you trust your people while keeping an eye on them. Don't be shy to follow up if you're not getting satisfactory replies.
answered 2 days ago
KilisiKilisi
1
answered 2 days ago
KilisiKilisi
1
answered 2 days ago
KilisiKilisi
1
answered 2 days ago
KilisiKilisi
1
1
add a comment |
add a comment |
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.
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%2f131819%2fhow-to-communicate-a-roadblock-that-has-no-solution-until-the-breaking-change-is%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
2
what is your position and responsibility in regards to this issue?
– Kilisi
2 days ago
@Kilisi, I am responsible for completion of the project.
– Daniel
2 days ago