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.

Comments (23)
  1. Dan McCarty says:

    Once there was this guy who did this thing and he learned a good lesson from it and now I want to tell his story, but I can’t provide any details.

    Raymond, I always appreciate your posts and the historical ones are great.  But leaving out all the details is the great way to write a boring story.

    It’s not finger pointing if your using the example in a constructive way.

  2. Moi says:

    It wouldn’t matter to the Project Leaders – one of them would be demoted, kicked aside, or whatever, so regardless of whether the teams would be merged or not, one of them would end up losing. Not surprising then if they, deliberately or otherwise, didn’t tell their teams the whole story.

  3. says:

    You can hardly blame Raymond for not providing full disclosure. Especially if any of the projects were classified or trade secrets, that’s not the kind of thing you want to have your name associated with on the Internet.

    Now, if Raymond writes a post about "a certain youth" who was strapped for cash in college and resorted to filming himself on Coders Gone Wild XIII, I think the identity might be a little more obvious… ;)

  4. Name says:

    Is this the same project that chose the code name "Highlander" (there can be only one)?

  5. Puckdropper says:

    Raymond, I always appreciate your posts and the historical ones are great.  But leaving out all the details is the great way to write a boring story.

    Got the point across to me.  I was going to comment how I liked the use of 1 and A rather than the typical 1 and 2 or A and B to distinguish things.

  6. The only details I omitted were the names of Project 1, Project A, and the head of the division.

  7. kbiel says:

    It sounds like management failed to communicate effectively with the project leads.  This sounds like another case of top-down management gone awry.

  8. Chris says:

    "Let’s call them Project A and Project 1."

    Raymond seems to be a Futurama fan.

  9. ChrisR says:

    Sounds like it could be the two Windows teams (9X vs NT).  Although it would be hard to imagine the 9X team writing documents saying it was the "wave of the future" compared to NT.

  10. Miles Archer says:

    If the leader of Project A was more astute, the document would have been written to be, on face value, impartial. Of course it would have been slanted, but not obviously so.

  11. Nawak says:

    Oh come on!!!

    Everybody KNOWS that Project 1 was vastly superior!!

  12. JadePhilosopher says:

    kbiel and moi hit the nail on the head.

    Only 1 project lead will remain on the project. Upper management failed to communicate the fate of the other project lead. Unless both leads are exceptional, at least one will go into risk avoidance mode.

    When you have grokked the mind of the middle manager, the logic of his seemingly inane decisions becomes clear.

  13. Dave says:

    This is probably the OS/2 and NT battle…

    After all, you were an OS/2 programmer before, right?

  14. Jerry Pisk says:

    I didn’t really learn much, what happened in the end? Were the teams integrated? Was the Project A’s PM put in charge? Or not? Were there any consequences?

  15. But isn’t this the rule rather than the exception at Microsoft? Historically many near-identical feature areas have been handled by teams from different divisions.

    The classic area would be *indexing and search*. This has been parcelled out between so many groups at Microsoft over the last decade that it’s no wonder its shipped technology lags others. If your product needed to be a search client, it might have to rely on releases from 3 different groups (each with their own namespace and API) sharing 50-80%

    of the LCD features.

    How many "lite" database projects, install routines, language parsers or image annotators have been developed to near ship quality before being terminated suddenly and all bits & specs archived? Whether you’re an employee, customer or share-holder these are important questions.

  16. Harold says:

    Just like an episode of "Survivor".

  17. MSDN Archive says:

    Isn’t the root problem really that we have different teams living in their own little silos? And doesn’t that problem still exist? I found out recently that some folks in your neck of the OS, Raymond, and some folks in mine aren’t exactly best of buddies. And IMHO the problem(s) could have been avoided if the two factions had been in contact much earlier. That’s my own somewhat evasive story.

    On a similar topic, am I the only one who actually uses WIMs to swap stories with folks in different parts of the division? It wasn’t very heavily attended yesterday, but I still managed to run into a few people I don’t usually see and found out a little about what they’re up to now. And that included finding out (happy surprise!) about some feature integration that I was hoping would happen, but thought had been punted to Vienna already. Nope. It’s gonna ship in Vista. Well . . . probably server, whatever that will be called. Ok. So that was vague and evasive, too. Not sure how much I can say in a public forum. Especially because I’m not on that unnamed team.

    – Drew

  18. [Response to Drew]

    I’d say "fiefdoms" rather than silos. I once owned a feature area that was developed solely by one division, and shipped solely by another. The organizational (which turned in technical) problems that built up over the years were never resolved due to perpetual pissing competitions between a PUM and a VP with no manager in common other than BillG. Why does this stuff never get bumped upstairs so that someone who gives a damn can bang their heads together…..

  19. Miral says:

    ChrisR: Other way around.  I think "Project A" is NT, and "Project 1" is 9x (look at the letter/number correspondence).  So it was the NT team that argued that their product was superior to 9x… and they won :)

  20. AntiSpy says:

    Could this be MS AntiSpyware group and the Windows OneCare group? Windows OneCare is to include anti-pyware too, so I heard.

  21. Mihai says:

    It might be worse. Let’s imagine team A goes in defense mode instead of atack. And quietly start looking for other jobs.

  22. julie:) says:

    on a random note, i thought i was reading about "team interrogations" and was a bit confused…  more sleep is needed on my behalf apparently.  

  23. David Walker says:

    It would be funny if, while Project A was busy writing large documents documenting why its methods were superior, Project 1 was busy getting the job done.

Comments are closed.

Skip to main content