Part II of The Art of Data War — Knowing Your Position, PRAISE Framework. Previously:

Every firm will meet a shock it did not choose. How it comes through was settled long before, in calm years, by what it built while nobody was asking for it. A firm built for change absorbs the shock, and gains the ground its competitors lose while they rebuild.

Adaptation & Resilience, the Evolve dimension of PRAISE, addresses whether your organization and data infrastructure can withstand external shocks and adapt to forces beyond your control. You’ve prioritized data strategically, resourced it with talent, accounted for what you have, integrated it into business operations, and stabilized systems to run reliably. All that internal discipline still has to evolve when technological disruption obsoletes your competitive advantages, when regulatory shifts demand a new architecture, or when market dynamics put pressure on your viable economics.

BlackRock — Aladdin built in calm and for advantage

BlackRock’s founders bet that complexity would overwhelm fragmented systems. The 1987 crash exposed Wall Street’s inability to coordinate during rapid market moves: portfolio insurance and program trading created cascading failures when disconnected tools couldn’t keep pace. BlackRock saw the integration tax: firms stitching together best-of-breed vendors spent enormous effort on manual reconciliation. They also bet that platform economics would favor unified infrastructure. Starting 1988, they built Aladdin internally, a contrarian choice when vendor solutions seemed safer. The 2008 crisis tested the bet. The New York Fed hired BlackRock to manage the assets it took on from Bear Stearns in March, and then the AIG portfolios, which Fed-funded vehicles bought at prices based on BlackRock’s own valuations. By 2025 BlackRock was earning $2.0 billion a year from technology services and subscriptions, most of it from Aladdin.

BlackRock built Aladdin from modular systems and common data semantics that could expand across asset classes without expensive rewrites. The platform started with fixed income in 1988, then absorbed equities, derivatives, real estate, and alternatives as markets evolved, adding some of them through software it bought and folded in, such as an equity system in 2008. When regulatory shifts arrived, from Basel requirements to Dodd-Frank reporting mandates and MiFID II transaction reporting, the modular design was built to absorb new compliance obligations through configuration rather than reconstruction.

Building in-house kept vendor dependencies few. While competitors relied on third-party risk systems that could disappear through acquisition or obsolescence, BlackRock had the scale and the focus to own its own destiny, which few firms have. Aladdin still draws its data from many sources, exchanges, brokers and custodians among them, and BlackRock’s own annual report lists its dependence on third-party data and cloud providers as a risk to Aladdin’s resilience. By 2013, about $15 trillion of assets ran on Aladdin, among them those of direct competitors who pay BlackRock for access. The platform maintains 98% client retention rates precisely because switching costs are prohibitive.

The Signals to Look For

Read the case back and it shows three things. BlackRock saw the change coming, which bought it time to build. It built so that new asset classes and new rules arrived without major infrastructure resets. And it kept its dependencies few, the narrow case of adapting, where the change is a loss. The signals below look for each in your firm.

1. Are technological and competitive threats seen coming, before they obsolete an advantage?

What to look for: Does your firm watch the outside world on purpose, through research firms, brokers, venture capitalists, startups and candidates? Does what it learns reach someone with the budget and the mandate to act on it? Is what it builds today made to be monitored, measured and replaced?

Are you watching the horizon, or staring at your feet? Sometimes the status quo seems stable for years, but somewhere, someone is working on the next major thing that will reshuffle the market, dethroning established players or creating new winners. Disruption emerges quietly in research labs, competitor roadmaps, or adjacent industries until suddenly it’s unavoidable. The test came when ChatGPT launched in November 2022: some organizations went into panic mode, scrambling to understand what it meant, while others were already preparing product launches and offering AI consulting to clients. Morgan Stanley was one of them: its wealth management arm had been building on OpenAI’s models since 2022 and announced an assistant for its advisors on GPT-4’s launch day in March 2023. The work had started while nobody was asking for it.

Disruption comes from multiple directions. Technology shifts fundamentally alter what’s possible. Quantum Machine Learning holds immense disruptive potential for data and prediction: it promises to automate the discovery of complex data relationships, shifting the focus away from manual feature engineering as a legacy methodology. Vendor changes create sudden advantages. By 2017, satellite providers were estimating oil inventories from space, and funds using the data had each week’s estimate hours before the government published its own figure. Competitive moves force response. Market makers continuously enhance predictive models to quote microseconds faster, dominating order flow and forcing rivals to match their infrastructure investments or cede ground. Each advancement resets the baseline—yesterday’s cutting edge becomes tomorrow’s table stakes.

A firm stays ahead by building deliberate organizational antennae. Research firms like Gartner and Forrester track emerging technology trends and investment patterns. Brokers and market facilitators bring competitive intelligence to their clients. Interviews and meetings with venture capitalists and startups reveal what’s being funded and built and which cross-sector trends are applicable. Interviews with candidates are a source as well. Their achievements show what is being built elsewhere, their frustrations show where the competition stands, and their skills show which tools are being adopted.

With this information in hand, a firm needs the internal capacity to translate it into strategies, which Prioritize covered. Integrate described the need for dedicated innovation budgets: reserved personnel experimenting with emerging technologies, time allocated for exploration, partnerships with universities and research labs testing new approaches, or even strategic stakes in promising companies to learn from their innovation while capturing potential upside. These investments require clear, measurable KPIs with different lifecycles: some for short-term operational improvements or competitive adjustments, others for long-term planning for your organization’s evolution.

The pace is now set by the AI frontier labs that build the models, and anything built on today’s model can be overtaken by the next. A firm builds with confidence by building to monitor, measure and swap, like a well-run factory where any station can be refitted. Signal 2 asks whether the infrastructure is built to support this goal.

2. Can the data infrastructure adapt to regulatory shifts, technological disruption, or new data products?

What to look for: Do your technical architecture and organizational structure absorb change? When regulatory enforcement shifts, technological disruptions emerge, or new data products appear, do platform modularity and operational abstractions enable rapid adaptation without requiring heroic effort or a complete re-platformization?

A new rule shows quickly whether a firm can adapt. When Dodd-Frank passed in July 2010, financial institutions faced 243 new rulemakings, by Davis Polk’s count, with implementation timelines measured in months. Meeting them was expensive and slow for every bank, and slowest for the ones whose data lived in silos. Goldman Sachs had run SecDB since the 1990s, aggregating risk across the whole firm on one platform. A firm with that kind of unified semantic layer could turn the new rules into manageable reconfiguration. Firms trapped in fragmented silos met them by hand. Without standardized data schemas, matching positions required an army of manual reconciliations every quarter. The consequences were public: major financial institutions failed stress tests by falling below capital minimums, while others received qualitative objections for deficient risk management processes.

Technology shifts test the same thing. Over the decade after 2008, cloud migration shifted from experiment to competitive necessity. Firms with decoupled modules and microservices migrated components incrementally, phasing storage, compute, and data pipelines into elastic environments without halting operations. They gained autoscaling, eliminated hardware management overhead, and tapped into new cloud-native services while competitors were deterred by misunderstood risks and unclear ROI. Monolithic applications faced a rigid “all-or-nothing” migration path. Analysis paralysis over deeply coupled dependencies often didn’t find motivated owners. The executives who would have owned the move were intimidated by the load of anti-migration complaints and by the political and technical work, and the paralysis ultimately justified staying put, a choice that would haunt those firms a decade later. Organizations that delayed migration now face a compound choice of rebuilding their legacy applications while simultaneously adopting AI capabilities, and the gap to the firms that moved widens every year.

A new kind of data tests it a third way. When healthcare alternative data reached the investment market, HIPAA and GDPR made on-premises storage a significant compliance bottleneck. Firms with modern architectures bypassed this through data clean rooms on outside platforms like Snowflake and AWS. They analyzed sensitive datasets inside the clean room, a compliant third-party environment, without ever “taking possession” of the raw files, which eliminated the need for local egress and complex de-identification pipelines. Many firms, unable to build the necessary guardrails in time, simply abandoned data that could have made them money, ceding alpha to competitors.

3. Are there contingency plans for the vendors, data sources, and platforms the firm depends on?

What to look for: Do you have single-source dependencies on critical external data, undocumented assumptions in models, release-timing fragility, or teams unable to operate without specific feeds? Is there evidence of redundancy: alternative providers, proxy signals, scenario modeling, and processes designed to continue decision-making when primary data disappears?

