JEREMY NAY

Independent advisory work

Since Expedia I've been advising mid-sized businesses on data platforms and AI enablement, and building the custom systems they need. These are production deployments with real users and real operational stakes.

The approach carries over from enterprise scale. AI goes where the work is mechanical and precision matters, and people stay accountable for correctness and meaning. The quality of the data foundations determines whether any of it holds up, and smaller organizations still need governance, just sized to fit them.

The work also keeps my technical judgment current. Leaders directing AI-era engineering organizations should have recent, firsthand experience with the tooling their teams live in.

The multi-agent software factory

I built a multi-agent software factory that takes a specification through implementation and validation to delivery. It runs on Claude through the CLI and API, uses MCP for tool integration, keeps context in SQLite, and is orchestrated deterministically in Python.

The design principles are the ones I've applied to every AI system I've been accountable for. Agents run where reasoning genuinely adds value, and plain code handles everything else. Explicit validation gates sit between the stages, and because development is spec-driven, correctness is defined by a human up front.

Using the factory I've delivered multiple real customer systems solo, on timelines that would traditionally take a team, while preserving SDLC rigor and production readiness.

Consolidating four teams into one global organization

The organization reached 39 people across EMEA, APAC, and AMER, roughly 260% growth, and most of that came through consolidation. Several previously independent teams, each with its own intake process and standards, moved under a single operating model. Intake and delivery practices were standardized across the teams, and on-call became a shared follow-the-sun rotation with common expectations for runbooks and escalation.

Consolidation at that pace erodes culture unless someone is actively shaping it. I decided the norms I wanted, worked directly on the gaps where an incoming team's habits fell short, and spread the right behaviors through the managers and senior ICs who set the tone day to day.

The result was an organization directing $11.4M in annual investment that operated as one team, with engagement scores above company averages and a delivery record to match.

Building the leadership bench

I treat succession as a deliverable. Mid-level ICs grew into senior technical leaders with cross-organizational scope, and several managers advanced to Senior Manager with independent ownership. Interns I had converted to full-time years earlier were senior contributors by this point.

The mechanism was deliberate. Ownership and decision rights were explicit. Regular VP-level demos covered failures and tradeoffs alongside the wins, and architectural deep dives gave senior engineers practice exercising judgment in the open.

A bench proves itself when the organization holds up in the leader's absence. Mine did, and each organization I've led has continued to run well after my departure because the structure was built for exactly that.

Operating decision-critical platforms

The platforms my teams owned fed C-suite dashboards reviewed daily, influenced roughly $250K per day in ad spend, powered real-time decisioning, and produced SOX/GRC compliance reporting. More than 200 analysts and data scientists depended on them, along with a 300-person product organization. When something broke, escalation ran to VP, SVP, and CISO level.

That level of visibility shapes the engineering. We ran shared PagerDuty rotations across three continents and enforced runbooks with explicit escalation paths. The semantic consistency of metrics got the same attention as uptime, because an available dashboard showing wrong numbers does more damage than an outage.

GDPR and CCPA obligations applied across these platforms, so data retention and the treatment of personal data were design constraints from the start.

The AI-powered analytics onboarding system

Onboarding a metric into our enterprise metrics platform required hand-written SQL and YAML configuration, with careful human precision at every step. When upstream metric logic changed, teams redid enormous amounts of work; one team lost a full quarter to exactly that. Strong data engineers were spending their days as careful SQL and YAML editors, which told me the system's design was the problem and added headcount would never fix it.

I mandated an engineering solution with explicit constraints. Humans would stay accountable for correctness and meaning. Automation had to reduce the work without obscuring the logic, and the finished system had to meet production reliability standards.

My team delivered a RAG-grounded pipeline. An engineer types a natural language question, and hybrid keyword and vector retrieval finds the relevant schemas in an Elasticsearch index of approved tables. Claude then generates SQL, which passes through automated validation covering schema correctness, join validity, NULL handling, and a confidence score. From the validated SQL the system extracts governed measures and dimensions, then produces standards-compliant YAML and opens a pull request into the governed metrics repository. The whole workflow is surfaced through a Backstage developer portal plugin.

