I run my company's central data team. Other teams depend on the output of our daily refresh pipeline which includes jobs that both my team has written (such as building our core orders and customers tables) and also jobs that other teams have written (specific reporting tables built from those core tables). All failed jobs are pushed to a company-public Slack channel, and we have a support rota to investigate failures and inform affected teams.
One team in particular has some reporting jobs in our pipeline that are required for financial auditing. These jobs often fail due to errors introduced by this team or due to one particularly unreliable external data source. Any failures cause significant disruption to this team and others who depend on them, but they don't seem interested in improving these processes and refuse my help. Their jobs failing doesn't affect any other users of the central data platform so it's not a critical concern of mine.
The alerting Slack channel is often full of this team's job failures, and when the incident in question happened it was the third different failure we'd seen from this team's jobs in that week.
Last week one of these jobs failed due to an error introduced by a member of my team - he was doing some routine background optimisation work in an upstream table that duplicated a small number of records. We informed the team immediately when the job failed and fixed it within a few hours. We also held an internal post-incident review and made a couple of technical and process changes to stop this specific issue from happening again.
This was the first time in the 18 month lifespan of my central data platform that any of these jobs have failed because of a bug introduced by my team.
I was therefore quite surprised to see a meeting invite in my calendar involving several senior stakeholders from the other team to discuss how my team can mitigate our impact on their important jobs. They also want us to inform them every time we do work that might impact their jobs.
I've been doing this job for long enough to know that sometimes things go wrong and that it's a normal part of the engineering process. If there was a prior history of my team breaking things then I'd understand their concern, but there's not. Add to this that they don't seem to care much whenever their jobs break for other reasons, and I'm a bit miffed.
My questions are:
What do I mention in the meeting? Do I say "why are we having a meeting when this is the first time we've broken something, and we fixed it quickly anyway?" or do I simply treat it like a post-incident review and walk everyone through what happened and what steps we have in place to prevent it happening again? I don't want to anger anyone or have them think I'm being difficult (I get on well with these people), but I also don't want them thinking that my team is unreliable or risky.
Do I agree to inform them every time we do work that might impact their jobs? My team are constantly doing internal tasks around optimisation and refactoring that have no noticeable impact on external teams. I'm worried that telling this team every time we do such a task will a)result in them not understanding the importance when we need to change something that actually impacts them and b)add a tedious "contact this team" step into most of our tasks.
My questions are around how I should handle this specific meeting. I'm not interested in advice about changing data ownership processes, that's already in progress.