LSEG completed its purchase of Refinitiv in January 2021, in an all-share deal that valued Refinitiv, debt included, at about $27 billion. Clients on the front line witnessed aggressive commercial escalation. Renewal negotiations turned combative, with unprecedented price increases justified by original deep discounting strategies that now felt like traps. There were early signs of the trouble ahead, visible to any client before the deal: legacy products like IBES, StarMine, and Lipper, acquired by Reuters and Thomson over the years, were never properly “digested” and operated in expensive silos. Tick History, the tick data service, stopped innovating, losing ground in a commoditized space to more nimble operators. Recurring “strategic” API migration mandates had already created client fatigue and frustration. In response, hedge funds with dual sourcing, pulling tick data directly from exchanges or alternative aggregators, maintained leverage and could walk away. Similarly, firms using abstraction layers were able to replace LSEG without disrupting downstream users. Firms that depended on LSEG’s proprietary datasets and had no contingency plan were left to choose between absorbing unsustainable costs and decommissioning strategies entirely.

Cloud adoption brings lightweight operation, ROI efficiency, and speed of innovation. But cloud engineering brings its own risks, and availability is the one most firms underestimate. While cloud services advertise 99.5% to 99.99% uptime, the remainder can arrive at the worst possible moment. Multi-region and hybrid architectures, data replication strategies, and chaos engineering often sound like ambitious over-engineering during calm periods. Then a crisis strikes. On December 7, 2021, a networking impairment in AWS US-EAST-1 took down the controls customers use to launch servers and change their DNS, during US market hours, and investment firms whose operations or failover needed those controls lost trading capacity. Market positions went stale, alpha opportunities evaporated, and service credits couldn’t recover lost revenue. The organizational dynamics followed a predictable pattern: business leadership escalated to technology, demanding explanations for the outage. Some technology leadership escalated to cloud vendor management, demanding accountability—some of it deserved. But others turned the lens inward: the shelved availability engineering projects became top priorities.

Macroeconomic visibility across industries rests on a surprisingly small set of government statistical pipelines. In the United States, indicators such as employment, inflation, retail sales, and GDP originate from agencies like the U.S. Bureau of Labor Statistics, the Census Bureau, and the Bureau of Economic Analysis. During the federal government shutdown of October 2013, these pipelines stalled. Surveys were suspended, collection stopped for sixteen days, and releases were delayed. Economists, corporate planners, and policy analysts navigated the economy with partial instruments: models calibrated on indicators that were no longer updating, on the assumption that the government’s numbers would always arrive. The disruption exposed a divide between organizations treating macro data as a single authoritative feed and those that built redundancy into their economic intelligence. Institutions with alternative indicators, such as payroll processor data, rail and freight activity, and regional Federal Reserve business surveys, continued producing internal nowcasts. Others waited for Washington to reopen, and lost the informational edge to competitors still measuring the economy in real time.

Now read your own organization. Who saw the last big shift coming, and through which channel? Did the last new rule, technology or kind of data land without a major infrastructure reset? Which data source, vendor or platform could you lose tomorrow, and what would you run on instead?

Part II of The Art of Data War — Knowing Your Position, PRAISE Framework. Previously:

Most firms trust their data because they trust the engineers who built it. When a pipeline breaks, the person who wrote it fixes it, and for a while that works. You’ve made data a leadership priority, built the teams to carry it, accounted for what you have and who uses it, and put it to work in business decisions. But none of that matters if your systems break under load, quality issues go undetected until they corrupt decisions, or your best engineers burn out responding to the same failures repeatedly. This is where many organizations discover their Achilles’ heel: data platforms held together by heroic individuals rather than systematic processes. A few people cannot grow as fast as the business, and growth is where that shows. What holds is a system: pipelines built to one standard so that anyone can run them, quality checked before a decision depends on it, and an operations team that keeps the lights on 24 X 7.

Operations & Reliability, the Stabilize dimension of PRAISE, addresses whether your data infrastructure can sustain growth without constant firefighting: whether it operates reliably at scale, catches problems before they cascade, and frees your talented teams to innovate rather than firefight.

Uber — From Wild West to Systematic Scale

By 2025 Uber’s data platform served about 189 million active customers and more than 7 million active drivers across more than 15,000 cities in over 70 countries, and held some 350 petabytes of data. During its early years of rapid growth that data infrastructure was built team by team: silos grew out of necessity, quality came with no guarantee, and the company hit a reliability wall.

During Uber’s early growth, the company onboarded overlapping data workflow systems: Apache Oozie, Airflow, Jenkins, custom Python and Clojure scripts. Users chose from several tools for each use case. While this allowed agile growth, engineers had to learn several systems that did the same job, and every one of them had to be maintained, debugged and taught to its users. This is how custom solutions become tribal knowledge concentrated in individuals. In 2017 it led to Piper, Uber’s centralized data orchestration system built on Apache Airflow but re-architected for Uber’s scale. Piper replaced the wild west with unified standards managed by a dedicated team. By December 2023 it supported 1,000 teams and 200,000 active pipelines.

Uber built integrated systems to catch quality issues proactively, before the data is consumed downstream. Databook, which began as a set of static catalogue pages, was rebuilt around a metadata graph. The Unified Data Quality platform (UDQ) auto-generates standard quality tests from each dataset’s metadata and shows the results in Databook. By 2021 it supported over 2,000 critical datasets and had detected around 90% of data quality incidents. Schema changes are reviewed and signed off before they are deployed. The checks did not catch everything: a fares data incident affecting ML models went undetected for 45 days. Uber answered with D3, a framework that automates anomaly detection across more than 300 of its most critical datasets, and reports that average time-to-detection fell to 2 days, more than a twentyfold improvement.

Uber started Site Reliability Engineering in 2014, when the load on its systems was outgrowing an engineering organization that doubled every six months. For its big-data jobs the company built DataCentral, which gives granular performance insights and automatically surfaces error messages with root cause suggestions, so that the owner of a failing job is told what went wrong and what to try. Tools like this rest on standardized telemetry that describes the state of the plant, the platform as it runs day to day, across thousands of datasets.

The Signals to Look For

Read the case back and it shows three things, in order. Piper put Uber’s pipelines on one standard. UDQ and D3 were built to check quality before a decision depends on it. DataCentral reads the error when a job fails and tells its operator what went wrong and what to try. The scale is Uber’s. The three things are what the signals below look for in your own organization.

1. Are pipelines built to one standard, so that anyone can run and repair them?

What to look for: Do your data flows run through a central platform, automated and standardized, not through ad hoc processes each team keeps to itself? Is manual work the exception? Does a new dataset follow a proven pattern, stored, accessed, versioned and monitored like every other? When a pipeline fails, can someone who did not build it find the fault and fix it?

A central data platform is a set of capabilities managed through common governance, automation, and standards while remaining open for usage and access. It does not have to be a single technology, or a single team controlling everything. The platform carries each dataset through its full lifecycle, from acquisition to distribution, and automation speeds mundane tasks like onboarding new datasets or setting up distribution channels. Standardization, in how data is stored, accessed, versioned, and monitored, makes management simpler without requiring institutional knowledge per dataset. It is what brings a new dataset in within hours, where a custom pipeline takes weeks. Imagine creating custom pipelines for hundreds or thousands of datasets versus following proven patterns. Standardized telemetry is also what lets AI take part in operations: a model can watch and act on thousands of pipelines only when they all report their state the same way.

Without a central platform, teams build custom solutions for every need. This problem commonly emerges in systematic hedge funds with engineering powerhouses. Each engineer tends to own the pipelines they brought in, so every pipeline has one owner. Solutions become tribal knowledge concentrated in individuals who become indispensable heroes. When these people leave, their systems become black boxes. Teams spend the lion’s share of their time on plumbing: acquiring, cleaning, and storing data, with little left for analysis. The organization accumulates technical debt faster than it can pay it down.

These custom solutions create cascading problems. Onboarding new datasets takes weeks instead of hours. Maintaining hundreds of custom pipelines becomes impossible: systems drift, break silently, or run indefinitely without anyone knowing if they’re still needed.

2. Are datasets qualified before a decision depends on them?

What to look for: Do automated quality checks catch issues before data reaches consumers, not in a post-mortem? Do datasets arrive complete per SLA before critical business moments? Does lineage tracking document each dataset’s sources, transformations and versions, so that a root cause can be found and a result reproduced? Are historical versions preserved for audit and post-decision analysis, so that an audit is routine and not a panic? Is quality logic transparent and crowd-sourced from users who understand their use cases?

Central platforms aren’t just about consolidation—they’re built to govern quality and distribution at scale with minimum effort. Datasets delivered without qualification pose risks to downstream consumers who discover issues too late. Quality check logic must be transparent to users, who know best what works for their use cases. The best rules come from two sources. Where datasets are recorded the same way, AI can draft a new one’s automated checks from similar datasets and from how the data is used. The people who use the data add what they know of their own downstream requirements. Understanding the original data product matters too: what inherent issues or characteristics does the source data carry? This is where the catalog from Account becomes critical: profiling and data representation reveal source data patterns, anomalies, and limitations that inform what quality checks and enrichments make sense downstream.

