Consulting Chronicles: Navigating Turbulent Waters

There are times where the smooth surface of collaboration is shadowed by turbulent undercurrents. This was the case with a team I was tasked to oversee, where dependency on a client's team became a focal point. Our success hinged on their timely deliverables, a fact compounded by our integral role in centralizing customer data, drawing the attention of various client teams eager to collaborate.

The story

Ever since we started looking into the solution we had to build, because the team was building something that had to do with centralizing the customer-related data, all the teams in the client wanted to work with us. We ended up working with a team who claimed to have half of it done and we could just "plug in and use it".

Since the beginning, they were very protective of their realm. They had one Tech Lead and one Engineering Manager, on the first meeting they said "we are your interface to the team, you speak to us and we communicate to the technical team" this was, according to them, to protect the engineering time. In this case, what was perceived and sold as a way to streamline communication, later on proved to be the first sign of warning.

As the project progressed, attempts to integrate into a cohesive unit were met with resistance. Requests to merge backlogs and synchronize ceremonies were rejected, quoting their manager leave or tasks alone, showing complete reluctance to share control over the deliverables. Despite these indicators, we moved on, operating as a team with two different backlogs and methodologies with periodic sync-ups.

Six weeks into the integration, after a few data streams were functional, the facade crumbled, suddenly everything stopped working. What was portrayed as a production-ready solution turned out to be a mere proof of concept, unfit for scalability and abruptly discontinued. The ensuing chaos, compounded by elusive timelines and shifting commitments, exposed the precariousness of our situation. Attempts to seek clarity were met with obfuscation, and we only got to know thanks to a casual conversation between our Product Manager and one of their Engineers.

The second attempt, after they found a better approach, was even worse, deadlines were a moving target, our asks for commitment were met with reluctance to agree on deadlines. To make things even more confusing, their lead communicated something in the meetings with their manager, but in reality it was the complete opposite. We didn't want to escalate the situation to preserve the good relationship we had with their manager, a VP level executive who was very supportive and helpful in other instances.

All the situation made it look like we were not delivering anything, when in reality we didn't have anything to work with due to an unresolved dependency without a clear way forward. In the end, when we raised it, it was too late and everything had to be adjusted.

Looking back, the signs were unmistakable, yet overlooked in favor of preserving rapport and some inexperience in my end. However, the lesson learned was invaluable: trust should not be a given, it should be earned. Relationships should not preclude the discussion of issues and tough conversations; rather, they should foster an environment conducive to mutual problem-solving, if this is not the case, something fishy lies under the ground.