The guardrails mattered as much as the generation. The LLM could only reference schemas in the approved index, and column pruning ran as a deterministic Python function because for schemas we own, column importance is a known quantity that belongs in rules. Pull request creation was automated while approval stayed with a human engineer on every artifact.

Onboarding collapsed from days to hours and freed more than $2M in annual engineering capacity.

Closing the SOX compliance blind spot

SOX violations were being identified and then going nowhere, with no system to track them and no owner responsible for remediation. The gap sat between organizations, which is why it stayed invisible at the company level for as long as it did.

I mobilized across teams and data sources to build a unified system that let GRC identify, classify, prioritize, monitor, and enforce remediation of violations. Daily reporting made compliance something GRC could manage actively throughout the year.

The work reinforced a principle I apply broadly: correctness in compliance data is a governance problem, and reporting that fails to drive accountability has no value.

Platform ownership and migration readiness

My teams owned the AWS Redshift analytics platform and consolidated several other teams off legacy SQL Server. When the mandate came to converge onto the corporate data platform, my responsibility was to determine when that migration would be safe and to hold the schedule accountable to that answer.

I defined production readiness requirements from observed workload behavior, spanning data correctness and freshness as well as latency under real load, and sequenced the migration once the platform met them. Where core abstractions fell short we extended them, and the operational evidence went back into the platform team's roadmap.

Delaying the migration was unpopular at the time. Migrating before the platform was ready would have cost far more over the following years, and my job was to make that call on evidence.

Embedding standards into engineering workflows

Standards enforced by policing get skipped under pressure, so we built them into the workflows themselves. Access control, data quality checks, observability, and auditability became part of how the teams worked day to day.

The data quality work shows the approach. I blocked adoption of a commercial data quality tool after determining it could not meet our production needs. In the interim the team built a forward-compatible internal framework with upstream pre-ETL validation and pre-commit checks built on Iceberg, configured through portable YAML so it could migrate cleanly later. When the core platform's roadmap caught up more than six months afterward, we inner-sourced the framework back to them.

None of it depended on individual diligence, which is why it held.

Unifying analytics into one source of truth

Analytics ownership was scattered across product, platform engineering, IT, risk/GRC, and security. Each group had its own implementations and its own numbers for the same metric, and when two dashboards disagree, every decision that depends on them starts with an argument about whose figure is right.

We simplified those fragmented implementations into authoritative enterprise systems and eliminated the duplicate and conflicting metrics. Over time the other organizations came to treat our data as the default truth.

That trust was earned operationally, through consistency and through accountability whenever a number was wrong. The work shifted analytics from reactive reporting into decision infrastructure the enterprise relied on, and the promotion to Director recognized responsibilities already operating at that level.

Metrics standardization and analyst self-service

We standardized the company-wide metrics platform and made our data assets available in the analytics data playground, a self-service environment where analysts could explore without filing tickets. The tooling we built let consumers get trustworthy answers without needing to understand data engineering internals.

The interface between data engineering and its consumers worked like a contract. Analysts got governed, well-defined data, and we kept the freedom to evolve everything underneath it. When an analyst built something valuable enough to deserve production support, we onboarded it properly.

The table design and metadata discipline established during this period is what later made AI-driven onboarding automation feasible at enterprise scale. Semantic layers get built long before they pay off.

Retaining the Security Data Warehouse through reorganization

When Data Engineering, Analytics, and BI consolidated under Platform Engineering, my scope grew to more than twice the sum of the original teams. Through that change I kept direct ownership of the Security Data Warehouse, serving Security Engineering, GRC, Operations, and Physical Security with reporting consumed up to the CISO.

Reorganizations are where institutional knowledge and service continuity tend to die quietly. Keeping the security data mission stable meant the CISO's reporting continued uninterrupted while everything around it moved.

It also kept me working at the intersection of data and security, a vantage point that shaped most of what I built afterward.

The build vs. buy decision