Two numbers show whether this is working: the share of quality incidents your own checks catch, and how long a bad dataset goes unnoticed. Quality isn’t just accuracy—it’s timeliness. Latency monitors track dataset arrival and completeness against SLAs. When critical feeds run late, alerts escalate before business impact: traders need overnight positions before the market opens, retailers need inventory before launching promotions.

Lineage isn’t a fancy term—it’s documenting the complete lifecycle of every data point from original sources through transformations to final consumers. Without lineage that tracks both data sources and generation logic, each under version control, tracing issues or evaluating existing datasets becomes impossible. When metrics suddenly shift, lineage reveals whether source data changed or transformation logic evolved. Auditors and regulators ask a firm to reproduce a result on the data it had at that moment. Datasets get restated as normal business: vendors correct errors, companies revise earnings. Maintaining original versions in a bi-temporal setting matters for regulatory audits and understanding decision quality: what did we know when we acted, versus what we learned later?

3. Is there a dedicated DataOps function maintaining trust 24 X 7?

What to look for: Is there a dedicated DataOps function with clear escalation protocols, where first responders have the tools to diagnose and intervene before escalating to data owners or infrastructure teams? Does standardized telemetry across all datasets enable normalized monitoring regardless of type, frequency, or size? Is incident response systematic, with root cause analysis and prevention, not heroic firefighting and reactive scrambling when issues surface?

Imagine software development without DevOps or application support: engineers writing code and personally responding to every production incident at 3 AM, no systematic deployment processes, no monitoring tools, no escalation protocols. Talented developers would flee to saner environments. Their expertise would be wasted on repetitive troubleshooting instead of building new capabilities. This is exactly what happens in data organizations without dedicated DataOps functions. Brilliant data scientists and engineers leave jobs because fire drills and 24 X 7 support consume their careers. The cost reaches the business too. One owner per pipeline cannot respond in time, and portfolio managers end up running models on late or broken data, in the worst cases at a loss. They chase a data team that does not answer, and the team’s standing falls with every incident. Engineers under that pressure onboard new datasets with the minimum of checks, which produces the next failure. DataOps provide systematic operational support far cheaper than expensive specialized talent wasted on firefighting, ensuring the plant runs healthy while both data owners and DataOps teams innovate in their respective domains.

Effective DataOps run on three or more tiers of support. In a common setup DataOps teams are the first responders, data owners are the second-level specialists, and behind them sit the platform and infrastructure specialists. DataOps teams need power and tools: health dashboards, drill-down interfaces, automated remediation for common issues, clear runbooks for intervention before reaching specialized knowledge. Where the pipelines look alike and the platform gives operators those tools, the first tier can be entrusted to existing support groups that are already watching trading systems around the clock. When DataOps can resolve 70-80% of issues without waking data owners, engineers stay focused and the organization scales without scaling headcount proportionally

The control room, and the three tiers of support behind it.

The central platform and automated quality checks from the earlier signals are prerequisites for scalable DataOps. Without them, operational support becomes impossible at scale. Innovation in DataOps emerges from systematic protocols built on this foundation. Automated SLA monitoring generates alerts when datasets run late or fail quality checks, triggering immediate investigation. Standardized telemetry and operational metadata describe plant state across thousands of datasets regardless of type, frequency, or size. This normalization lets monitoring and intervention tools work uniformly: the same dashboard shows batch equity data, real-time market feeds, and alternative web-scraped datasets. Without standardization, DataOps teams drown in bespoke monitoring systems, each requiring specialized knowledge. The same standardization lets AI take the first look. It can find the likely cause of a failure, propose the known fix, and enable the incident communication to vendors, specialists and users. There is art in making the whole ecosystem work together and for each other.

Now read your own organization. Are your pipelines built to a standard anyone can pick up? Is your data qualified before the decision is made? When a pipeline fails at 3 AM, is answering it someone’s job? Three yeses mean your data holds because of a system. Three noes mean it holds because of a few people, and a few people cannot grow as fast as the business. Start with the standard, then the checks, then the team: each depends on the one before.

Part II of The Art of Data War — Knowing Your Position, PRAISE Framework. Previously:

A firm can have data teams, dashboards, a data budget and a seat for its CDO, and still be running around its data rather than on it. The decisions that matter get made, and the analysis arrives afterward to support them. The data bill is paid centrally, so nobody asks what any dataset returns against what it costs. Each new team builds the stack it needs, and the firm carries the cost of building the same thing again. his dimension asks three questions: are business decisions data-led, are data assets managed for their value, and do platform returns compound across the business?

Business Enablement, the Integrate dimension of PRAISE, assesses whether data is woven into the organization’s DNA: embedded across the business in how decisions are made, strategies are formed, and value is created. Organizations with strong integration generate strategies from data, not just validate them. Data teams participate where questions are formed, not where they’re answered. Business units connect their data investment to business outcomes and hold their data assets accountable for returns, not just delivery. Without shared standards and unified capabilities, effort gets duplicated across departments rather than compounding into platform advantage that scales across the organization.

Netflix — Running on data from the start

Marc Randolph and Reed Hastings founded Netflix in 1997 and put it online the following year, and from the first rental the company tracked every search, rating and return. Blockbuster, renting the same films from nine thousand stores, could not see any of it. That advantage guided the 2007 streaming launch: while competitors dismissed internet video as premature, Netflix’s behavioral data showed customers would abandon DVDs for convenience. By 2012, recommendations drove roughly three-quarters of what subscribers watched, turning user behavior into decisions the business made at scale.

Netflix held its data organization accountable for measurable returns. The recommendation engine delivered over $1 billion a year in retention value, keeping subscribers engaged and churn among the lowest in the industry. But Netflix tracked costs just as rigorously. Data showed what streaming cost per view and where it could fall, so the company built Open Connect, its own delivery network, placing caching servers inside internet providers’ own networks. It completed a seven-year migration to the cloud in 2016, and its engineers reported cloud costs per streaming start “a fraction of those in the data center.” Efficiency dashboards allocated every dollar of infrastructure spending to the teams and services that incurred it, and the cleanup that followed retired tens of petabytes nobody was using.

The platform Netflix built for streaming carried it into original content. The talent arrived packaged from an outside studio. What Netflix supplied was the audience: its subscribers had already shown they watched political dramas, and they watched Fincher and Spacey. It committed $100 million to House of Cards in 2011, before a frame was shot. The show arrived in 2013 and the slate scaled behind it, each new title inheriting the infrastructure rather than rebuilding it.

A disciplined buyer is taken seriously, even with the lower offer. When Warner Bros Discovery weighed its sale, Netflix’s $83 billion offer was the lowest headline bid on the table, and the board chose it first, on value and certainty. And when Paramount’s bid climbed past what the numbers could carry, Netflix walked: the same discipline that priced a $100 million show priced an $83 billion one. Netflix had one advantage most firms did not: it started on data and never had to change course to get there.

The Signals to Look For

Read the case back and three things carried it. Netflix decided from data before the market agreed, on the launch that remade the company. It held what its data cost against what its data returned, and it knew both numbers. And it built one platform, so every new business it entered ran on what was already there. The three signals of the Integrate dimension read for exactly these, one at a time.

1. Are business decisions data-led?

What to look for: Do your decisions originate from data insights, not gut feelings justified afterward? Are data capabilities built into your regular operating rhythms: reviews, planning cycles, resource decisions? Do business units have the governance and independence to challenge leadership’s assumptions with data? Can teams get their own insights without gatekeepers, and test and iterate fast?

In investment management, sell-side analysts maintain privileged access to companies they cover, conducting management meetings and site visits that shape their research narratives. But this traditional insight channel is now complemented—and sometimes challenged—by alternative data sources that reveal what companies won’t disclose: satellite imagery tracking construction completion rates, sentiment analysis detecting shifts in earnings call tone, social media signals predicting consumer behavior. Advanced analytical tools democratized what used to require exclusive relationships. Research teams that built alternative data into their own research set themselves apart: their analysts went into management meetings already holding a view, and their clients got sharper insight. The firms gaining competitive advantage are those embedding analytical capabilities directly into investment workflows—using data to originate investment decisions, not simply validate them after the fact.

In data-driven organizations, data capabilities are embedded in regular operational rhythms: automated decisioning for routine choices, real-time dashboards powering recurring reviews, analytics frameworks guiding planning cycles. In these organizations, business units are empowered to make decisions independently using defined data governance, challenging assumptions from leadership with evidence. Beyond supporting decisions, embedded data capabilities systematically trace performance and generate new opportunities: identifying underserved customer segments, detecting operational inefficiencies, surfacing market shifts before competitors notice. Teams self-serve insights, enabling rapid testing and iteration, the democratized capability Resource describes.

When data comes as an afterthought, commitments are made first and data teams are asked to validate decisions already made. Numbers get cherry-picked to support predetermined narratives. When a marketing campaign underperforms, leadership moves to the next initiative without understanding what failed. Data professionals become order-takers—producing reports nobody questions or acts upon. Analysis arrives too late to influence strategy, serving only to document choices already in motion. Business units lack self-service access, waiting days or weeks for centralized teams to produce insights. By the time analysis arrives, the opportunity has passed or the mistake has compounded.

2. Are data assets managed for their value?

What to look for: Do your data investments show clear business returns? Can you see what each data asset costs and what it earns? Do chargeback or P&L models make those costs visible, so high-value assets get priority and low-value ones get retired? Do you track vendor ROI well enough to renegotiate or walk away from underperforming products? Do R&D budgets keep exploratory work apart from production, with the business involved so each initiative graduates to operations, gets sunset, or delivers strategic learning?

The Account dimension covered seeing what data assets cost and what they are worth. But tracking alone doesn’t drive discipline. Mature firms embed ROI discipline directly into business decisions: which data assets to license or build, which platforms to develop and manage, which business lines to continue or sunset, and where to invest next. Many choose to treat data services as P&L centers, where business units “pay” for what they consume. Both chargeback and direct pricing models make storage, compute and data asset costs visible, forcing conscious trade-offs. How those models are built is the Value Framework’s subject, later in the book. Business units carry the cost, which keeps them lean and competitive, and the data organization is free to put its time and investment into the capabilities that matter. Data stops being hidden corporate overhead and becomes part of the true cost of doing business.

ROI visibility gives negotiation leverage with data vendors, who price opportunistically when they don’t know the value their data creates. Global financial market data spending crossed $30 billion for the first time in 2018 and reached $49 billion by 2025, a surge of over 60% as the uses for market data multiplied. Without clear ROI tracking, firms couldn’t distinguish high-value feeds from noise, and bloated budgets funded vendor growth rather than selective buying. As the Account dimension showed, firms that track returns can renegotiate contracts, walk away from underperforming feeds, or reallocate budgets to higher-return investments.

Some data investments are bets whose return comes later. Firms allocate dedicated budgets for data R&D: exploring new tools and modeling approaches to optimize operations, enable new business lines, or simply stay ahead of disruption. The wave of enterprise AI investments in 2022–2023 was a good example: many firms invested defensively, needing to understand the potential impact before competitors did, without a clear immediate return. Some R&D initiatives carry defined success criteria: fail fast or graduate to production. Others run on longer, more strategic or educational horizons, the balance of bets Prioritize describes. Either way, the business has to be involved: ensuring exploration stays grounded in real problems, learnings get translated into opportunities, and promising capabilities find their way into operations rather than remaining academic exercises.

3. Do platform returns compound across the business?

What to look for: Does the whole business run on one central platform, so every improvement lands in every business at once? Do business units share common semantic layers and platforms, not separate stacks per division? Do new teams inherit existing infrastructure without the need to build their own from scratch? Can talent move freely between units without retraining on different systems?

Successful firms make deliberate foundational investments in data and platforms aligned with their business strategy. When business units lack those investments, they develop tactical solutions to make things work, creating silos that harden over time. Management loses direct access to key metrics, and getting one view of the business becomes a manual exercise of stitching together incompatible systems. Dismantling silos later proves extraordinarily difficult—disrupting operational routines, invalidating institutional knowledge, and meeting fierce resistance from teams defending their investments. The alternative requires a common semantic layer, one set of definitions for the customers, products and positions every unit works with, plus centralized platform capabilities that units inherit rather than rebuild, avoiding duplicate spending. That layer matters more now, when firms are looking to extend their capabilities through AI. An agent put to work on the business is only as good as the shared meaning it can reason over. With that layer in place, AI brings more digested context into decisions than any analyst team could supply, and the decisions stay with the people who make them.

Beyond centralized capabilities, successful firms foster institutional transparency around existing and planned initiatives, so every unit knows what the others have built. Independent business units see what’s available and what’s coming, aligning themselves to benefit while maintaining their perspective as internal clients, judging whether capabilities serve their needs. Platform investments compound naturally: building recommendation capabilities benefits content, commerce, and customer service simultaneously rather than each funding redundant solutions. Cross-business insights emerge as teams share learnings, discovering that operational improvements in one market apply to others.

Two multi-strategy managers show what that compounding is worth. At the first, every new pod built its own stack, up to a year of work before it could trade. At the second, one platform was already there: new pods traded within months of being hired, costs were lower, and portfolio managers spent their time finding alpha. The business side ran at better odds, and spent its own time finding the next pod. The same holds true outside hedge funds. Platforms like Focus Financial let boutique wealth management firms inherit institutional scale the day they join: vendor rates a five-person firm could never negotiate alone, compliance infrastructure that takes operational overhead off the advisors so they can spend their time with clients, and investment platforms with institutional-grade capabilities. Each firm that joins adds to the buying power and the shared infrastructure every other firm draws on, which is the compounding at work.

Now read your own organization. Did the last significant decision start from the data? Can you say, for any data asset that you pay for from your P&L, what is its contribution to your top line? Does every new product, team or business line launch driven from insights and operational capabilities the firm provides? Three yeses mean the business runs on its data. Most firms will find at least one no, because unlike Netflix they have to change course to get there, and each no marks where to start. The gap to the firms already running on data compounds for as long as it stays a no.

Part II of The Art of Data War — Knowing Your Position, PRAISE Framework. Previously:

No firm decides to lose sight of its data. Very few firms treat data as a priority from the start; that is Prioritize’s territory, and it is why the problem arrives unannounced. Every team acquires its own vendors, builds its own datasets, and solves its own problem well while the firm grows. Then, at scale, data is suddenly a problem: nobody can say what the firm holds, what any of it means, or who is using it. A multi-strategy fund spends somewhere between tens and hundreds of millions of dollars a year on data, the second most expensive resource after people, and most could not produce the list. Getting the view back takes a data marketplace, under which every data asset has to earn its place, bought or built alike.

Visibility & Control, the Account dimension of PRAISE, assesses whether the organization has a clear and current view of its data landscape: what exists, what it represents, and how it’s being used. Organizations that lack visibility operate blind, making non-optimal decisions, duplicating effort, creating compliance risk, and wasting resources on data that delivers no value. Those that establish strong visibility and control can move faster, fuel innovation, govern effectively, and allocate resources where they actually matter.

Multi-Strategy Fund — Building Data Visibility at Scale

A large multi-strategy hedge fund faced a common problem as it scaled: portfolio management teams had no systematic way to discover what data already existed across the firm, and management could not tell which data assets were valuable. Teams operated in distinct pods across systematic strategies, equities long-short, and fixed income, each sourcing and processing data independently. A fund of that shape, spread across regions and asset classes, can easily hold a few hundred to a thousand datasets, and without a catalog tens of sourcing people do nothing but pass information, what we have and what to look for, while tens of engineers hand-build entitlements and manage feeds. The result was duplicated spending on licensing and effort, missed opportunities, and no institutional view of what the firm actually owned.

The firm built a centralized data catalog and teams changed how they worked with data. Each dataset was tagged with rich ontologies—sectors, asset classes, strategies—along with descriptive metadata covering collection methods, preparation workflows, and common use cases. This allowed portfolio managers to browse intelligently and compare alternative datasets before committing resources. It also connected sourcing strategy teams, licensing, and vendor management into a unified workflow, eliminating the friction that previously slowed data acquisition.

Once a dataset could be found, the next question was whether it was worth using, so the data management platform integrated dataset profiling metadata directly into the catalog. Teams could see quality metrics, completeness, historical depth, consistency, and timeliness before ever requesting access. For systematic teams especially, they could now eliminate unsuitable datasets in hours rather than spending weeks or months on manual exploration. Data lineage tracking revealed how datasets were generated and which qualification rules they passed, adding another layer of confidence.

With integrated access controls and usage analytics, the catalog became a bidirectional marketplace: data went out to serve users, and evidence of what it was worth came back to the owners. Data sourcing teams could now measure the actual value of datasets based on who used them and how often, identify synergies across pods, and negotiate renewals from strength. The people who had spent their days passing information were freed to add value: finding new sources of alpha, understanding what portfolio managers needed, and building relationships with vendors. The organization stopped treating data as infrastructure and started managing it as a strategic asset, the shift Prioritize describes. Every data asset, bought or built, now had to earn its place, and for the first time the firm could say which ones did.

The Signals to Look For

Read the case back and three things carried it. The firm could find what it had, because every dataset was described the way the business thinks. It could judge a dataset before committing resources to it, because the profiling, lineage and other important meta/operational data sat on the listing. And it could see what each dataset was used for and what it was worth, because access and usage ran through the same place. Those are the three questions to put to your own organization, in that order. How to build one is the subject of Platform as a Foundation, later in the book.

