Skip to content
Anil Thapa

Case studies

Work

Each of these is a pattern I have run more than once, written the same way: the situation, the constraint, the decision, the tradeoff I accepted, and what actually happened. The reasoning is portable and it is the useful part: the confidential specifics belong to the organizations I did the work for and are not here.

Org designHiringPlatform strategyGovernanceEnablementExec partnershipStrategyCommunicationDecision supportData qualityIncident responseStakeholder trustArchitectureStakeholder alignmentMigrationVendor selectionCost governance
01
Org designHiringPlatform strategyGovernanceEnablement

Greenfield data function, analysts embedded across departments

Building a data function from zero

No data team. Engineers working in a vacuum, product managers asking developers for numbers, and every department with its own analyst producing a different answer to the same question. The platform was the straightforward part.

Built from the ground up: the pattern generalizes to any organization that grew without a data function

  • Centralize the definitions first, the people second, the tools last
  • Analysts join the centre for governance and stay close to their department
  • Training is the deliverable: a platform nobody can use is not a platform

OutcomeOne governed language for the business, and departments that stopped keeping private numbers

Read it
02
Exec partnershipStrategyCommunicationDecision support

Executive partnership across departments and at board level

Data in the boardroom

Being in the room is not the same as being useful in it. Most of the work is not C-suite set pieces. It is department heads, one at a time, and the argument is never really about metric definitions.

The part of the job that took longest to learn and transfers least from technical work

  • Executives do not want the number, they want the decision it implies
  • Align on the strategy first; metric definitions are the mechanism, not the point
  • Show the uncertainty; hiding it is what costs you the room

OutcomeData present while decisions were made, not reporting on them afterwards

Read it
03
Data qualityIncident responseGovernanceStakeholder trust

Data quality and reliability as an operating discipline

Earning trust in the numbers

Trust in a data platform does not degrade gracefully. It holds, then one confidently wrong number in a visible setting, then everyone checks everything manually forever. Treating quality as a discipline rather than a side effect.

The problem underneath every other problem on this page

  • Trust is a step function, not a gradient, protect the step
  • Cover the numbers your most skeptical stakeholder uses, first
  • How you handle the incident matters more than the incident

OutcomeFailures found by monitoring rather than by an executive in a meeting

Read it
04
ArchitectureGovernanceStakeholder alignment

Warehouse consolidation across mergers, silos, and migrations

One number, two histories

Mergers, departmental silos, platform migrations, the surface story differs every time. The invariant is that two groups have incompatible definitions of the same metric, and the pipelines are the easy part.

A pattern I have run repeatedly, in several different forms

  • Definition reconciliation is the project; the pipeline work is support
  • Agree the metric before writing the model, or relitigate it forever
  • A slower visible start buys a result people actually trust

OutcomeManual reconciliation retired rather than automated

Read it
05
ArchitectureData qualityMigrationVendor selection

Ingestion rebuilds across heterogeneous sources and warehouses

Rebuilding ingestion people trust

Pipelines decay quietly and the rebuild question is never "is this broken" but "can we still justify trusting it." Choosing the integration approach, handling sources that do not agree with each other, and proving the result before anyone is asked to rely on it.

Several rebuilds, different source systems and different constraints each time

  • Pick the integration approach from the source constraints, not from preference
  • Parallel run until variance is explained, not merely small
  • Cutover is a trust problem before it is a technical one

OutcomeCutover with every remaining variance explained, not merely small

Read it
06
Platform strategyCost governanceVendor selectionExec partnership

Platform cost governance and capacity decisions

What the platform costs

Warehouse spend is the one number a data leader owns end to end and the one most cannot explain. Making cost legible, pushing the decision to the people creating it, and knowing which inefficiencies are worth leaving alone.

A recurring responsibility rather than a project: the work is making it routine

  • Unattributed cost cannot be optimized, attribution comes before efficiency
  • Cheap and slow is a decision, not a default
  • Some waste is correctly left alone; say which and why

OutcomeSpend attributable to teams and defensible per workload, not a single line item

Read it
07
Org designGovernanceEnablementPlatform strategy

Central platform team federating ownership to domain analysts

Giving the models away

A deliberate giveaway of central control, and an org-design decision wearing a tooling costume. Throughput went up more than consistency went down, but the second half of that sentence is real and most write-ups omit it.

Run at different scales; the governance layer is what decides the outcome

  • A central team that owns every change is a bottleneck in platform clothing
  • Federated ownership trades uniform quality for throughput, knowingly
  • Tests and CI are the precondition, not the follow-up

OutcomeSeveral times as many people able to safely change production models

Read it