On Being Acquired – Lessons Learned

Once upon a time, I was one of the three full-time employees at Colusa Software, which Microsoft acquired in 1996.  We all came to Microsoft as part of the buyout, and went on to learn some interesting lessons about having your very small company acquired by a very large one.

Who We Were

Colusa was building some nifty virtual machine technology – you could target it from any conventional language, could run in a protected sandbox, and could get close to natively compiled performance on a variety of hardware platforms.   Our dream was that we would contribute towards a VM for Windows that would ultimately run much of the software in the world.  Other companies wanted to acquire us, but we came to Microsoft because we thought it offered the best chance for our technology to be ubiquitous – we said to each other that it would be a place to build software that “my mom will use.”  That was a very powerful motivation.

What Happened

After we were acquired, we ended up in the Visual Studio organization.  It seemed to make sense because we needed to work closely with the compiler team to target the VM, but actually it was a mistake.  All of the major decisions about runtimes were being made elsewhere, and we had limited contact with the key people.  Many of them were already committed to other solutions.

The result was that we kept getting redirected from afar.  “Your VM would be perfect if the wire size was smaller than Java.”  Ok, we went and built a cool compression strategy that yielded extremely compact code.  “Your VM is out of the question because it isn’t compatible with Java bytecodes.”  Oh.  “Your VM is Microsoft’s future.”  Great!  “Your VM would be cool, but isn’t practical without a substantial modification to Windows that would require too many resources.”  But …  And so on.

Amidst these conflicting messages, we tried to soldier ahead.  We rebuilt our original system to work with Windows, and demonstrated that it worked  by recompiling Microsoft Word and running it on the VM with performance indistinguishable from natively compiled code.  Eventually the team helped design the bytecode strategy of one of the VMs in the operating system.  Although it wasn’t what we had originally hoped to accomplish, the ideas did influence the design of a part of Windows.

So, what did I learn from all this?

Lesson #1: Have a champion

By far the most important lesson is that you desperately want to have a senior person who is the champion for your group.  We didn’t have one, and we suffered badly for it.  The need is particularly acute if you walk into a politically charged area.  There were deep divisions in the company that we didn’t understand – it was confusing for long-time employees and utterly baffling to us.  We thought we had something that the company would eagerly seize upon.  Over the course of six months, we were told that we had one of the most important projects in the company, that our technology would be scrapped, and that we should redesign it in ways that we felt would be a disaster.  Not fun.

I don’t think anyone could have prevented the situation from being difficult and confusing, because the company was facing very tough and important decisions.  But at least we would have felt that somebody was in the key meetings advocating for us and then telling us what was happening.  I think the team was hurt, for example, by a feeling among some key partner teams that we were overselling.  We thought we had carefully explained that, for a commercially viable solution, we would have to rely on other parts of the company to deliver key missing pieces.  But that message didn’t get through.  This kind of disconnect happens all the time and is natural; people who hear about a technology without the details make assumptions about what it does and doesn’t deliver.  Teams have to actively (and continually) educate their partners.  We just weren’t talking to them.  In fact, we didn’t even know their names.

To a company being acquired, I can’t stress enough that you want a politically savvy champion who has the ear of the key architects, people in management, etc. and will go to bat for you when it is appropriate.  You want that person to be identified with the acquisition and their credibility on the line as to whether it succeeds or fails.  They should drive you hard and want to exploit your ideas for the maximum benefit of the company – after all, that’s what you want, too!

Lesson #2: End up in the right part of the organization

Many large organizations have teams that are quite autonomous from each other.  If you land in the right place, which we didn’t, the people around you will understand how to integrate your technology into the product portfolio of the company and be in a position to make that happen.  The key thing, though, is that your hosting organization is the one that drives the decisions that most directly affect you.

Lesson #3: Nobody trusts you

Getting acquired feels like a seal of approval.  It says that you were doing something cool enough that the big company felt it was better to buy it than to build it themselves.  That doesn’t prepare you for the likelihood that nobody in your new company will trust you at all.  They won’t believe that your code is any good or that your team is up to the standards of the rest of the organization.

As far as I’ve seen, there are only two solutions:

• Seed your team with some experienced and trusted employees from the big company.  This is a great idea anyway, because in addition to providing credibility, they can also be enormously helpful in getting things done in your new environment.
• Ship and win in the marketplace.  That’s the ultimate coin of the realm in any software company.

Final Thoughts

There were ups and downs throughout the experience, but I learned an enormous amount from being acquired by and working within a large company.  I’m doing my third startup now, and hopefully applying lessons learned from all the experiences I’ve been fortunate enough to have along the way.