1. Do you know what data assets you have and where?

What to look for: Does your organization maintain a catalog that captures what data exists, where it lives, who owns it, what it represents, and how to access it—kept up to date as part of standard data onboarding and engineering processes? Or does discovering available data require tribal knowledge, emails to multiple teams, and luck?

The most fundamental requirement for data visibility is knowing what you have. This sounds obvious, but in practice, most organizations have no systematic answer. Data lives across cloud platforms, on-premise systems, third-party vendors, departmental databases, and individual file shares. Teams acquire datasets, create new ones, or enrich existing data independently, and no one maintains a central view.

For organizations that depend on a high number of diverse datasets for intelligence, investment firms, research institutions, sales organizations, the absence of a catalog creates severe competitive disadvantage. Some analysts are completely blocked from datasets they don’t know exist. Others have technical access to tables or files but lack context about what the data represents, its quality, or appropriate use cases, leading to misinterpretation or underutilization. Teams spend hours on calls trying to piece together what’s available. Datasets the firm built get built again: a derived dataset or a signal one desk produced is rebuilt by another because no one knows it exists, duplicating the effort and often producing two versions of different quality, and somewhere a portfolio manager is investing on the weaker one. Worst of all, teams acquire licenses for datasets the firm already owns or has a comparable alternative, wasting capital on duplicates. The impact extends to recruiting: new portfolio managers find the move less attractive when they can’t efficiently discover and access data to support their alpha research.

A data marketplace solves these problems by creating a searchable, browsable catalog of datasets described the way the business thinks. An entry describes what the data represents, the business domains it belongs to, its common use cases, and its update frequency and scope, and is tagged with ontologies—asset classes, customer segments, product lines, geographies—so users can explore intelligently. AI search now lets users find datasets by asking in plain language, matching on metadata, semantic relationships and usage patterns.

This is a different product from the catalog most firms buy. Tooling providers like Alation and Collibra offer platforms to build and manage catalogs, and their unit is the table, the column, and the schema: a technical catalog, organized around how a database is structured. Business glossaries and metadata sit on top, but the thing being catalogued is still the table. They struggle to represent data at the level business users actually think about it: coherent datasets that answer specific questions, not fragmented across dozens of tables.

Catalog freshness matters as much as coverage. A catalog is only valuable if it’s current—stale catalogs stop being trusted and stop being used. This means catalog updates must be integrated into standard data lifecycle processes, not treated as a separate responsibility. In a firm that has this, engineering teams update the catalog as part of any deployment, and sourcing teams maintain the entry as part of a license renewal. Where the catalog is a separate duty, it is already out of date.

Ownership is equally critical. Every data asset needs a clear owner. Accountability is one reason; the other is that ownership is what keeps the catalog reliable and the marketplace working. Owners are responsible for keeping metadata current, which makes the catalog trustworthy. The owner might be a business function releasing operational data—sales teams publishing end-of-day numbers, pharmaceutical research teams sharing clinical trial results. It might be a sourcing team managing vendor relationships and ensuring product details are reflected in the catalog. In some cases, external vendors serve as owners for third-party data they provide directly.

External catalog providers exist because organizations struggle to discover relevant data sources beyond their walls. Firms like Eagle Alpha and Neudata help investment organizations explore alternative datasets across the market—tracking new vendors, evaluating emerging data products, and understanding what competitors might be using. Integrating with them is valuable. But external catalogs can never fully replace internal ones. They lack knowledge of your proprietary datasets, your internal enrichment processes, your specific use cases, and the institutional context that makes data valuable in your environment.

Knowing what you have is the first question, and the marketplace answers it. The harder two follow: whether a dataset is worth using, and whether it is being used.

2. Do you know what your datasets actually represent and when they’re valuable?

What to look for: Beyond knowing datasets exist, can users assess whether a dataset is fit for their specific purpose before investing time exploring it? Can they see quality metrics, coverage, timeliness, lineage, where the dataset is available, how well it is supported, and what it costs and permits? Or does evaluation require manual exploration, conversations with data owners, and trial-and-error testing?

Discovering that a dataset exists is only the beginning. The catalog tells you where something is—assessment tells you whether it’s worth using. This is the difference between browsing Amazon product listings and actually reading the detailed descriptions, customer ratings, reviews, and comparing alternatives before you buy, where the listing is the dataset. Without integrated assessment capabilities, teams waste enormous time on datasets that turn out to be incomplete, stale, poor quality, or simply the wrong fit for their use case. What makes that assessment possible is the operational and the meta data the platform keeps on the listing.

Impactful catalogs are living systems, continuously enriched by the data management infrastructure that produces and maintains the datasets. Lineage is critical: analysts spend hours, sometimes days, tracing how they got specific values when lineage is unclear. The catalog should automatically capture and allow users to trace data sources, code versions, quality rules executed, and transformations applied. Coverage, completeness, consistency, uniqueness and validity metrics can be generated through automated profiling metadata or data quality rules wired into each dataset refresh. Timeliness becomes transparent by surfacing both processing times and SLA breaches—how often does this dataset arrive late? Channeling across downstream systems shows where the dataset actually lives, and which analytics platforms can reach it, so users know immediately whether they can access it in their preferred environment. Operational metadata also reveals the level and quality of support the dataset receives from its owners, signaling how actively it’s maintained.

The metadata the platform produces is only half of what makes a listing trustworthy. The other half comes from the users themselves: feedback, ratings, use case descriptions from people who’ve actually worked with the data. That is what makes the catalog a marketplace, and the challenge is keeping it current. Smart organizations create incentives, and the incentive is an exchange: a new dataset gets a trial period; production access is granted against a documented use case and an assessment of whether the dataset improved the results; and a failed trial is closed with the feedback that earns the next one. Users pay for access in the currency the marketplace needs most.

The marketplace surfaces pricing and compliance rules the same way. Owners can tag licensing costs, or price them dynamically, whether to allocate ownership costs across teams or to price their own services. Compliance teams flag restrictions: headcount limits, prohibited use cases, AI usage constraints, geographic limitations. This information is essential for access control gateways, but it’s equally valuable to socialize upfront so users don’t waste time exploring datasets they’re not permitted to use.

The value of this marketplace model is speed. Analysts explore more datasets because they can fail fast, assessing that something isn’t appropriate and moving on, or proceed with confidence knowing quality, coverage, and compliance align with their needs. Without this, teams spend weeks gaining access, normalizing data, and testing—only to discover at the end that the dataset won’t work. That delay kills innovation. When assessment is integrated, teams iterate faster, test more hypotheses, and spend their time on datasets that will hold.

3. Do you understand the value and ROI of your data assets?

What to look for: Can you see which data assets are actively delivering value versus sitting idle, and what each of them costs? Do you know who’s using them and for what purpose? Does this visibility surface whether usage is appropriate and compliant? Or is usage data scattered across systems and invisible?

Datasets are distributed through various channels—databases, file systems, APIs—each with their own access control mechanisms. But access shouldn’t be managed purely as a technical concern by data engineering teams. Owners or their delegates, such as sourcing teams managing vendor data, should have the levers to control permissions directly through the marketplace catalog. The catalog maintains logs of who requested access and when it was granted. Before approving access, owners verify rules and restrictions, and kick off pricing approvals if necessary. This shifts access control from infrastructure administration to business-governed processes, ensuring permissions align with data policy rather than just technical capability.

Granting permission isn’t the same as understanding usage. To assess value, you need visibility into actual consumption: who’s querying the data, how often, and for what purpose. Usage telemetry captures which schemas or subsets are accessed, what filters are applied, and whether the data supports exploratory analysis or production systems, and the distribution channels integrate back to the data management platform to create a unified usage model.

Consumption is one half of the reading. The other half is cost, and not all catalog metadata is meant for end users—some exists purely for governance and control. Total cost of ownership (TCO) is a prime example. The catalog tracks not just licensing fees, but the full economic footprint of each data asset: storage costs, compute resources consumed during processing and distribution, engineering time spent maintaining pipelines, and operational overhead for support and troubleshooting. This gives data owners and finance teams visibility into a data asset’s full cost burden, and it is the number consumption has to be read against.

Put the two together and the catalog answers the question its heading asks. For any data asset, bought or built, the firm can set what it is used for and by whom against what it costs to keep, and say whether it earns its place: keep it, expand it, or retire it. A team that knows what a data asset is worth negotiates its renewal from strength. It also sees whether usage aligns with intended purposes and licensing terms. How the entitlement and usage data the marketplace collects feed ROI assessments, chargebacks and pricing is the Value Framework’s subject, later in the book; the reading itself is one a firm can produce today.

