5

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?

6
  • Any motivations you can think of for why Team Bob is doing this? Deadlines? Budgets? Quarterly goals? Is a Team Alice win a loss for Team Bob in some way? Why is Team Bob under the executives if they don't have time to manage them? Jun 27 at 21:05
  • 2
    Deadlines + quarterly goals. Team Bob has high turnover and multiple on-the-record complaints from their own employees about aggressive mismanagement to meet deadlines. Their roadmap progress always looks the best in the company because of this aggressiveness/shortcuts, giving them major brownie points with the executive team, but it comes at a fairly large cost
    – Drudge
    Jun 27 at 21:12
  • "Why is Team Bob under the executives if they don't have time to manage them?" I'm not an executive, so hard to answer. I suspect it is a growing pain of the company where only a few years ago all engineering teams reported directly to the executive team, and this particular team is lagging behind
    – Drudge
    Jun 27 at 21:25
  • Once the work was reassigned to Team Alice, was the deadline changed, and expectations adjusted? Jun 28 at 2:45
  • Roadmap-wise the original project Team Bob had (which was scoped to entail UI) was marked as blocked & Team Alice added a project for UI the next quarter on the roadmap. Team Alice's project was delivered on time according to the roadmap, but Team Bob's was not because it required Team Alice's deliverable to ship
    – Drudge
    Jun 28 at 3:11
6

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.

2
  • If Team Bob can reported directly to the executives certainly Team Alice can do the exact same thing.
    – Donald
    Jun 28 at 17:24
  • This is good. If we can get Team Bob to agree to something and put it in writing in-meeting then they can't renegade on it later. And if they backpedal on everything in-meeting to where Team Alice can't write anything down then that is much easier to deal with, as not being able to come to a consensus is a good reason to pull the exec team in & Team Bob would have to go on the record with what they are asking.
    – Drudge
    Jun 29 at 4:55
2

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

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.

4
  • 2
    I feel there's a risk here: degenerate Team Bob might claim completion of the backend work, but hand over broken incomplete garbage, and then have Team A on the hook to deal with the fallout. Jun 28 at 15:04
  • I'd mention the use of a ticketing system to track any issues in the back end code from Team Bob. They would still 'own' the back end, but not be responsible for driving the schedule. They would still be on the hook for any blocking issues.
    – Noel
    Jun 28 at 21:32
  • Team Bob wanted to own the product development & relegate only the actual implementation to Team Alice, so Team Alice could not take full ownership of the project. You're right though, this would have been a good option had it been available. No risk of blame game when Team Alice is point of contact.
    – Drudge
    Jun 29 at 4:52
  • As far as incomplete garbage, as long as Team Alice is in full control of the project that shouldn't be an issue: they can document every defect and present it to the exec team. Though this is very hard when Team Bob has ownership, can lie, and then it's on Team Alice to fully investigate and irrefutably prove every little defect on top of their actual allocated work
    – Drudge
    Jun 29 at 4:59
-2

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.

2
  • 1
    For added context, Team Bob's tone was very much that of the blame game & not professional at all. Team Bob was actually assigned to complete the UI originally, couldn't, and then after their project was due came to Team Alice to pawn off the work. Yes Team Alice's work was what was gating release, but had Team Bob not waited a quarter to involve Team Alice for the UI the feature would have already been released. The blame very clearly trying to be shifted was not on Team Alice. But that's not the question being asked: when paper trails fail, what is the next best option
    – Drudge
    Jun 28 at 3:06
  • @Drudge I don't see how the paper trail is failing. Unless the paper trail is failing to reflect the points above. Which part are Team Bob lying about? Jun 28 at 3:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .