How to deal with teams that deliberately make their negligence hard to document/track?

Question

I work in a software engineering company with over 1000 engineers in silicon valley. We generally have really strong & healthy engineering teams, and have very high ratings on glassdoor. But occasionally there will be a bad apple that will skirt requirements/due diligence at the expense of other teams. Normally on Workplace SE, the suggestion for dealing with these problems is to document and escalate it, but for one particular team, this only worked in the beginning. It would go on to adapt, making its actions hard to document/track and even getting higher stakeholders to forget things that they decided in the first place.

Imagine a Team Bob: Team Bob has a project on its roadmap to deliver a customer-facing tool for estimating rainfall. Team Bob delivered a similar project in the past to very poor reception due to lacking a UI, and the new project also does not have a UI. It gets rejected in the executive review & UI mandated prior to release. The executive team suggests integrating this project into a tool that Team Alice owns. A quarter later, Team Bob has finished the non-UI half of the project and asks Team Alice to take over the UI portion, without advance notice. Team Alice gets input from the executive team who decide to cut one of Team Alice's original roadmap deliverables in favor of the UI for Team Bob's feature.

Team Alice communicates to the executive team up front how much the project will take (a whole quarter), but by this point Team Bob's promised delivery date for the feature is up. To excuse the delays, every week or so Team Bob passive aggressively mentions to the executive team that Team Bob's work (the non-UI half) is already done and Team Alice is blocking the release of the feature, even though Team Alice was only just involved. Team Alice tried to take the high road and ignored it, avoiding a grade school shouting match. Through repetition though, Team Bob convinced the executive team that it was really Team Alice delaying the project, even though the executive team agreed on the added cost upfront.

There was a lot more unprofessional behavior, but I will omit specifics for brevity. Team Alice attempted to surface these issues throughout the course of the project, but Team Bob reported directly to the executive team, so the executive team was the only medium that could intervene. It went well at first: when Team Bob would email Team Alice asking for permission to ship the feature without UI, Team Alice clarified the permission wasn't theirs to give and cc'd the executive member that owned the project. After this repeated & Team Bob got chewed out by the executive team a few times, Team Bob resorted to underhanded means. Team Bob would only show their true colors in face-to-face meetings. If Team Alice surfaced issues that happened there, then Team Bob would tell the executive staff Team Alice must have misunderstood them. Due to the executive team's busy schedules, it was not possible to invite them to the meetings. Eventually the executive team questioned if Team Alice had a grudge against Team Bob that caused them to escalate all of these (according to Team Bob) minor misunderstandings to the executive team.

How can Team Alice deal with Team Bob in such a way that 1) it is not exhausting, 2) Team Alice does not get blamed for anything resulting from Team Bob's subterfuge, and 3) Team Alice's product does not suffer at the hands of Team Bob?

Answer 1

You have correctly identified that Team Bob is avoiding accountability by not leaving a written record of their behavior. However, Team Alice is not at the mercy of Team Bob when it comes to documenting things, because Team Alice can create a written record, too.

For instance, when important matters are discussed face to face, put this in writing after the meeting, and send the meeting notes to Team Bob for verification.

You might also give regular status reports to the executives that detail the overall project plan, listing the agreed upon deliverables from both teams, while keeping Team Bob in the CC.

That is, if Team Bob is attempting to exploit that the project is poorly managed, step in and manage the project. This has the added benefit that it will bring you in contact with the executive team, allowing you to more easily counteract any subtle blame shifting Team Bob attempts to engage in.

Also:

Team Alice tried to take the high road and ignored it, avoiding a grade school shouting match

That was not wise. In remaining silent, Team Alice may have given the impression of having nothing to say in their defense, thereby admitting culpability. In addition, in letting Team Bob get away with shifting blame, Team Alice may have encouraged Team Bob to continue shifting blame.

Now, of course you should not start shouting, but a dry and dispassionate:

We are not "blocking" anything. But we can not finish in one week what your team failed to finish in a year. We estimated 3 months, and we are on track for achieving that. If you think your team can do it faster, I'd be happy to let your team take over.

should remind everyone of the relevant context, and make it clear that you are not the problem, but the solution.

Answer 2

Team Bob has finished the non-UI half of the project and asks Team Alice to take over the UI portion

OK, so Team Bob is finished their part.

How can Team Alice deal with Team Bob in such a way that [...] Team Alice's product does not suffer at the hands of Team Bob?

OK, so the product is Team Alice's product now.

So what's jangling about in my head is: why is Team Bob even still involved?

Team Alice should, logically, take ownership of the product at this point. That probably requires the executives to officially pass ownership from Team Bob to Team Alice somehow. But (barring any byzantine politics surrounding ownership and deliverables which may exist in the department) it sounds like it would not be difficult for Team Alice to convince the executive team of that, because Team Bob has finished their part. They have nothing more to add.

Perhaps there is an insistent view that Team Bob is the "client team" and Team Alice is the "supplier team", because the backend implementation is "the guts" and therefore critical, while the UI is only "the presentation" and therefore superficial, and therefore Team Bob should own the product. I've definitely seen such a bias before. But if both parts are required before the product can ship, it's nonsense; they're both critical. Product ownership needn't be linked to a particular development role like that.

Answer 3

Break things out using RACI charts.

Responsible

Accountable

Consulted

Informed

Along with clear and concise deadlines and dependencies.

Implement ITIL

If you have Team Bob with clear responsibilities for delivering components on time, and clear timelines for what is, and is NOT a dependency, you can head off blamestorming

Answer 4

So, in summary:

1. Team Bob could not get the UI work done in time
2. The executive team reassigned the UI work to Team Alice
3. Team Bob is reporting the Team Alice's newly assigned work is blocking the release

I don't really understand what the problem is. Those facts are indisputable.

To excuse the delays, every week or so Team Bob passive aggressively mentions to the executive team that Team Bob's work (the non-UI half) is already done and Team Alice is blocking the release of the feature, even though Team Alice was only just involved.

Team Bob are reporting facts. Not sure exactly what you want them to say. Should Team Bob indicate that they still have work remaining, even though they do not? The work assigned to Team Alice IS blocking the release. Doesn't mean Team Alice is bad or underperforming.

The Executive are the ones that reassigned the work to Team Alice after the deadline is passed, so, by extension, they must be aware that Team Alice is not to blame for missing the deadline with that work.

Obviously Team Alice needs a new deadline to complete that work, and once that work was handed over, that should have been discussed and decided.