The same visibility is what an audit tests. Data vendors, government agencies and regulatory bodies audit how data is used, and responding can consume enormous time and resources when visibility is poor. Slow or incomplete responses not only waste effort—they signal to auditors that your house isn’t in order, which can trigger deeper, more invasive audits. When you have integrated visibility—catalog entries connected to lineage details, derived datasets, compliance rules, access controls, and usage patterns—audit responses become fast and confident. You can demonstrate exactly who accessed what data, for which purposes, under what permissions, and whether usage complied with licensing terms. Compliance shifts from a burden to an operational advantage, and auditors recognize an organization that takes data governance seriously.

Now read your own organization. Can an analyst find a dataset without emailing anyone? Can they judge whether it fits before requesting access? Can you say, for any data asset you bought or built, whether it earns what it costs? Three yeses mean the firm has strong marketplace dynamics, whatever it calls it. Three noes mean it has an inventory of tables and a licensing bill it cannot explain. The first question is the easiest to fix and the third is the one that decides whether the catalog is operating or merely built.

Part II of The Art of Data War — Knowing Your Position, PRAISE Framework. Previously:

An organization’s data capability is only as durable as the structure that holds it. Hire strong people and attach them to tasks, and the work walks out with them. Build teams around focus areas, and their innovation and built capabilities compound through turnover. The same holds for leadership: each new data leader brings a philosophy worth learning from; strategy doesn’t shift with every hire. Management that is aware and involved commits with a clear view of impact, risks, costs and upside — and a strategy held that way outlives the leader who brought it.

Skills & Continuity, the Resource dimension of PRAISE, reads how durable that structure really is: whether the organization can attract and keep data talent, whether it holds beyond individual experts, and whether capability is spread wide enough that the whole business can act on it. The three signals run in order; each builds on the one before. Few companies show what durable resourcing looks like at scale better than Intuit.

Intuit — Resourcing durable data capability at scale

Intuit offers a strong example of how organizations can resource data capabilities in a way that survives growth, turnover, and changing business priorities. Beginning in 2007, under founder Scott Cook, Intuit launched Design for Delight (D4D), an operating model that embedded experimentation, customer data, and rapid learning into how products were built. Intuit treated it as a business discipline from the start. The company invested heavily in hiring and upskilling data scientists and analysts, made data literacy a baseline expectation across teams, and has since trained more than 1,500 employees as Innovation Catalysts: internal coaches who spread experimentation and data-driven practices throughout the organization.

Intuit also designed its organization to avoid reliance on individual experts. Experimentation platforms, standardized metrics, and shared analytical tooling let teams generate insights without depending on a small set of specialized analysts. By 2012 the company was running over 1,300 experiments a year, across every function from product to legal, and maintained the pace. The program outlasted two changes of chief executive, in 2008 and 2019, and is still active today. Knowledge lived in systems, processes, and teams, not in personal spreadsheets or tribal memory.

Data teams sat close to business execution: analysts and data scientists worked product reviews, growth discussions, and pricing decisions directly, while business teams were trained to explore data themselves, a structure Intuit still hires for today. When Intuit’s finance team discovered that 25% of QuickBooks customers weren’t updating payment information on time, contextual research revealed emails weren’t reaching the right people. Through rapid experimentation, they fixed the communication gap and recovered approximately $8 million annually. Between 2010 and 2020, Intuit more than doubled revenue while expanding operating margins, growth that leadership repeatedly attributed to faster learning cycles and better customer insight. Other forces worked in the same window: the shift to cloud subscriptions, a tax-preparation market that kept growing on its own, and the acquisition and integration of new businesses, from Mint in 2009 to Credit Karma in 2020. Scott Cook has also stood behind D4D for its entire life; continuity that has never lost its founding sponsor is a postponed test, not a passed one.

The Signals to Look For

Read the case back and three structures carried it. Intuit gave its data talent work worth staying for, and kept training more of it. It moved knowledge out of individual experts into platforms and standards its teams owned together. And it spread capability across the business, from product reviews to pricing decisions. The three signals of the Resource dimension read for exactly these, one at a time.

1. Is the organization able to attract, upskill and retain data talent?

What to look for: Does the organization invest in senior data leadership with real authority? Is the firm able to attract top talent in the data space (people with strong track records) and position them for success? Are there visible programs that help people grow their skills and take intelligent risks? And critically, do talented data professionals stay and grow with the company, or does turnover tell you the opportunity isn’t delivering?

Attracting strong data talent starts with credible leadership at the top. Organizations serious about data and AI invest in a Chief Data or Chief AI Officer who can navigate the complexity of technology, business strategy, and organizational change. The investment itself announces, to the market and to internal teams, that data is treated as strategic. Even more importantly, when that leader articulates a compelling vision, the vision becomes a formidable recruitment tool. While compensation and titles play an important role, top talent also seeks opportunities where they can grow and have high chances of success. They join because they believe the problems are worth solving and the organization is committed to solving them well.

Retention was one of the hardest problems I watched hedge funds fight, and it concentrated in the central data engineering and data science teams. For a new hire it is the most exciting job in the world: they arrive expecting to hunt alpha signals and build trading models. What they find is custom data pipelines to build, and to maintain on weekdays and weekends. Some of these hires are engineers at heart, drawn to design patterns and pure engineering problems; others came for the data, the analysis, and the sector background. Pooled into one team and attached to whatever needs doing, both kinds leave, and no compensation review fixes it, because the job was never the one they came for. Structured around focus areas, the same people flip: teams own their ground and innovate on it, and upskilling happens naturally as people take on harder problems and stretch into new capabilities. That ownership generates tremendous business value, from central data platforms and well-maintained knowledge bases all the way to the MLOps and guardrails for spinning off new predictive models.

The restructuring I saw work drew exactly that line. The central organization was rebuilt into focus areas: a platform team building the central data management platform; data engineering teams using it to onboard datasets, learn them, and work use cases with the portfolio managers; data scientists forming hypotheses and answering investment questions with the data and tooling made available to them. After the change, retention issues all but disappeared. Retention follows naturally when people are growing: taking on bigger problems, seeing their work drive business decisions, and building capabilities that compound over time. The company scales, new challenges emerge, and people grow into larger roles without needing to leave. When attrition becomes a pattern, especially among high performers, it tells you something has broken: the work isn’t producing meaningful results, leadership credibility has eroded, or the organization stopped creating opportunities for growth. The reasons to stay are built, not offered.

2. Is the organizational structure resilient beyond individual experts?

What to look for: Are critical data and business capabilities dependent on a few key individuals, or can the organization continue functioning when those people are unavailable? Look for shared tooling, accessible knowledge bases, standardized processes, and governance protocols that create transparency and eliminate dependency on specific individuals.

Key-person dependency, commonly referenced as the “no heroes” dilemma, is one of the most common failure modes in data organizations. When critical work, a revenue forecasting model, a customer segmentation pipeline, the knowledge of how legacy systems connect, depends entirely on one or two individuals, the organization becomes fragile. When that person goes on vacation, progress halts. When they leave, it creates panic and forces non-optimal knowledge transfer protocols. Projects stall, deadlines slip, and institutional knowledge evaporates.

The issue isn’t that experts exist; every organization needs deep expertise and specialized skills. The problem is when that expertise isn’t integrated into the broader system. A strong data organization takes what experts build and makes it part of the larger intelligence. This means decomposing complex work into manageable components with independent lifecycles. Consider a predictive analytics initiative: it might involve scraping external data, building ingestion pipelines, enriching the dataset with a semantic layer, developing a predictive model, and inferring results in product. Each of these components has its own development, deployment, and operational requirements. When structured well, dedicated teams can focus on managing those parts correctly, ensuring automation, quality, and reliability.

This structure serves the expert as much as the organization. Experts spend their time on the novel work they came for, the analysis and the strategic insight, instead of rebuilding foundational components every time. They work on platforms with reliability built in, freed from operational burdens. As they become more productive and deliver greater impact, they’re better positioned for recognition and advancement. They’re not stuck maintaining what they built; they’re solving the next problem.

For the organization, this approach ensures continuity when people move on, accelerates innovation by avoiding redundant work, and reduces cost by building shared capabilities once rather than repeatedly. It eliminates hero dependency and makes the organization far more attractive to new talent, who can see they’ll be set up for success rather than starting from scratch. Knowledge compounds, systems improve over time, and the organization grows stronger with each hire rather than more fragile.

3. Are data capabilities democratized across the organization to enable cross-functional execution?

What to look for: Can business teams explore data and answer their own questions without waiting for a central data team? Do data professionals participate directly in business strategy discussions, embedded where decisions are made and analytical capabilities are needed most? Does this structure enable faster innovation across the organization?

