Not all team integrations go smoothly
When writing the entry on Windows Integration Meetings, I was reminded of a team integration that didn’t go quite so smoothly. I will not identify the teams involved because this is not an outlet for finger-pointing but rather a cautionary tale for managers and developers everywhere. Once upon a time, there were two teams developing projects that ended up converging and solving roughly the same problem, but approaching it from different angles. Let’s call them Project A and Project 1. The head of the division that was responsible for both of these projects looked at the situation and said, “Well, now that they’ve converged, it seems kind of silly to have two projects, doesn’t it.” The people on Project A went on high alert. “The head of the division is going to keep one of the projects and cancel the other! Let’s make sure we’re the one they decide to keep.” They wrote large documents laying out a feature-by-feature comparison of the two projects explaining why Project A is technically superior to Project 1 in every way, why Project 1 was a dead end compared to Project A which was the wave of the future, and why the people Project A had better fashion sense than the people on Project 1. (“Black shoes with a brown belt, oh puh-leeze!”)
It turns out the head of the division was actually planning to merge the two teams, not pit them against each other in a fight to the death. But the attack documents drafted by Project A poisoned the relationship between the two teams, setting the integration off on a very sour note.