Technology Is Rented. The Team Is the Asset.
I helped a bank grow from $4B to $20B in assets. The tools we started with are mostly gone now — the warehouse, the reporting platforms, the on-prem stack. What survived every change was the organization. Here's what that taught me about building a data function that outlasts the technology it runs on.
I joined a bank when it had about $4B in assets. By the time I moved on, it was $20B — grown through a mix of organic expansion and a steady run of mergers. The data and analytics organization had to grow just as fast, and absorb an acquired company’s data environment every time we did a deal.
Living through that kind of scaling teaches you something the org charts don’t. The technology you’re so proud of on day one is temporary. The warehouse gets replaced. Reporting platforms come and go. You migrate to the cloud. What carries the capability across all of it — the thing that’s still standing after every migration — is the organization you built. Technology is rented. The team is the asset.
Here’s what I’d tell anyone scaling a data function through that kind of change.
1. Hire for judgment, not tools
The most common hiring mistake I see is optimizing for the current stack. You need someone who knows the tool you use today, so you hire for that — and in three years the tool is gone and so is the reason you hired them.
The stack you hire someone for will be dated fast. The ability to reason about data, ask the right question of an ambiguous business problem, and earn the trust of the people who depend on the answer — that doesn’t expire. I optimized for the second, every time. You can teach a strong thinker a new platform in a quarter. You can’t teach platform expertise to become judgment.
2. Governance is a culture, not a document
Every governance program starts with the temptation to write the policy — the standards document, the data dictionary, the stewardship charter. Those matter, but they’re not what makes data trustworthy. You cannot police quality into an organization from a binder.
What worked was making stewardship something people owned rather than something compliance enforced. When the people closest to the data felt accountable for it — its definitions, its quality, its lineage — trust followed. And that ownership is exactly what made each merger survivable: acquired data didn’t just get migrated onto our platform, it got genuinely integrated, because we had people whose job was to understand what it meant and vouch for it. Governance as a document is a cost. Governance as a culture is what lets you absorb change without losing the plot.
3. Build for the merger you haven’t announced yet
When you integrate acquisitions repeatedly, something shifts in how you design. You stop treating change as an exception — a project with a start and an end — and start treating it as the normal operating condition.
That changes the architecture (loosely coupled, standardized interfaces, as few hard dependencies as you can manage) and it changes how the teams work (documented, repeatable onboarding of new data domains, not heroics). We got to a point where a new acquisition wasn’t a crisis; it was a runbook. Flexibility became the default posture, not a special effort. If you only ever build for the systems you have today, the next deal breaks you. If you build for the deal you haven’t announced yet, the next one is just Tuesday.
4. Earn trust in the business, not the platform
This is the one technical leaders get wrong most often. Confidence in data isn’t won in the data platform. It’s won in the room where the business actually makes decisions.
The teams that spent time in those rooms — understanding what the line of business was trying to do, what a number meant to the person using it, where the last report had burned them — delivered far more than the teams that stayed close to the technology and waited for requirements. Trust is a relationship, and relationships aren’t built through a ticketing system. The best data people I’ve worked with were as comfortable in a business review as they were in a design session. That’s not a soft skill; it’s the skill.
5. The capability lives in people
We changed warehouses. We changed reporting tools. We moved to the cloud. Across every one of those transitions, the thing that carried the organization’s data capability forward was not any platform — it was the people who understood the business, owned the standards, and had earned the trust to be believed.
That’s the reframe I’d leave any leader with. When you invest in a data organization, it’s tempting to measure the investment in tools and platforms, because those have price tags and demos. But the platforms are rented; you’ll replace them. The durable asset — the one that compounds, survives the migrations, and actually determines whether your data and AI ambitions come true — is the team.
The part underneath
Scaling a company 5x looks like a technology story on the surface. New systems, bigger platforms, a cloud migration, more data than ever. Underneath, it’s an organizational one: the standards you set, the ownership you cultivated, the trust you earned, and the people you kept growing.
That’s the part I’d build the same way again — and the part I’d tell anyone standing at the front of a fast-scaling data or AI function to protect first. The technology will change out from under you. Build the team that can carry the capability through it.
Building this capability inside your organization?
I write about enterprise AI, data governance, and turning data into value in regulated industries. If you're working through the same problems, I'd welcome the conversation.
Get in touch →