Whether business and mid-office teams can explore data and answer their own questions is a resourcing decision, and it only works with the right foundation. Self-service needs an open, capable platform with integrated tools that make data accessible without demanding specialized expertise for every operation. It also needs enabled employees, through training and accessible knowledge systems, or through hiring data-literate professionals from the start. Quantitative investment firms hire this way across all roles, expecting everyone to work with data directly. When this capability is missing, every question becomes a ticket, every experiment requires a specialist, and innovation slows to a crawl.

Equally important is ensuring data professionals are embedded directly in business execution, not isolated as infrastructure support. Data teams need access to strategy discussions, business debates, and the problems being solved in real time. This doesn’t mean abandoning centralized platforms; in fact, strong central platforms enable embedded teams to move faster. But proximity to the business is what allows data expertise to shape outcomes rather than just measure them. The quiet failure mode is the reserved task: analysis one team holds against another, capability treated as territory. Held that way, its strategic value diminishes; resourced as shared muscle, it compounds.

When both elements work, business teams empowered to explore data and models, and data professionals embedded where decisions are made, innovation accelerates across departments. Teams ideate and experiment faster, insights surface earlier, and execution becomes cross-functional rather than siloed. Organizations that structure around this principle create compounding advantages. Those that don’t find themselves perpetually behind, waiting for insights that arrive too late to matter.

AI has collapsed this gap from both directions at once. Business teams can now run analysis that once required a specialist: the question that used to sit in a ticket queue gets explored the same afternoon, against governed data, with guardrails the platform enforces. Engineering teams gain the other half: through AI and agents they carry a working knowledge of the business context they build for, and they innovate inside it instead of waiting to be briefed. Central engineering still has to be thoughtful about how content is organized and cataloged; agents are only as good as what they can find. None of this replaces deep expertise. It deepens what specialization earns: when every team can reach the data and the context, the experts’ work travels further, and the gains compound where the two meet.

Now read your own organization. Does your data leadership inspire the roadmaps and the hires, and does the work people came for match the work they do? Does anything critical stop when one person is unreachable? Does a question from the business become an exploration, or a ticket? The three answers are a position on the Resource dimension, and unlike the people who carry your capability today, a position holds only as long as you maintain it. Structure is the part of the resourcing and talent strategy that nobody resigns from.

Part II of The Art of Data War — Knowing Your Position, PRAISE Framework. Previously:

Picture two firms—same business, similar size and similar target markets. In the first, the CEO talks about data the way they talk about office space: a cost to be managed sensibly. In the second, every business conversation involves the firm’s data and AI capabilities. It doesn’t take a decade anymore: the second is already accumulating more ways to disrupt the first than the first has answers.

The difference was never the technology budget. Leadership that treats data and AI as infrastructure to be managed has already forfeited the compounding advantage, however well it executes everything else; genuine intent rebuilds the organization around intelligence. And AI has shortened the clock on that verdict. Foundations that eroded quietly over a decade now decide who fields a credible AI capability within quarters.

Leadership & Intent, the Prioritize dimension of PRAISE, assesses exactly that difference: whether conviction lives at the top, whether it translates into direction the businesses can act on, and whether it persists as leaders change. The three run in order; each depends on the one before. When leadership gets this right, the rules of the competition change. Few traditional financial institutions demonstrate this more clearly than Capital One.

Capital One — Leadership intent that rewired an industry

Capital One’s transformation into a data-driven institution began in 1988—six years before the company existed. Richard Fairbank and Nigel Morris built their information-based strategy inside Signet Bank and pitched it to the national retail banks. Twenty said no. The credit card division it produced was spun off as Capital One in 1994, with the conviction explicit from the start: an information-based strategy business that happened to sit in financial services. Harvard Business School’s case study of the period documents how data, analytics, and large-scale experimentation were elevated to the core of executive decision-making—credit underwriting, pricing, marketing—long before this became common practice in banking. Data was framed by leadership as competitive advantage tied to growth, risk-adjusted returns, and market share, never as infrastructure or compliance overhead—and the analytics scaled the credit card business through the late 1990s, gaining share while holding charge-off rates at or below the top-ten issuer average through 2001.

The strategy outlived every transition beneath the top. Over the following decades—well before the completed Discover acquisition changed the firm’s scale in 2025—CIOs, data leaders, and business heads rotated and moved on, and initiatives built on prior foundations rather than resetting; the chief data officer role, established more than two decades ago, still reports into the firm’s enterprise leadership. The commitment survived its hardest test mid-flight: a 2019 breach affecting some 106 million accounts and an $80 million regulatory penalty citing the cloud migration itself—and yet no reversal, with the firm announcing in November 2020 that it had exited its last on-prem data centers, the first US bank to go all in on the public cloud. One caveat belongs on the table: Fairbank has run Capital One since the beginning. The strategy never had to survive a change of CEO: continuity under an unchanged founder is a postponed test, not a passed one. The result was still not just operational efficiency, but durable differentiation in how the bank priced risk, acquired customers, and scaled new businesses—proof that when leadership intent is real, data maturity compounds even as executives change.

The Signals to Look For

Read the case back and three things carried it. Leadership held the conviction and owned it: the strategy was the company, not a program inside it. The conviction was articulated as direction the businesses could act on: underwriting, pricing, and marketing knew what the data was for. And what was built compounded: each initiative inherited platforms and momentum instead of replacing them.

1. Is data treated as a first-class business asset?

What to look for: When leadership talks about data, do they frame it as a way the business competes and wins, or primarily as infrastructure that needs to be managed? And perhaps most tellingly: do they talk about it at all?

What you’re looking for here is an intentional adoption of data as a business driver at the very top. The belief and commitment should be owned by the CEO personally and reinforced at the board level. Without that sponsorship, data inevitably defaults to infrastructure: important, expensive, and necessary—but not strategic.

Many digital or transaction-heavy businesses manage data at scale simply to operate. That alone does not make them data-driven in a competitive sense—operating on data is not the same as competing on it. When leadership does not articulate why data matters beyond keeping the lights on, it usually tells you data is viewed as cost, not leverage.

The intent must also be made visible—wherever leadership speaks to the whole organization, and to whoever holds it accountable. Data priorities should appear repeatedly in town halls, board papers, investor communications, internal narratives—not as a technology initiative, but as a way the business wins. Just as importantly, the intent must translate into execution: roadmaps reflect it, departmental goals align to it, and mid-level management is motivated by it and equipped to act on it.

In rare cases, this mindset comes from leaders who have already experienced data-driven advantage firsthand—executives who lived through a transformation elsewhere and know what’s possible. At Capital One, that conviction came directly from the top. In most institutions, however, leaders have not lived through that competitive edge. In those cases, progress depends on change agents—senior leaders who can articulate data’s value in business terms, anchor it to real drivers, and execute with enough consistency to build confidence over time.

At a leading investment firm, I once pitched the heads of independently run businesses, each a CEO in their own function, on a centralized data practice: real engineering muscle, enabled data intelligence practices, broader vendor reach, and a budget contributed by every business. The north star was business efficiency: cutting the time from hiring new investment teams to them trading, and becoming the kind of firm that talent and investors choose, discretionary and systematic alike. The mission was simple and in line with their business goals: strategic enough to remedy challenges at the root, while giving every business breathing room to innovate further.

2. Is there a clear and credible data strategy?

What to look for: When you hear about the data projects and roadmap, do they generate genuine conviction—or does it feel vague, recycled, or disconnected from business priorities?

When the direction is set and prioritized by leadership, functional managers and business heads understand where they are encouraged to innovate, what problems are worth solving, and how data and its solutions are expected to contribute. That clarity reinforces critical thinking and purposeful experimentation—teams know which questions matter and can pursue them with confidence.

There is a test for whether the direction ever landed, and you can run it from any seat in the building—call it the debate-altitude test. A credible strategy, both for business and data, reduces debate rather than creating more of it. When direction is clear, teams argue about designs and implementations, not foundations or goals. They debate which features to prioritize, which design patterns to use, not which platform architecture to adopt. They refine execution, not revisit ownership. In a firm with clear direction, a team might debate whether to prioritize churn prediction or lifetime value modeling first. But if they’re still arguing about whether to store data in a relational database or a data lake, or whether analytics should live in the product team or a central data group, the foundational strategy never landed.

Crucially, data innovation should never exist in isolation. A credible data strategy makes explicit how data and analytics advance concrete business objectives: whether on the top line through growth, new products, or market expansion, or on the bottom line through efficiency, risk reduction, and operational leverage. Technology upgrades that cannot be traced to a business advantage, even indirectly, erode conviction over time. When leadership consistently frames data initiatives in business terms, innovation becomes purposeful rather than performative.