I led a 22-person global security engineering organization covering IAM, insider-threat and indicators-of-compromise detection, physical security, and deployment automation, and I owned the roadmap and its tradeoffs. The hardest deliverable that year was the data and analysis behind a CISO-level build vs. buy decision on our security tooling.

The analysis favored buying, specifically IBM QRadar SIEM and Resilient SOAR over continuing the in-house build, and the CISO made the call. As a consequence my own security engineering developers were redistributed to teams across Platform Engineering, and I absorbed orphaned data engineering and BI teams that had no home after the restructuring.

That is how my move from security into data engineering leadership happened. My analysis drove the reorganization, and I stepped into the result and led those teams forward. A recommendation shaped to protect my own org would have been the wrong one.

Building the Security Data Warehouse

Security telemetry lived in dozens of third-party tools, each with its own console and its own partial view. Reporting on the company's overall security posture was being assembled by hand.

We built the Security Data Warehouse as the consumption-ready layer on top of the enterprise security data lake, with pipelines and APIs feeding dashboards that unified visibility across security operations, insider threat, physical security, and internal risk. It became the primary source of metrics and reporting for the CISO and the Senior Security Directors.

Aggregating the data was the smaller part of the job. Every number in a CISO dashboard is a number someone may have to defend, so correctness carried more weight than coverage.

Scaling the security tooling portfolio

The portfolio that year ranged from behavioral analytics to badge readers. We scaled Exabeam, the behavioral analytics and investigation platform, to four times its operational capacity by broadening the detection sources feeding it, landing new feeds such as badge events and server logs into the security data lake.

On the physical side we delivered bi-directional synchronization between the Lenel and Pro-Watch badging systems, which gave employees a single badge that worked globally, and unified video and badging events into one view for security operators.

For identity, we built the company-wide User Access Review tool used as a SOX control, along with the self-service Access Request Portal that cut IAM operations by 40% and improved the joiner-mover-approver experience. Across all of it, the pattern was automating the mechanical work while keeping people accountable for the judgment calls.

Re-architecting the fraud detection platform

I was hired to replace two rigid, monolithic fraud web services sitting in the live booking path. This system stood between Expedia and many millions of dollars in annual fraud losses, and once fraudsters detect an outage, losses escalate within hours.

What we built was, in practice, a real-time identity resolution platform operating under adversarial conditions, where signals actively try to evade correlation. We decomposed the monoliths into a modular platform: signal collection from more than a dozen parallel sources, a stateful behavioral graph in Elasticsearch aggregating velocity over time windows, deterministic known-entity lists, ML confidence scoring, an explicit rules engine gating merge decisions, and full decision-context persistence so every outcome could be audited. The migration ran without interrupting live booking traffic.

Fraud losses fell 10% year over year, and the platform absorbed supplier fraud and account takeover workloads without relaxing an SLA. Merge errors carried cost in both directions, since a false merge let fraud through and a false split broke a legitimate customer's booking, and that risk drove the explicit confidence thresholds and conservative merge logic at the core of the design.

Onboarding acquired brands onto the fraud platform

After the acquisitions of HomeAway, VRBO, and Travelocity, each brand arrived with its own approach to fraud. Ours was measurably stronger, so the integration strategy centralized the brands onto the Expedia fraud platform.

The platform's design made that practical. The strategy engine let us onboard a new brand through configuration, adding brand-specific risk interfaces and rules without touching the core. I also played an operationally critical role in the HomeAway platform migration itself, including the identity and account work required to bring users onto Expedia systems under deadline pressure.

Faster integration and consolidated operations turned the platform's capabilities into direct M&A value.

The Sev 1 fraud incident

A legacy component in the fraud detection path failed. Fraud outages compound, because once fraudsters find the gap the losses grow hour by hour until it closes.

I led the response. Containment came first, with a targeted patch deployed quickly and carefully. Then came the more consequential decision: we accelerated the decommissioning of the failing legacy service so the same failure could never recur. Restoring it would have kept a known liability in the booking path, so we removed it.

