July 15, 2026

Early in my career, I ran Sapient's mobile + retail Center of Excellence. The title sounds grander than the work. In practice, a CoE exists for one reason: so the tenth team doesn't rebuild what the first team already solved. What I learned running one is that the value was never in the documentation. Nobody reads the wiki. The value was in the patterns. The handful of hard-won decisions about architecture, data, and delivery that showed up again and again across different clients. A retail rollout and a mobile launch looked nothing alike on the surface. Underneath, the same three or four problems kept repeating. Once you can name the pattern, you stop treating every engagement like a blank page. That's the same thing I do now, just across more industries. Financial services, retail, QSR, hospitality. Different language on top, familiar architecture underneath. The pattern recognition compounds. A Center of Excellence was just an early, formal way of forcing that compounding to happen on purpose, instead of hoping it happened by accident. Where does your organization actually capture the patterns worth reusing? Or does every team quietly start over?

For years at POSSIBLE / Wunderman Thompson Apps, the teams I led built apps for live sports and media. Turner Sports, NBA, PGA TOUR, the Olympic Channel. Here's what building for live events teaches you that a normal product never does: The peak moment is the whole product. Nobody remembers whether your app felt fast on a random Tuesday. They remember whether it held during the final round, the buzzer-beater, the opening ceremony. The exact moment a few million people all open it at once. And when something broke in those moments, it was almost never the thing on the screen. It was the layer underneath. The data feed that couldn't keep up. The service that wasn't built to absorb a spike. The integration that worked fine at 1x and folded at 100x. The UI got all the attention in the review. The architecture underneath decided whether we made it through. The same pattern plays out in every industry I work in now. QSR at the lunch rush. A retailer on a launch day. A financial firm at market open. Everyone wants to polish the surface. The moment that actually matters is a load problem, not a design problem. Where does your peak moment live, and is the layer underneath built for it?

Twice in my career I've helped fold an acquired company into a larger one. At Sapient, I helped integrate the Nitro acquisition. Years later at Goods & Services, I assisted a near-shore merger. Both times taught me the same thing: the deal closing is the easy part. Everyone celebrates the announcement. The org chart gets redrawn. The press release goes out. Then the next morning you have two companies sharing a logo but not a way of working. Different systems. Different definitions of "done." Different data sitting in different places. The synergy that lived in the deck lives entirely in the architecture underneath. I see the same pattern now in QSR. A PE-backed platform buys three brands, and suddenly there are three POS systems, three loyalty programs, and three sets of customer data that don't talk to each other. The growth model assumes one connected guest. The tech stack assumes three separate ones. Closing the gap isn't a rebrand or a new app. It's the unglamorous work of unifying the layer beneath, so the combined company can actually behave like one. For those who've been through a roll-up or an acquisition: what surprised you most about the work that started after the deal closed?

Something I keep noticing about growing existing accounts: the ones that expand into AI aren't the ones with the biggest budgets. They're the ones where the earlier work left a clean data layer behind. Most teams treat the next capability as a separate decision. New evaluation. New business case. Sometimes a fresh bake-off, as if the last two years of relationship never happened. But AI doesn't expand an account. The data foundation does. Where the common data layer under the account is sound, adding AI is a short conversation. Where it isn't, you spend the first few months cleaning up before anything actually works. I watch this play out. Data + AI is the expansion offer I'm actively pushing inside existing accounts, and it moves fastest exactly where the groundwork was already done, and stalls where it wasn't. Which means the real expansion decision usually got made two projects earlier, when someone chose whether to architect the data properly or ship the feature and move on. Are you treating your data foundation as the thing that unlocks what comes next, or just the thing under the current project?

A few years back I stood up eCommerce delivery for a global brand running on Adobe, with unified delivery across North America, England, Germany, India. Same platform in every market. One stack, one codebase. I assumed the hard part would be the technology. It wasn't. The hard part was that "unified" isn't a codebase word. It's an operating-model word. Each region had its own catalog. Its own data. Its own idea of how checkout should work and who signed off on it. You can deploy the exact same platform in four countries and still end up running four different eCommerce businesses, because the process and the data layer underneath were never actually connected. That's the part nobody scopes. In the RFP, the platform decision gets all the attention. The data and process unification gets almost none, and that's where the thing lives or dies. The same pattern shows up in every industry I work in now. Financial services, retail, QSR. Leaders point at "one system" and assume alignment follows. The system is the easy part. Unifying software is simple next to unifying how people work and how data moves across borders. If you're running one platform across multiple markets, how are you handling the data and process underneath, not just the deployment?