A sound data strategy also reflects a deliberate balance between near-term impact and long-term optionality. Some initiatives are expected to deliver measurable results quickly; others are intentionally exploratory. Consider how financial institutions in the early 2010s invested in machine learning infrastructure—not because the ROI was clear, but because they understood that algorithmic trading, credit modeling, and fraud detection were evolving rapidly. Firms that built those capabilities early gained years of advantage over competitors who waited for certainty. Similarly, pharmaceutical companies investing in genomic data platforms today may not see immediate returns, but they’re positioning themselves for a future where personalized medicine becomes standard of care. What matters is not certainty of outcome, but clarity of intent: leadership understands which bets are foundational, which are experimental, and why both exist, which in turn helps with the right prioritization, budgeting and sequencing decisions.

I faced this balancing act myself, often. At the end of 2022—when AI brought excitement and anxiety in equal measure, small players declaring disruption inevitable while established executives saw doomsday—we chose to make an early move: a centralized chat interface exposing frontier models to the whole firm. The near-term impact was real. Adoption spread, institutional learning, momentum built, and we had a front seat in the race. But the long-term option it bought mattered more: the log traces revealed the most common use cases, the knowledge bases people actually needed, and who the early adopters were: all the raw material needed for a more intentional agentic ecosystem for discretionary investors, built on those lessons, guardrails, and proven flows.

3. Do data initiatives persist across leadership cycles?

What to look for: When leadership changes—a new CEO, CTO, or CDO—do data initiatives build on prior progress, or does each transition bring a reset with new platforms, vendors, and rebranded strategies?

Continuity doesn’t mean stagnation—it means new leadership extends what’s working rather than starting from scratch. At the highest-performing organizations, data initiatives compound over time. New executives inherit platforms, processes, and momentum, then build on them and refine them. When that doesn’t happen, there’s a write-off—not just financial, but in lost time, eroded trust, and organizational momentum. Those costs should be taken seriously at the highest levels before allowing strategic reversals.

One of the clearest tells of instability is a strategy that keeps changing without clear reasoning. One year, the priority is centralized data ownership—a single platform team controlling standards, quality, and access to ensure consistency across the business. The next year, leadership pivots to a federated model where each business unit owns and manages its own data, citing agility and accountability. Both approaches have merit, but when the shift happens without explaining what failed in the first model or what specific problems the new one solves, teams are left guessing. Engineers who built the central platform wonder if their work mattered. Business units hesitate to invest, assuming the next reorganization will undo it. When priorities reverse without clear closure or institutional learning, teams stop internalizing the strategy.

The biggest risk often comes at the hiring stage. When bringing in new senior leadership, especially into organizations where a data strategy is already established, alignment on direction matters as much as capability. Consider an established investment firm that commits to cloud modernization—migrates critical data footprint, builds team expertise, and begins scaling adoption. A new senior hire joins with strong credentials but without deep assessment of whether the person believes in the existing strategy. Within months, the new leader begins pitching a return to on-premise infrastructure, arguing the firm needs more control and shouldn’t depend on external vendors. Management, without fully interrogating the trade-offs or value, approves the shift. The result: millions spent rebuilding infrastructure that had already been modernized. The new on-prem systems are never properly adopted, the cloud ecosystem becomes orphaned, and the people who built it begin to leave. The misalignment proves costly.

Now run the signals on your own firm. How does leadership frame data when no one from technology is in the room? Does the roadmap end arguments or start them? Did the last transition extend the platform, or reset it? Read honestly, the three answers are a position—where conviction lives, whether it lands, whether it survives—taken before the results arrive, while it can still be changed. That is the point of reading intent early: unlike results, it is still yours to change.

Part II of The Art of Data War — Knowing Your Position, PRAISE Framework. Previously:

I’ve been called into situations where the external story and internal reality don’t match. The firm is profitable. Leadership has pedigree from top institutions. The brand attracts talent. Quarterly performance is in line with the benchmarks. Employees don’t see trouble coming—there’s a prevailing sense that strong returns will continue and everyone’s position is secure.

But management sees something different. Costs are escalating—licenses, infrastructure, headcount—without proportional improvements in what the business actually gets. Investment teams funding these capabilities aren’t seeing better insights or faster execution, so their expectations stay low. Meanwhile, conversations behind closed doors are getting heated. Data teams feel underfunded and underappreciated. Some are threatening to leave. The gap between “we’re printing money” and “this isn’t sustainable” is narrower than most employees realize.

This isn’t about one firm. I’ve seen this pattern repeat across multiple institutions with different strategies and different leadership. The symptoms vary in detail, but the underlying dynamic is the same: organizations can succeed financially while quietly losing the infrastructure war. By the time the gap becomes visible to everyone, the structural problems are years deep—and key people are already halfway out the door.

Why Traditional Assessments Miss the Point

When executives realize they need to assess their data capabilities, they reach for the familiar. A technology audit inventories the firm’s tools and licenses. A capability maturity model, borrowed from software engineering, scores the processes. A vendor scorecard rates the platforms on features. Each produces a thick report and an action item list. Each feels rigorous. And each almost always measures the wrong thing. These audits evaluate what you have—tooling, headcount, process maturity—against generic benchmarks already obsolete for your competitive reality. They measure the plumbing instead of the water pressure.

What these approaches don’t reveal is whether your data capabilities translate into competitive velocity. Can you launch strategies faster than competitors? Adapt when markets shift? Test hypotheses and deploy insights before the window closes? Put an AI model into production with trusted guardrails? Or has your “mature” data stack become so complex that the lion’s share of your budget goes toward keeping the lights on—maintenance, cloud costs, integration fixes—rather than generating new advantages? When disruption arrives, this kind of expensive complexity acts as an anchor, not an engine. If your architecture is so standardized that you can’t integrate a new data source in 48 hours to respond to a competitor’s move, you don’t have a capability—you have a liability.

When speed and adaptation determine survival, measuring the wrong things is indistinguishable from not measuring at all. Maturity doesn’t mean having the most sophisticated tools or the highest process scores. It means your organization has the capacity to make data-driven decisions under pressure and adapt when conditions change.

What PRAISE Actually Is

PRAISE is a strategic diagnostic. It reveals whether your organization is building competitive advantage or just maintaining complexity. It’s not a scoring system or a checklist of technologies to acquire. Instead, it surfaces patterns that executives often miss until they become crises—the warning signs that appear in how decisions get made and how quickly you can respond to threats.

PRAISE examines six dimensions where data capability either compounds advantage or creates hidden vulnerabilities. Prioritize asks whether leadership treats data as strategic or tactical, and Resource whether you’re building institutional muscle or just hiring headcount. Account asks whether you can see what you have and control who uses it, and Integrate whether data enables the business or lives in isolation. Stabilize asks whether operations run reliably or depend on heroics, and Evolve whether you’ve architected for disruption or accumulated dependencies. These dimensions aren’t independent—weakness in one often amplifies problems in others. An organization that prioritizes data strategically but fails to stabilize operations ends up with well-intentioned chaos. Strong integration without visibility and control creates invisible dependencies that surface as failures during crises.

PRAISE is reconnaissance—a way to see the battlefield clearly before competitors force you to fight on their terms.

How to Use PRAISE

The diagnostic works through observable patterns across the organization. Whether you’re an executive, a front- or mid-office manager, or a data engineer, you’ll have direct visibility into some dimensions and limited insight into others—that’s expected. No single person sees the entire picture.

Start with what you can see directly. If you’re a data leader, you’ll have clear answers about resourcing decisions and operational stability but may need to probe executives about strategic priorities. If you’re in the front office, you may have limited insight into underlying architecture—but you’ll know immediately whether data enables your work or creates friction.

You complete it through observation and conversation, not from a single vantage point. Use team meetings, firm-wide surveys, skip-level discussions, and informal check-ins to fill gaps. Ask your data engineers how often they’re fighting fires versus building new capability. Ask portfolio managers how long it takes to respond to market events. The patterns will emerge quickly.

Expect some answers to be uncomfortable—that’s the point. You’ll discover that initiatives you thought were strategic priorities are viewed as low-value distractions by the people funding them. You’ll find that systems considered “stable” are held together by a few overworked engineers who are interviewing elsewhere. These moments of discomfort are where the value lives. The goal isn’t a perfect score or a polished report for leadership. It’s conviction about where you actually stand—which gaps create systemic vulnerabilities, which are acceptable trade-offs, and where investment will generate the most competitive return. If you finish this with shared language about your real strengths and weaknesses, you’ve succeeded.

Where You’ll Land

Some organizations come out of this stronger than they thought—exposed, but more self-aware, informed, and with conviction. Others come out of it weaker than the story they’d been telling themselves. Both now have something they didn’t before: a position.

What follows from it varies. Some slash projects that aren’t set up for success. Others finally fund the ones they’d been starving. Some go back to the drawing board and seek external advisory for a reset. Every one of those decisions comes from the same place: knowing which capabilities compound into an edge, and which ones just accumulate. And that clarity is what separates organizations that drift from those that adapt.