By that point I was trusted to approve cutovers and decommissioning without additional oversight. That kind of trust accumulates one incident at a time.

Full ownership of the SDL data platform

At SDL I owned the complete product in a private data center, from cluster architecture and capacity planning through ingestion, enrichment, indexing, and query serving, up to the application layer the business used directly, including a pixel-perfect UI. There were no managed services underneath us, and every capacity decision and failure mode was ours.

The architecture matched what was later named the Lambda Architecture. Kafka served as the ingestion bus and absorbed viral traffic spikes, HBase provided the durable write store and the MapReduce input surface, Oozie orchestrated batch ML enrichment covering sentiment analysis, entity extraction, language detection, and geo-resolution, and date-partitioned Elasticsearch served queries for client reporting.

The modern equivalents are managed services like Kinesis and OpenSearch. The engineering judgment involved has changed very little, though at the time a mistake cost us recovery time on hardware we owned.

The petabyte-scale HBase key migration

Our HBase row keys were timestamp-prefixed, so every incoming write landed on the single region server that owned the current time range while the rest of the cluster sat idle. Under production load that became a hard ceiling on write throughput.

The fix itself was well understood: salt the keys with a hash prefix so writes spread evenly across regions. The complication was that HBase row keys are immutable, which meant rewriting the entire petabyte-scale corpus on live infrastructure without any elastic compute to lean on.

We executed it as chunked Oozie workflows with state-aware restart logic and dual-table consistency validation before cutover. Time-range scans became parallel scans across the salted partitions, a tradeoff we priced in ahead of time. It was planned carefully and executed once.

Improving release cadence

Releases were quarterly events when I started, with high ceremony and slow feedback. I drove a continuous release initiative that brought the team to a multi-weekly cadence and cut deployment overhead by 45%. Production capacity expanded 400% over the same period.

Tooling was part of it, and the operating model was the larger part. As tech lead of a 12-person international team split between Seattle and Ho Chi Minh City, I ran a Scrum of Scrums across sites and moved the team to a sustained delivery rhythm with smaller releases and tighter feedback loops. I also led the company-wide adoption of security reviews and formal threat modeling in the development lifecycle.

Release frequency works as a forcing function. A team can't ship every two weeks on a fragile pipeline, so the pipeline improves.

Promotion from technical lead to manager

I joined SDL as a senior engineer and grew into the technical lead role for a cross-site, full-stack initiative, working directly with executive and product stakeholders on a customer-facing reporting dashboard.

The promotion to Engineering Manager was based on measurable change. System reliability and release cadence both improved substantially, and cross-functional partners trusted the team's commitments enough to plan against them.

I still think leadership is best earned that way, with the outcomes demonstrated before the title arrives. My management style rests on having done the job my teams do, under the same constraints.

The Microsoft Policy Processor

I designed and implemented the Microsoft Policy Processor, the core policy execution engine for endpoint management. It shipped inside Windows Server, System Center Configuration Manager, Mobile Device Manager, and Microsoft Intune, running on enterprise endpoints at global scale, and the work is protected by two issued U.S. patents, 8,112,379 and 8,954,370.

I also refactored the Intune management agent's codebase, which had been forked from the Windows Update agent and written in a hurry during the Blaster and Sasser worm era, and bootstrapped its C++ unit test framework to 80% coverage. That investment paid quality dividends for every downstream team that touched the agent.

Microsoft in that era taught engineering for durability: backward compatibility, staged deployments, rollback strategies, and the hidden cost of breaking changes in widely deployed systems. Those standards stayed with me.

Replacing planned custom protocols with standards

The Policy Platform needed a communication layer, and the default plan was to design custom protocols, an effort estimated at roughly 24 person-months to implement and then maintain indefinitely.

I prototyped standards-based WMI and WinRM services for the integration. The prototype demonstrated that the standards could carry the workload, and the custom protocol effort was cancelled.

Before committing to custom infrastructure, it's worth proving whether an existing standard can already do the job. In this case the answer saved roughly 24 person-months of work.