Dick Costolo writes about the post-acquistion integration of Feedburner here. Brad Feld points out that this sort of thing is very, very hard – “[t]he deep dark hole of post acquisition integration is often deep and dark.” Ain’t that the truth. If I could ask Dick one thing these days, it’d be this – “when a team switches over from iterating and releasing new features rapidly to a lengthy period of integration work, how do you keep them happy and motivated, and how do you avoid losing momentum?” (Who knows, maybe Dick will read this and answer.)
UPDATE: And so he did, in the comments. (Thanks, Dick!)
{ 2 comments… read them below or add one }
“Why not build new services and integrate at the same time? There are lots of opinions about the best way to go through integrations. Our perspective is that the time you lose trying to continuously merge an updated legacy codebase with a new rewrite causes you be in a world of never actually getting the integration done because you’re constantly working on merge problems, which gives you less time to add new features OR get the new backend integration done, and eventually you kind of grind to a halt”
Wow, that sounds familiar.
Hey there Greg,
We have three things going for us, and I would stress that they are all Google things and not Dick Costolo is smart things. So, if we were going through this process someplace else, the answer might be a lot different.
First, many of the engineers have already picked up 20% time projects outside of FeedBurner, so those are a good way to work on new stuff and stay motivated.
Secondly, the integration we are executing is largely due to a lot of highly specialized ways of building/running things that Google has developed, and so it feels a lot less like just “use this different code management system and rewrite it all in Cobol and Fortran” and a lot more like “here’s a better/cooler/faster way to do a bunch of things”, so that’s also less monotonous. Certainly, we have had a not insignificant number of “ugh, that’s going to be painful” parts of this process as well, but at least it’s not ALL painful.
Lastly, similar to the 20% projects, the FB engineering team has been pretty well culturally integrated with the rest of the Chicago engineering team now, so some of the other Chicago Google engineers are helping out with challenging/painful FeedBurner stuff and some of the FB engineers are getting exposed to other cool projects. When there’s “shared pain”, it makes it a lot easier for everybody to wade through the integration.
To generalize then, i’d say you want the entire eng org (or at least the regional eng org) to embrace the integration challenge so it’s not just a couple poor jamokes in the corner slogging away, and then you want to give the team some other projects to occasionally focus on, and as it so happens, Google is one of the ideal places for that sort of thing. Frankly, that goes for the product management, publisher services, and ad ops staff as well.