Zachary Fouts

I work on the technical side of M&A: the acquisitions where nobody knows how the tech stacks will fit together, the divestitures where shared infrastructure has to be cleanly separated under tight timelines.

I’ve been doing some version of this for a long time. In ‘97 I was getting pulled out of class to fix the principal’s computer and was the first student in my elementary school to get internet time during lunch. By 16 I was running my own gig: web hosting, VPNs, fixing whatever small businesses needed fixed. The problems have gotten bigger, but the approach hasn’t changed: understand the landscape, find the risks, build a plan, execute without burning the place down.

The Path Here

I didn’t plan to end up here. Nobody does. I spent years as a generalist: building cloud infrastructure, writing Go and Python, designing APIs, running Kubernetes clusters, automating everything I could get my hands on. I got pulled into my first acquisition because I happened to know how a lot of the systems connected together.

Turns out, that’s what the work needs when you’re merging two companies or pulling one apart. Someone willing to zoom out far enough to see the whole landscape and zoom in deep enough to understand why that one legacy service can’t just be “turned off.”

One integration became two. Then came a divestiture that was harder than any acquisition. Now it’s what I do.

Where I’m Coming From

I’ve sat on different sides of the table. Acquiring company’s architect evaluating targets. Acquired company’s engineer wondering what happens next. The one tasked with separating shared infrastructure under a hard deadline. Each of those seats taught me something the others couldn’t.

Reality over slide decks. Due diligence isn’t about producing a pretty report. It’s about finding the things that will cost you millions if you miss them. Hidden technical debt. Licensing landmines. The single engineer who holds six critical systems in their head and nowhere else.

I think about the humans. Every migration ticket represents someone’s workflow changing. Divestitures are especially hard: you’re asking people to untangle systems they spent years building, often under real uncertainty about their own futures. I approach that with empathy and with a plan.

On Leading People

The part of this work I care about most isn’t the architecture, it’s the people. I care a lot about leadership, but not the “command and control” kind. What I try to do is partner with the people around me and help them do their best work. The best outcomes I’ve been part of weren’t because I had the right answer. They happened because the right people found it together.

How I Operate

Clarity over comfort. If the integration timeline is unrealistic, I’ll say so. If the divestiture requires 18 months and the business wants 6, you’ll know on day one.

Systems thinking. Technology doesn’t exist in isolation. Every architecture decision ripples through teams, budgets, timelines, and culture. I map those ripples before making recommendations.

Ship, then iterate. There’s no single playbook. Sometimes you integrate the stacks that exist; sometimes rebuilding is the cleanest path (rebuild, migrate, deprecate); in a divestiture you might rebuild what you’re keeping and hand over the rest. The bias is figuring out the right approach for the deal, getting it stable, then optimizing. Chasing perfection during a transaction is how you never finish.

Minimize blast radius. Especially in divestitures, the goal isn’t elegance, it’s reducing risk. I build rollback paths and make sure no single cutover can take down both sides.