Bxdty

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?

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.

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.