You can buy a company’s code, its customers and its logo in an afternoon (well sort of, you know what I mean). What you cannot buy, is the reason any of it was built the way it was.
Twice in my career I’ve watched a company buy another company mostly for a logo and the customer list, and then act genuinely surprised when the systems underneath turned out to have opinions. Very strong ones. Let’s be clear, I was not the one signing the contract. I’m the guy who turns up and checks in the secured data room a few weeks later, looks at a tidy architecture diagram, and asks the hard questions. Which was actually not that hard: okay, but who actually understands any of this?
You can’t reboot a horse
I have three horses (actually I don’t, my wife does, tip of the day: don’t marry a horse girl. I didn’t plan on three, that’s a whole other story). And the single most useful thing they’ve taught me about acquisitions is that you can’t reboot a horse.
A server, or a VM, or a service you can restart. A horse you cannot rush, cannot reason with, and cannot reboot. Its temperament was shaped over years, and most of what you need to know about it lives in the head of the one person who has fed it every morning. Which fence it leans on. Which sound sends it sideways, yes they are flight animals, ask me how I know. When “she’s just being dramatic” and when “this is going to be expensive, call the vet, now”
You see? Horses are flight animals!
Now imagine buying that horse from a photo, on Facebook, from someone who is leaving to another country the day after the sale closes. You get the animal, the person who knew it from a veulen and all it quirks not. That, more or less, is what buying a platform in an acquisition feels like from where I sit.
So what has this to do with acquisitions?
I’ve written before about the Law of Contextual Decay, the idea that the context around a component decays far faster than the component itself, and the other side of the coin, about the Amber Trap, where a system’s frozen context quietly turns into a liability. Both of those were about your own systems, built by your own people, where at least in theory somebody, somewhere remembers why.
An acquisition is different, and I think also meaner. It’s the Amber Trap handed to you pre-loaded and sight-unseen. You inherit 10 years of “we built it that way for a reason that made sense at the time”, except the reason, and the people who lived it are being actively paid to leave. The earn-out and the retention package are, in my plain terms, a countdown timer on your only real understanding of why.
In my experience the diligence runs on a clock measured in weeks. But the actual understanding you actually need is measured in months or even years. It is usually not in the repo, or on Confluence or SharePoint. It lives in maybe 3 or 4 heads, and a couple of weeks of data-room access will not pull out what took a decade to accumulate.
The folklore, the near-misses, the “never touch that batch job on the 28th” that is the difference between a system that runs and one that runs you. And the first time that system falls over at 2am, the engineer who inherited it learns the operational runbook was a person, and that person walked out.
So the price gets set against the thing you can see (the tech, the customers, the revenue) and almost never against the thing that will actually hurt you, the comprehension that is about to resign. In debt terms you’ve just taken on a huge, somewhat documented liability and booked it. On the slide it probably looks like a koopje.
You can lead a horse to water…
Companies get bought, it’s how the market operates and a lot of good technology finds a bigger home, and sometimes the messy inherited system is genuinely worth it. My point is smaller, and I think more useful. The risk that should move the price is comprehension. Integration effort you can plan and staff.
If you’re a CTO running the technical diligence, the thing most likely to blow up your synergy case is sitting in the HR file, not the codebase. It’s the handful of people who are the only living copy of why the thing works, and whether anyone made a plan to keep them. So, my take is that when you see the architecture diagram in the data room, don’t just read it, ask who drew it. Then check whether that person is on the retention list, and for how long.
The animals on our farm get fed whether or not I fully understand them, and a system is no different. You bought the horse, so find out fast which fence it leans on, and what the good approach route is (ever been kicked?).
Leave a Reply