Data, AI, analytics, and engineering leader with 8+ years of experience building trusted data products, canonical models, and production-grade data systems. Proven ability to launch data and engineering strategy from scratch, establish observability and quality frameworks, and embed reliable decision support into workflows across Finance, Product, Operations, Sales, and Marketing teams. Recognized for shaping engineering standards, creating future leaders, and delivering data as a trusted product in ambiguous, fast-changing environments.
Skills
Top skills
ETL
Show all skills7878 more skills
Technical
Generative AI
Incident Response
Performance Optimization
Go
Machine Learning
Rust
Tool
Azure Active Directory
Google BigQuery
Looker
Apache Kafka
Salesforce
Cloudflare
Domain
A/B Testing
Cloud Architecture
Compliance
Data Architecture
Data Warehousing
Product Management
Soft
Analytical Thinking
Attention to Detail
Continuous Improvement
Data-Driven Decision Making
Facilitation
Root Cause Analysis
Strategic Thinking
Accountability
Communication
Conflict Resolution
Resilience
Coachability
Experience
Principal Consultant, Data & AI Systems
DataViking Technologies
DataViking Technologies is an independent data and analytics-engineering practice. Wesley works as embedded, fractional data leadership for early-stage companies and small technical teams: making architecture calls, standing up analytics-engineering and data-platform foundations teams can own long-term, designing measurement and evaluation loops, and building agentic and AI-enabled workflows where they are reliable enough to ship. He helps teams sequence data and AI investments — what to build first, what can wait, what to drop — across the data layer and the AI on top of it.
The work is hands-on. Wesley builds with modern data and application patterns across Dagster, Databricks, dbt, Supabase, Kafka, Cloudflare, and multiple LLM providers, chosen for what small teams can actually operate. Alongside client work, he ships original products that demonstrate the same patterns in production: Traitprint (a structured professional self-knowledge system with an MCP-served portable ontology), SynthPanel (open-source synthetic focus-group tooling), and SynthBench (an open benchmark for distributional parity between AI-generated and real human survey responses). He also does structured LLM evaluation work, including a June 2026 subcontract evaluating Codex conversation quality for OpenAI.
The through-line is the substrate beneath AI systems: trustworthy canonical data models, context surfaces, evaluation loops, and adoption patterns that let human and machine consumers rely on the same underlying facts.
Built Traitprint, an AI-driven career intelligence tool that walks a person's work history into a private, auditable skill vault and measures it against real job postings (public beta)
Built SynthPanel, an open-source synthetic focus group tool for repeatable AI-assisted research across multiple LLM providers, plus SynthBench, an open benchmark for evaluating synthetic-response quality via distributional parity between AI-generated and real human responses
Prototyped modern data and application patterns across Dagster, Databricks, Supabase, Aiven Kafka, Cloudflare, and multiple LLM providers to evaluate practical adoption paths for small technical teams
Embedded as technical lead for early-stage companies: making architecture calls, standing up AI and agentic workflows, and building data foundations teams can own long-term
Helped a three-person Austin startup (Gastown) go from second-guessing every agentic workflow step to shipping faster and continuing to build on the setup independently
Show all highlights22 more highlights
Subcontracted to evaluate Codex conversation quality for OpenAI (Jun 2026), conducting structured conversation-level assessments of how the model presented technical work to users and participating in calibration discussions with other evaluators
Advise startups and small teams on data and AI strategy — sequencing what to build first, what can wait, and what to drop, across the data layer and the AI on top of it
Senior Manager, Data Analytics and Development
Peloton Interactive
Clarification for Peloton leadership scope: Wesley's formal promotion to Senior Manager occurred after his direct leadership chain publicly announced to the full department that he had already been performing at Senior Manager scope for roughly 18 months and that the promotion was overdue. His scope did not materially expand with the title change; the promotion recognized work he was already doing. In addition to directly managing his own team, Wesley played a department-level leadership role across the broader 30+ person data organization: participating in hiring, coaching and developing ICs outside his direct reporting line, co-authoring leveling guidelines with the Senior Director, shaping standards and rituals, and helping build the department's talent and operating model.
Improved pipeline fidelity by 50% and reduced cycle times by 60% through architectural improvements and process optimization
Reduced initial deployment failures by 80% through canonical data models and quality/observability standards
Delivered 90%+ of advertised roadmap commitments for 8 consecutive quarters across growth verticals
Built and scaled team from 0 to 6+ ICs, hiring senior-level talent and establishing team culture centered on psychological safety and distributed ownership
Mentored 3 engineers to Staff+ Analytics Engineer roles and developed leveling guidelines and performance review frameworks for career development discussions
Show all highlights99 more highlights
Delivered self-service data interfaces for 50+ direct and senior stakeholders, enabling 500+ downstream operators to access insights independently
Built measurement strategy for Peloton’s 50–150 owned retail locations across North America and select international markets, connecting 800k foot traffic, 200k leads, and 150k unit sales to downstream channel conversion, store openings/closures, staffing, compensation planning, inventory optimization, and pop-up vs. inline real estate strategy
Designed organizational data governance framework and defined canonical data models adopted by 50+ data professionals, eliminating siloed work and reducing operational failures across four cross-functional teams
Established data development standards, workflows, and tooling (including containerized development environment) that became organizational best practices across analytics and engineering functions
Fostered high-agency data culture across department of 40+ data professionals through enablement initiatives (weekly bookclub, tech debt days, modeling showcases, data glossary) that reduced onboarding friction
Delivered reliable, partner-facing insights and data points to enterprise partners including Lululemon, Hilton, Hyatt, YMCA, NBA, and F1, incorporating human-in-the-loop enrichment from partnership managers to improve accuracy, context, and usability
Led company-wide migration from Redshift to BigQuery, overseeing 15-30 external contractors and coordinating across Analytics, Marketing, Retail, and Finance while preserving platform stability and SOX-compliant data access
Partnered with Finance, Marketing, Ops, and Product leadership to define KPI methodology and A/B testing frameworks
Co-managed sensitive data transmission and access provisioning strategy ensuring SOX compliance
Data Engineer
Peloton Interactive
Designed and automated ELT/RETL pipelines and led cross-organization executive reporting initiatives.
Reduced delivery time from days to hours by automating ELT and RETL pipelines
Developed a containerized development environment adopted by 30+ data professionals
Co-created the Peloton History Summary product to reclaim revenue
Data Scientist / Lead Data Analyst, Analytics Center of Excellence
Brinks Home
Led analytics initiatives, built training programs, and implemented machine learning forecasting techniques.
Built and led cross-organization training programs to upskill analytics talent
Defined and managed enterprise data models in Azure
Co-led data warehousing initiatives transitioning from MSSQL to Databricks (Azure hosted)
Implemented machine learning forecasting techniques for workforce and sales predictions
Provided insights to executive leadership using Tableau
Recognized as 2020 Employee of the Year - Business Intelligence and Sales Operations
Data Analyst, Business Intelligence
Brinks Home
Automated reporting pipelines and implemented CRM data warehouse integrations.
Implemented CRM data warehouse integrations for Salesforce, HubSpot, and NetSuite
Automated reporting pipelines across operations, sales, and marketing teams
Administered centralized analytics systems (Databricks, Tableau, MSSQL, Alteryx) supporting 30+ data professionals; owned access provisioning, visualization optimization, and onboarding
Built SQL- and Tableau-based reporting with a focus on performance optimization and stakeholder enablement
Mentored and instructed analysts across the business, establishing documentation and knowledge-sharing standards
Education
Kansas State University
B.S. · Business Administration
Kansas State University
B.S. in Business Administration and Management · Analytics focus
Graduated 2020. B.S. in Business Administration and Management with a focus in Analytics.
Stories
Select a story (or press Enter) to expand the full STAR breakdown.
Instrumenting Engineering Velocity and Developer Experience with dbt
The models gave Wesley's org an evidence base — rather than anecdote — for engineering velocity, ramp-up, and tooling ROI decisions, and…
Near the end of his Peloton tenure (May–Oct 2025), Wesley's data organization had no structured visibility into where engineering work actually stalled or sped up — velocity conversations, ramp-up assessments, and tooling investment decisions were largely anecdotal, and there was no consistent way to identify which developers needed which kind of support.
Task
Wesley set out to build a data layer that could quantify engineering productivity and developer experience directly from the systems developers actually worked in — not survey-based sentiment, but instrumented behavior — to inform training priorities, tooling investment, and performance guidance.
Action
Wesley built dbt models across ticket, roadmap item, PR, commit, developer, and development-log objects, with the development-log layer specifically capturing dev container activity (utility usage, model run behavior, and similar low-level signals). Joining that dev-container telemetry against tickets, PRs, and roadmap items let the team track velocity shifts tied to specific dev-experience or process changes, rather than guessing at cause and effect. He extended the models to track ramp-up curves for new hires and per-model development speed, surfacing how individual developers' speed shifted as they moved in and out of different technical domains. That data justified deeper investment in specific tooling gaps and fed into clear performance buckets used to prioritize and guide individualized developer training.
Result
The models gave Wesley's org an evidence base — rather than anecdote — for engineering velocity, ramp-up, and tooling ROI decisions, and directly informed both training prioritization and the performance-calibration process he ran in parallel for the team.
Turning Peloton's Corporate Wellness Program into a Data-Driven Partner Retention Lever
Per Peloton's CW partner managers, the usage heuristics regularly had a material impact on renewal terms — including add-ons like employee…
Business AnalysisData IntegrationExperimentation DesignStakeholder Communication
Situation
Peloton's Corporate Wellness business offered Peloton as an employee benefit to 200+ partner companies, covering 100,000+ external employees. Peloton also ran a parallel internal program, P4P (Peloton for Peloton), extending the same benefit to Peloton's own ~3,000 employees. Both populations generated usage data (workout modality, frequency, challenge participation) that was valuable to partner account teams, Peloton's own People team, and the partners themselves, but none of it was packaged as a decision-support tool.
Task
Wesley's team owned the data side of this: ingestion, aggregation, and partner-matching logic feeding a formal analytics and reporting portal built jointly with the front-end engineering team, plus ad hoc analysis requested directly by the Corporate Wellness (CW) team and by Peloton's own People team around the P4P launch. The recurring, highest-stakes use case was arming CW's partner managers with usage heuristics ahead of contract renewal conversations.
Action
Wesley's team built the ingestion, aggregation, and partner-matching layer underneath the partner-facing analytics portal, giving each of the 200+ partner companies a usage view scoped to their own employee population. Beyond the standing portal, Wesley did ad hoc segmentation work — for example, surfacing that L8/VP+ level employees over-indexed on meditation and yoga modalities while operations-level employees over-indexed on outdoor modalities — patterns partner managers used directly in renewal conversations. The team also ran regular A/B tests on communications approaches for the CW population, including giving partner companies the ability to opt in or out of automated campaigns, and iterated on comms strategy directly with clients based on those results. On the internal side, Wesley supported the P4P launch and post-launch readouts for Peloton's own People team using the same usage-pattern lens applied to the ~3,000-person internal population.
Result
Per Peloton's CW partner managers, the usage heuristics regularly had a material impact on renewal terms — including add-ons like employee hardware discounts and in-office equipment, and changes to employer/employee subscription pay-splits. The work turned a benefits-usage dataset into a recurring input for B2B contract negotiations, not just a reporting artifact, while also giving Peloton's own People team the same lens on its internal program.
Migrating 300+ Legacy SQL Scripts to Databricks and Coaching a Team Through Modular Transformation Design
The migration moved 300+ scripts across three business domains onto modular, notebook-based transformation logic, with six team members…
Data EngineeringDatabase DesignDatabricksMentoringMicrosoft Azure
Situation
As Brinks Home moved off on-prem MSSQL as part of a broader Azure cloud migration, Databricks was selected as the new compute engine for the data warehousing and modeling layer. As the Lead Data Analyst on the Analytics Center of Excellence team, I was responsible for a substantial piece of this migration: 300+ legacy SQL scripts spanning acquisition, retention, and operations needed to move off giant monolithic script files and into a modern, notebook-based Databricks environment, scheduled through Azure Data Factory.
Task
Beyond my own migration workload, I needed to coach a group of six people — 2 Data Engineers, 3 Data Analysts, and 1 Data Scientist — through a real shift in how they wrote transformation logic: breaking giant, opaque SQL scripts into modular, traceable blocks inside Databricks notebooks, rather than porting the same monolithic pattern into a new platform. The goal wasn't just a lift-and-shift; it was raising the team's engineering standard for how transformation logic should be structured and understood.
Action
I personally migrated roughly 30 of the highest-priority scripts myself, concentrated in acquisition and customer-lifecycle domains, so I had direct, hands-on fluency with the platform rather than directing the work from a distance. That gave me the credibility and specificity to coach the rest of the team through the same pattern: breaking transformations into smaller, named, testable units instead of one continuous script, and thinking about compute provisioning and job scheduling as first-class design decisions rather than an afterthought.
Because this was our infrastructure to own end-to-end — not a shared on-prem SQL Server environment gated by a separate DBA team — I also had to reason directly about elastic compute costs and provisioning tradeoffs for the first time. I tracked and tuned compute and development costs against specific initiatives, balancing time-to-delivery against budget constraints in a way that wasn't possible when infrastructure decisions lived with a separate database administration function.
Result
The migration moved 300+ scripts across three business domains onto modular, notebook-based transformation logic, with six team members coached through the new pattern. Costs were not directly comparable to the prior on-prem environment — elastic compute isn't an apples-to-apples comparison against fixed on-prem hardware, and total spend actually increased — but we gained direct visibility into compute and development costs by initiative for the first time, which let us make explicit time-versus-budget tradeoffs that had previously been invisible. We also saw meaningful reliability gains from owning the infrastructure outright: no more contention or delays from a separate DBA team gating changes. This was also where I first coached engineers on treating transformation structure itself as a quality bar, a pattern I carried into later dbt and analytics-engineering standards work at Peloton.
First Hands-On PySpark: Rewriting Legacy Transformations for Distributed Processing
This was my first hands-on distributed-processing experience, and it directly shaped how I approached later data engineering and…
Apache SparkData EngineeringPython
Situation
During Brinks Home's migration off on-prem MSSQL onto Databricks (Azure-hosted), the ~30 legacy SQL scripts I personally migrated — concentrated in acquisition and customer-lifecycle domains — needed to move from single-threaded SQL Server transformations into a platform built around distributed processing. This was my first real exposure to PySpark, and I wasn't willing to coach other Data Engineers through a pattern I hadn't done myself.
Task
I needed to actually write PySpark for the transformations I owned, not just direct the migration from an architecture level, so that I understood the platform's distributed-processing model well enough to review other engineers' work credibly and coach them on structuring transformations as smaller, traceable units instead of monolithic scripts.
Action
I rewrote my ~30 scripts as PySpark transformations inside Databricks notebooks, learning the platform's distributed execution model hands-on — how partitioning, lazy evaluation, and DataFrame operations differed from the single-node, row-by-row mental model I'd built writing years of T-SQL. Because I was doing the work myself, I could give specific, credible feedback when reviewing the other Data Engineers' PySpark code during the broader migration, rather than offering only architectural direction from a distance.
Result
This was my first hands-on distributed-processing experience, and it directly shaped how I approached later data engineering and analytics-engineering work — including how I thought about transformation modularity and testability when I moved into dbt-based environments at Peloton. It also meant the coaching I gave the rest of the Brinks team on modular transformation design was backed by direct implementation experience, not just review authority.
Operating at Staff/Principal Engineer Scope While Serving as Senior Manager
The combined evidence supports a level claim that neither the management-only nor the engineering-only stories fully carry on their own: I…
Data EngineeringdbtLeadershipSystems ThinkingTechnical Leadership
Situation
At the time I left Peloton in October 2025, I held the title of Senior Manager, Data Analytics and Development. Titles at Peloton lagged scope consistently in my case — the same pattern that led to my Senior Manager promotion being announced 18 months after I was already operating at that level applied again on the engineering side. While I carried full people-management responsibility for a 6+ person team and department-level influence across a 30+ person data organization, I never stepped back from being the most technically load-bearing person on the team. I stayed the person other engineers, and other managers, routed the hardest architecture problems to.
Task
The claim I need the vault to support explicitly: for the back half of my Peloton tenure, I was simultaneously operating at Senior Manager scope on the people/org side and at Staff/Principal Engineer scope on the technical side — not as two separate part-time roles, but as one continuous mode of working where the management load never displaced the engineering load.
Action
The evidence for this is spread across several efforts I owned personally, hands-on, throughout my management tenure:
- **Codebase ownership at scale**: I remained the single heaviest contributor to Peloton's dbt codebase at departure — roughly 3x the volume of the next-highest contributor — while carrying full management responsibility. This is the most direct, quantified signal: a manager of my tenure is assumed to have drifted into pure coordination, and the commit-volume data says otherwise.
- **Systems architecture under real constraints**: I personally designed the technical strategy for the Redshift-to-BigQuery migration — tracer-bullet sequencing to surface the security review bottleneck early, adapter-selective SQL macros that avoided a company-wide dbt code freeze, and a three-tier validation framework (aggregate stats, row-level hashing, BI-layer reconciliation via the Looker API). These are Principal-level systems-design decisions, not program-management decisions, made under the pressure of a 30+ person org's active development continuing on a live environment.
- **Platform-level tooling built solo**: I was the primary contributor to Peloton's containerized dbt and Airflow development environments through nearly the end of my tenure, writing bash, Python, and small amounts of Rust and Go — tooling that cut dbt setup from 2-3 days to 5-10 minutes and Airflow setup from 2-3 weeks to 5-10 minutes, adopted voluntarily across 40-50 data professionals.
- **Reliability and observability architecture**: I designed and implemented the alerting, SLA, and on-call structure that extended accountability beyond data engineering to analytics engineers, analysts, and data scientists — a technical and process design that cut incident rates by 90% over 12 months.
None of this was legacy work coasting on a prior IC reputation. All four of these were live, load-bearing technical contributions during the period I was also running a team, sitting in leadership meetings, and building the department's talent and operating model.
Result
The combined evidence supports a level claim that neither the management-only nor the engineering-only stories fully carry on their own: I did not choose between staying technical and becoming a manager. I did both concurrently, at a standard each would be independently evaluated against — heaviest codebase contributor by volume, principal-level systems design on the highest-stakes migration in the department's history, and platform tooling built and maintained solo. This is the direct answer to the question of what I was actually doing in the final two years at Peloton: Senior Manager on paper, Staff/Principal Engineer in practice, at the same time, without either side being the token effort.
Hand-Rolling Reliability into Informatica Cloud on the Member Support Pipelines
The pipeline ran reliably despite the platform, and I came out the other side with a much sharper, first-hand appreciation for developer…
This was my first project as a Data Engineer at Peloton. I joined a relatively new embedded data and analytics team supporting Member Support, brought in as extra muscle for an existing Data Engineer who had already built a series of Python scripts handling the team's data pipelines. The mandate was to first push those scripts into AWS Glue (strictly as a Python runner), then migrate the whole thing to Informatica Cloud — including file listeners, archiving processes, sentinel mechanisms, reliability checks, light anomaly testing, and loading into a dedicated Redshift database. No dbt, no modern orchestration, very limited tooling flexibility.
Task
I needed to stand up production-grade reliability, alerting, and anomaly detection on this pipeline using Informatica Cloud — a platform I did not choose and did not like working in. I already understood the mechanisms I was implementing (I wasn't new to reliability engineering or alerting design); the challenge was building them inside a clunky, low-code-first UI that crashed constantly, resisted integration with other tooling, and put me in a contractor pool rather than working with internal Peloton engineering resources.
Action
I pushed through it. That meant late nights, holidays, and occasional weekends getting the pipeline to a stable state within Informatica's constraints. Since the platform forced almost everything through its web UI, I wrote a Python script to hand-roll some of the Informatica artifacts myself rather than build them by hand in the UI every time — a workaround, not a fix, but it bought back some control and repeatability. I implemented the reliability, sentinel, and anomaly-detection mechanisms as designed, just constrained by what the tooling would actually let me do. Parquet was the intermediate file format for the archiving and Redshift-load handoff, giving the pipeline schema enforcement and columnar efficiency between the AWS Glue and Informatica stages rather than relying on flat, untyped file dumps.
Later, once I'd built deep familiarity with more modern practices (Airflow, Airbyte) and a strong internal reputation, I led the migration off Informatica entirely — dismantling the same system I'd helped stand up. I was the last remaining person on the team who'd been there for the original build, so I knew exactly where the fragile points were.
Result
The pipeline ran reliably despite the platform, and I came out the other side with a much sharper, first-hand appreciation for developer experience — not as an abstraction, but as something I'd felt the cost of directly. That contrast shaped how I think about tooling as a leader: I generally believe tool-independent skillsets are more valuable long-term, but this project taught me there's a floor — bad enough tooling can slow down even strong engineers, no matter how well they understand the underlying mechanisms. I carried that into how I later evaluated and pushed for better platform choices once I had the influence to do so.
Remaining the Heaviest Hands-On dbt Contributor While Leading the Team
At his departure in October 2025, Wesley was the single heaviest contributor to Peloton's dbt codebase — roughly 3x the volume of the…
As a player-coach Senior Manager at Peloton, Wesley led a 6+ person analytics and analytics-engineering team while the canonical dbt codebase remained the backbone of the department's models. The common failure mode for managers at this level is to stop writing production code and drift into pure coordination, which erodes both technical credibility and the ability to set standards by example.
Task
Keep the canonical dbt / analytics-engineering layer healthy and moving while carrying a full management load — setting standards by doing the work, not only reviewing it.
Action
Wesley kept contributing production analytics-engineering work throughout his management tenure. He personally authored core dbt infrastructure, including the adapter-selective SQL macros that made models platform-agnostic during the Redshift-to-BigQuery migration (avoiding a code freeze), and the custom dbt utilities shipped in the containerized development environment — mass linting, changed-file testing, development-schema management, downstream builds, and pre-PR validation hooks. He set and enforced model-layering, naming, testing, and refresh standards, and continued shipping production models across growth domains while mentoring and reviewing his team's work.
Result
At his departure in October 2025, Wesley was the single heaviest contributor to Peloton's dbt codebase — roughly 3x the volume of the next-highest contributor — while simultaneously carrying full people-management responsibility. This demonstrates sustained Staff+-level hands-on analytics-engineering output layered on top of a management role, directly countering the assumption that a manager of this tenure is no longer close to the code.
Closing the Accountability Gap: Building Observability Across Peloton's Full Data Stack
Over approximately 12 months, incident rates fell by 90%. SLA violations in executive reporting dropped from roughly 5 per month to fewer…
At Peloton, on-call coverage existed only for the data engineering team — the layer responsible for infrastructure and ingestion. Analytics engineers, analysts, and data scientists operated without on-call accountability, meaning that downstream failures triggered by late-night PRs or unvetted model changes all routed back to the data engineering team regardless of root cause. Wesley had been on the receiving end of this as a data engineer himself: the team absorbing blame for incidents they did not cause, while the teams whose changes triggered the failures had no direct exposure to the consequences. Alerting mechanisms were poor, runbooks were absent, and there was no structured process for incident handoffs, triage, or retrospectives. The result was a cycle of reactive firefighting, misattributed blame, and low incentive for downstream teams to invest in testing or careful deployment practices.
Task
In his management role, Wesley chose to correct the accountability gap. The goal was not just to build an observability practice for its own sake, but to connect the people making changes with the consequences of those changes — structurally, culturally, and operationally. The scope covered production data products with significant business stakes: the marketing communications pipeline, external-facing member products including the Peloton History Summary, models supporting shareholder readouts, accounting processes, and high-caliber executive reporting.
Action
Wesley extended on-call ownership downstream of data engineering, bringing analytics engineers, analysts, and data scientists into the accountability model for the first time. He built and implemented alerting mechanisms to surface failures earlier and with more context. He created triage runbooks so on-call responders could diagnose and escalate efficiently without tribal knowledge. He instituted SLA management with explicit targets — particularly for executive and shareholder-facing data products where violations had direct business consequences.
He led structured weekly handoff calls and retrospectives that gave on-call responders continuity, surfaced recurring failure patterns, and created a feedback loop between incident experience and engineering practice. This structure had compounding effects: teams that now owned on-call consequences began investing more heavily in testing before merging, CI/CD practices improved, and the devcontainer initiative gained additional momentum as a shared development standard.
The observability practice was deliberately designed to improve behavior upstream, not just respond to failures downstream.
Result
Over approximately 12 months, incident rates fell by 90%. SLA violations in executive reporting dropped from roughly 5 per month to fewer than 1 per month on average. Mean time to resolution improved as runbooks and handoff context gave on-call responders a clearer starting point for triage. The cultural shift was equally significant: accountability for production changes spread across the full data org, late-night unreviewed PRs became less common, and testing practices improved across analytics engineering and data science. The observability initiative reinforced and accelerated several parallel investments — CI/CD maturity, devcontainer adoption, onboarding quality — that collectively raised the reliability bar for Peloton's data function.
Accelerating a 3-Person Dev Team from Cautious AI Experimentation to 20x Throughput
Progress was measurable both quantitatively — GitHub metrics and Claude consumption data showed consistent, increasing adoption and…
Situation
Gastown, a three-person Austin-based startup, had done light experimentation with agentic development but had not moved beyond chatting with Claude in the CLI or using Cursor's built-in tooling. The CTO — one of three developers — recognized the team needed to move meaningfully faster and reached out. The core problem was not access to the tools; it was trust, workflow design, and the strategic thinking required to leverage agentic development as a genuine multiplier rather than a novelty.
Task
Wesley was engaged as an embedded technical advisor to help the team adopt agentic development practices with enough depth and confidence that they could operate independently afterward. The engagement needed to address trust, workflow design, planning patterns, and team collaboration dynamics — not just tool setup.
Action
Wesley structured the engagement in phases that built on each other.
The first priority was trust. This came through guided exposure to Claude Code in real work contexts, practical guardrails (creating environments that constrained the agent appropriately, implementing CI testing to catch regressions), and coaching developers to ask the agent clarifying questions during execution rather than treating its output as a black box.
Once the team had baseline confidence, Wesley shifted to the strategic bottlenecks: planning and parallelization. With development time suddenly something that could run in the background, the old single-threaded working model was a ceiling. Wesley helped the team redesign how they broke up work — identifying tasks that could run in parallel, optimizing for tight iteration loops, and building an experimentation mindset into the process.
The final phase addressed the collaboration model itself: not just human-AI collaboration, but how the three developers worked with each other given their new capacity. Wesley helped them develop visibility into where they were getting stuck, what sequencing decisions mattered, and how to maintain strategic coherence while parallel workstreams ran simultaneously.
Result
Progress was measurable both quantitatively — GitHub metrics and Claude consumption data showed consistent, increasing adoption and throughput — and qualitatively, through conversations in which team members described growing confidence and reduced second-guessing. The CTO estimated the engagement had produced a 20x improvement in team throughput. More importantly for longevity, the team could operate independently: they could see their own bottlenecks, knew what to do next, and had a working model for AI-assisted collaboration that did not depend on Wesley's continued presence.
Leading Peloton's Redshift-to-BigQuery Migration at Enterprise Scale
The migration completed with a clean cutover. Incident rates during the migration were not elevated above the pre-migration baseline — a…
Peloton's data infrastructure had hit the ceiling of what Redshift Serverless could reliably support. The platform's scaling model addressed query volume, not query complexity — as Peloton's analytics estate grew more sophisticated, jobs were timing out and failing under load in ways that couldn't be resolved by adding concurrency. Cost pressure compounded the reliability problem, and BigQuery's capabilities opened options, particularly around ML integration and analytical workload handling, that Redshift couldn't match. The migration was ultimately greenlit as part of a broader strategic consolidation: Peloton wrapped the BigQuery commitment into a GCP minimum-spend contract that also covered Looker and Gemini, making the business case straightforward.
By the time the migration was scoped, Peloton's enterprise data estate had grown to 2,500+ dbt models across legacy and modern repos, 300+ Airflow orchestration jobs, and 500+ Looker dashboards. The migration needed to move code (dbt, LookML, Airflow), archival data and its transmission and ingest mechanisms, the full BI layer, and downstream consumer systems — all without disrupting active development across a 30+ person data organization. Wesley was the technical lead for the code migration and co-led the data, BI, and consumer migrations. To execute at scale, Peloton brought in 15–20 contractors.
Task
Wesley needed to architect and sequence the migration without halting development velocity, navigate Peloton's internal requirements (including security and privacy approvals that weren't yet cleared), and set contractors up to execute effectively without becoming a bottleneck himself. Scale wasn't the primary challenge — sequencing was. A wide, sequential approach (ingest first, then all dbt models, then transformation jobs) would have been too slow, too brittle, and too likely to surface blockers at the worst possible moment.
Action
Wesley's first structural decision was to reject the sequential approach in favor of tracer bullets. Rather than migrating whole categories of work in order, the team would shoot narrow end-to-end paths through the stack — proving out the full pipeline, identifying blockers, and clearing internal requirements before the contractor pool was brought in to scale execution.
This sequencing decision paid off immediately at the most dangerous bottleneck: security sign-off on the data migration mechanisms. By surfacing this through an early tracer rather than discovering it mid-migration, the team was able to run the security and privacy review process in parallel with other migration work, rather than having it gate the contractor effort entirely.
On the dbt side, Wesley made an architectural decision that avoided a hard code freeze. Rather than treating platform-specific SQL as a migration problem to be solved later, dbt models were converted to platform-agnostic SQL by masking all Redshift-specific functions behind custom macros with adapter-selective logic. The macros resolved dialect differences at compile time, so developers could continue active development throughout the migration without a code freeze — one of the most common velocity killers in large warehouse migrations.
The dual-write approach was kept deliberately simple: incremental loads from Redshift to BigQuery ran continuously until the hard cutover date, staged through Parquet files for the transfer — which gave the pipeline schema enforcement and columnar efficiency during handoff — and landed via BigQuery MERGE statements so incremental batches could be applied idempotently without full-table rewrites. Wesley also used BigQuery's native time-travel windows during validation, comparing table states across specific points in time to isolate exactly when a discrepancy between platforms was introduced, rather than only comparing current-state snapshots. Rather than engineering a complex synchronization layer, Wesley preserved complexity budget for the validation framework.
Validation ran in three explicit passes. First, aggregate statistics: column counts, means, sums, and distributions for numerical and categorical columns across tables. Second, row-level hash validation to confirm individual records matched between platforms. Third, BI-level validation via Looker's API, confirming that major metrics tied out at the dashboard and report layer — the surface stakeholders actually interacted with. The three-tier design meant discrepancies could be caught and diagnosed at different granularities rather than surfacing as an ambiguous "numbers don't match" problem during cutover.
Wesley managed the contractor pool directly throughout, keeping them unblocked by running tracer bullets ahead of their work and clearing internal requirements before they could slow execution. The final 20% of the migration — non-critical-path models and pipelines — was handed off to the team upon his departure from Peloton in October 2025.
Result
The migration completed with a clean cutover. Incident rates during the migration were not elevated above the pre-migration baseline — a meaningful outcome given that active development continued against a live environment throughout. Developers moved onto BigQuery without loss of velocity, in part because the macro-based SQL abstraction had removed the platform dependency from the dbt layer before the cutover landed.
The tracer bullet sequencing was critical to the timeline. Early discovery of the security bottleneck prevented it from becoming a mid-migration gate on contractor execution. The three-tier validation framework, backed by time-travel comparisons and Parquet-staged MERGE loads, gave the organization confidence at every layer of the stack — from raw table contents to the executive dashboards built on top of them — and eliminated the ambiguity that commonly makes post-cutover incident diagnosis slow and painful.
Building Peloton’s Containerized Analytics Development Environment
The development environments reduced dbt setup time from two to three days to roughly five to ten minutes, and reduced Airflow setup time…
Peloton’s data and analytics development work was split across three major tool-centric tranches: Airflow, dbt Core, and Looker. Airflow and dbt development required users to install dependencies and configure local environments through scattered documentation, operating-system-specific keywords, and copied shell commands. Environment setup was fragile, inconsistent, and time-consuming. New users often needed two to three days to get a dbt environment fully running and two to three weeks to get a working Airflow environment.
This created onboarding friction, developer downtime, troubleshooting inconsistency, and slow development cycles. Each developer’s local machine could fail in different ways, which made it hard for teammates to help each other. The organization needed a more reliable shared starting point for analytics and data engineering development, but there was no mandate to build one.
Task
Wesley set out to build a containerized development environment that reduced onboarding friction, improved environment reliability, and sped up development cycles for Peloton’s data organization. The goal was not only to make setup easier, but to create a shared developer substrate: common diagnostics, common linting and testing commands, common dependency versions, common troubleshooting patterns, and a fast distribution mechanism for new utilities.
The work needed to support both dbt and Airflow development while remaining useful enough that developers would adopt it voluntarily. Wesley built it as a product he would have wanted for himself, with the expectation that it would still be worthwhile even if nobody else chose to use it.
Action
Wesley was the primary contributor for the containerized development environments until the final months of his tenure at Peloton. He wrote bash, Python, and small amounts of Rust and Go to build the tooling and developer workflows.
The dbt development container included dbt Core, the appropriate database adapters, linters, and custom shared utilities. Those utilities supported workflows such as mass linting, development schema management, changed-file testing, and downstream builds. Wesley also added suggested pre-hooks that developers could turn on or off for pre-PR validation.
The Airflow development container included Peloton’s production Airflow dependencies and supported a locally hosted, full-fat Airflow deployment running against additional containers. It also included Python linters, YAML validation, and cloud-storage access tools. This gave developers a much more realistic local environment for testing DAGs and related orchestration work.
The onboarding workflow became a few simple steps: install Git, install Docker, install VS Code, authenticate GitHub, clone the devcontainer repo, start the container, and run the diagnostic tool. Wesley also implemented version-update mechanisms so that as new tools or dependency changes rolled out, users were notified and nudged to update when ready. This distribution mechanism paid off repeatedly, including for LLM tooling such as Claude Code, dbt adapter repointing during the Redshift-to-BigQuery migration, and major dependency updates.
The containerized environment also became a sandbox for other developers to build and share internal tools. For example, one developer built a local tool for testing the distribution of dates across intervals. The team baked that utility into the container configuration and delivered it back to the broader data organization in less than a week.
Result
The development environments reduced dbt setup time from two to three days to roughly five to ten minutes, and reduced Airflow setup time from two to three weeks to roughly five to ten minutes. Common tooling and a common starting state significantly decreased developer downtime because troubleshooting became easier and teammates could reason from the same environment.
The environments were gradually adopted across the full 30+ person data organization and expanded to another 10–20 embedded data professionals across business verticals. Adoption happened without a mandate because the product solved real developer pain.
The broader result was a Staff+ style multiplier: Wesley created tooling that made other data professionals faster, more reliable, and more consistent. Frequent testing became easier, so developers tested more often. Versioned distribution made it easier to roll out new tools, adapters, and dependency changes. The containerized environments turned ad hoc local setup into a shared analytics engineering platform that improved onboarding, development speed, debugging, and standards across Peloton’s data function.
Using Skill Shapes to Correct Title Bias and Align an Analyst to Data Science Work
The IC’s title was changed in-seat from Data Analyst to a title aligned with their data-science-shaped work. There was no org move and no…
Data AnalysisData VisualizationJudgment and Decision MakingLeadershipManagement of Personnel ResourcesMentoringPerformance Management
Situation
Peloton’s data organization used titles such as Data Analyst and Data Scientist, but Wesley did not view those titles as rigid boundaries around the work a data professional could or should perform. Reporting, warehousing, experimentation, pipeline development, statistical analysis, and stakeholder decision support often cut across titles. A Data Scientist at one company might look like a Data Engineer at another, and a Data Analyst in one context might be doing work that closely resembles another company’s data science role. Because titles carry organizational and market biases, Wesley focused instead on skill shapes, responsibilities, duties, and interests.
Within Peloton’s evidence-based talent calibration system, one IC held the title of Data Analyst but did not closely resemble the analyst archetype visible in the department’s calibration data. Most analysts spent substantial time on reporting, dashboard development, and contributions to the data warehouse. This IC, however, spent significantly more time on statistical analysis, modeling, and thesis-style white papers. Their work shape did not align tightly with their title cohort, but it aligned closely with the department’s Data Scientist cohort.
Task
Wesley needed to use the calibration framework to evaluate whether the IC’s title still reflected the shape of their actual work. The goal was not to force a handoff between job families or build walls between titles. Instead, the task was to compare the IC’s radar-chart shape, time allocation, responsibilities, duties, interests, and work artifacts against peer archetypes across the data organization.
The situation also mattered culturally. Showing that lateral movement was possible was important for the agency component of Peloton’s data culture. If the department wanted ICs to pursue work that matched their strengths and growth trajectory, leadership needed to show that titles could be corrected when the evidence supported it, rather than forcing people to remain inside a title simply because that was where they had started.
Action
Wesley used the department’s objective calibration system to compare the IC’s skill shape against analyst and data scientist peer groups. The evidence included the IC’s radar chart, their allocation of time across different work types, and their actual artifacts — especially white papers and statistical modeling work. Those artifacts separated the IC from the analyst cohort more clearly than title-based assumptions ever could.
Rather than treating the issue as a promotion case or an organizational transfer, Wesley framed it as a title-alignment problem. The IC was not necessarily moving into a new organization or taking on a new job because leadership wanted to reward them with a promotion. They were already doing work that aligned with a different archetype, and the title needed to catch up to the work.
Wesley worked directly with the VP, bringing objective, data-driven evidence and work artifacts to the conversation. The VP agreed with the case. The argument was grounded in the same philosophy that shaped the broader calibration framework: titles should not be treated as proof of capability, and talent systems should evaluate actual skill shapes, responsibilities, duties, and interests rather than assuming that each title maps cleanly to one kind of work.
Result
The IC’s title was changed in-seat from Data Analyst to a title aligned with their data-science-shaped work. There was no org move and no formal promotion in the traditional sense; it was a lateral correction based on evidence. The title change came with an approximately 10% compensation increase.
The move also sent an important cultural signal to the rest of the department. Lateral movement was possible. Career paths did not have to be constrained by a starting title, and leadership was willing to recognize when someone’s actual work shape, responsibilities, duties, and interests had diverged from their current label.
The broader leadership lesson was that title bias shows up both in action and in inaction. Leaders can either interrogate inherited titles and correct misalignment where the evidence is clear, or they can prioritize other problems and leave people mislabeled. The answer is not simple, because rebuilding every title assumption from the ground up can consume enormous organizational energy. But this case showed that an evidence-based talent system can reveal when a title is no longer serving the person, the team, or the organization.
Building Peloton’s Evidence-Based Data Talent Calibration System
The department created a reference document for leveling guidelines, performance review templates, modified hiring rubrics, coaching and…
Data AnalysisData VisualizationHiringJudgment and Decision MakingLeadershipManagement of Personnel ResourcesMentoringOrganizational DevelopmentPerformance Management
Situation
Peloton’s enterprise data organization had grown into a 30+ person department, but many talent decisions were still vibes-based rather than evidence-based. Managers had different standards for technical competency, promotion readiness, and performance expectations. Wesley held a high technical bar rooted in engineering and advanced analytics, while some peer managers came from management or BI backgrounds and used different standards. This created inconsistent hiring signals, loose promotion criteria, and mistrust in the promotion process.
The ambiguity affected both managers and ICs. Promotions could trigger backlash from other ICs who did not understand why someone had advanced, even when the promotion seemed obvious to management. Leaders lacked a shared language for what performance meant, how to measure it, how to compare expectations across titles, how to hire against team needs, and how to guide IC career development across Data Analytics, Data Science, Analytics Engineering, and Data Engineering.
Task
Wesley needed to help move the department from informal, manager-specific judgment toward a more objective talent calibration system. The work needed to create shared leveling expectations, review templates, hiring rubrics, coaching rituals, and calibration practices that could support fairer performance conversations, clearer promotion cases, better hiring decisions, and stronger org-level talent planning.
A key philosophical and analytical challenge was whether performance ratings should be relative to title or objective across the department. Some peers argued that a 5 for a Senior Analyst should represent a higher skill level than a 5 for a non-senior Analyst. Wesley pushed for objective ratings independent of title, arguing that objective ratings could later be interpreted relative to level, but starting with relative ratings would eliminate visibility into true progression over time.
Action
Wesley worked on early iterations of the leveling guidelines with another Senior Manager of Data Analytics and the Senior Manager of Data Engineering. After his new boss, the Director of Data Analytics, took over, Wesley and the Director finalized the leveling guidelines across Data Analytics, Data Science, Analytics Engineering, and Data Engineering, with sponsorship from the VP and collaboration across departmental leadership.
The framework defined categories across both technical and soft-skill dimensions. Technical categories included Data Platforms and Orchestration, Data Observability, Standards, Debugging, and Programming. Soft-skill categories included Scope, Analysis, Project Management, Methodology, Communication, Documentation, Leadership, Training, and Feedback. Department leadership then held recurring six-month calibration sessions where managers rated ICs from 1 to 10 in each category, with 1 representing extremely poor or non-existent capability and 10 representing the feasible upper bound of human performance in that skill. Managers discussed the ratings as a group, presented evidence, and calibrated where the bar should be.
Wesley pushed the department toward objective, evidence-backed ratings rather than title-relative ratings. With VP support and several cycles of calibration, the department established a clearer shared standard. Wesley then created strong visualizations, analytics, and scorecards to support managers and ICs in performance conversations. The primary IC-facing visual was a radar chart with a 0–10 score for each category, showing the most recent rating, previous rating, level-peer average, title-peer average, department average, and team or pod average. For leadership, the system included heatmaps to identify high and low performers quickly, along with per-category and cross-department deltas so managers could focus on where someone was falling behind relative to the team rather than simply targeting the lowest-scored category.
The same framework also improved hiring and org planning. Once objective, peer-reviewed ratings existed, managers could inspect aggregate team composition and identify where the group needed investment. If the average score for a category such as orchestration was low but one individual clearly rated higher, that person could help lead upskilling. In hiring, Wesley used the framework to understand his team like a puzzle with a missing piece: he looked for candidates who brought strengths the team lacked, had capabilities he could not easily teach, and also had enough aptitude to grow into the areas where the team was already strong. The framework overlapped with roadmap plans and stakeholder demand to shape applicant expectations rather than simply doubling down on existing team strengths.
Result
The department created a reference document for leveling guidelines, performance review templates, modified hiring rubrics, coaching and calibration rituals, and a framework for org-level talent analytics. Performance conversations with ICs became more constructive, leaders had better common ground for discussions, and faith in the promotion process was more broadly restored.
The framework helped push through four promotions that had stalled in previous quarters due to misalignment in expectations. It armed the VP with direct evidence to prove growth and team-level shortfalls rather than relying on vague manager advocacy. It also enabled cross-title movement: the department had clear, objective evidence that one analyst was performing in the same capacity as data scientists, allowing leadership to align that person’s title with their actual scope and capability.
The broader result was that Peloton’s data organization gained a more evidence-based talent operating system. Leaders could calibrate performance more consistently, ICs could see clearer growth paths, hiring could target missing team capabilities, and promotion conversations could be grounded in visible evidence rather than individual manager intuition.
Pushing Peloton from Promo Redemptions Toward Incrementality Measurement
The work improved Peloton’s promotional measurement discipline across roughly 100 offers and promotions during Wesley’s period of…
AttributionBusiness AnalysisCausal InferenceChange ManagementData AnalysisExperimentation DesignJudgment and Decision MakingMetrics DesignStakeholder Communication
Situation
Peloton’s promotional analytics culture often treated redemptions, promo-period sales, and broad channel performance as if they were equivalent to incremental lift. Teams assumed sweeping impact for promotions even when redemption paths would not necessarily result in a discount being applied, when customers could qualify for an offer without receiving or using it, or when competing evergreen discounts from sources such as Corporate Wellness employer benefits could explain conversion behavior. In many cases, stakeholders wanted to claim that all conversions during a promotional period were caused by the promotion, or that a user who merely might have seen a promotion in an email subject line or social post should be counted as influenced by that promotion.
This created a measurement problem and a business-behavior problem. Peloton had a fixed promotional rhythm where holidays and recurring promo periods were treated as mandatory: if the company ran a promotion on a holiday in a prior year, teams assumed it had to be run again. That mindset made it difficult to test whether promotions were actually creating new demand, pulling expected demand forward, subsidizing customers who would have purchased anyway, or training prospective members to wait for the next discount.
Task
Wesley needed to help move Peloton’s promotions measurement from redemption counting and broad promo-period correlation toward incrementality analysis. The work needed to distinguish actual lift from redemptions, eligibility, offer exposure, competing discounts, cannibalization, pull-forward, and ordinary purchase behavior. It also needed to help teams understand user state before, during, and after promotional periods so offers could be evaluated against the revenue behavior they were intended to change.
The analytical challenge varied by offer structure. Some offers had large addressable pools, making a clean holdout impossible; in those cases, the team had to reason from eligible users versus redeemers and from pre/post behavior. Other campaigns allowed stronger experimentation through randomized holdouts, geographic splits, A/B testing, offer-version comparisons, or discount-depth comparisons. The work also needed to account for different user cohorts, such as net-new leads, existing leads, existing members, previous members, recent churn, stale churn, and customers upgrading from cheaper to more expensive subscriptions.
Action
Wesley used pre-, during-, and post-promotion user-level statuses as the cornerstone of offer-incrementality measurement. He connected offer eligibility, exposure, redemption, purchase behavior, subscription status, lifecycle stage, prior ownership, churn status, lead freshness, and related Customer 360 attributes to understand what state a user was in before an offer, what happened during the promotional period, and what changed after the period ended. For winback campaigns, this helped distinguish recent churn from older stagnant churn. For first-sale campaigns, it helped distinguish fresh leads from stale leads. For upgrade-oriented offers, it helped track movement from lower-value subscriptions to higher-value subscriptions.
Where possible, Wesley pushed for proper holdout mechanisms and A/B testing, often using randomized cohorts with representative geographic splits. Depending on the campaign, the analysis compared exposed users against held-out users, redeemers against eligible non-redeemers, different discount depths, different offer versions, and pre/post windows. He also evaluated cannibalization and pull-forward when offers appeared to accelerate purchases customers were likely to make anyway or shift demand from full-price behavior into discounted periods.
The metric set went beyond redemption rate. Wesley and the team assessed conversion lift at the offer level, revenue recognition, AOV, margin proxy, attach rate, subscription retention, churn, refund or return behavior, and cohort shifts across net-new leads, existing leads, existing members, previous members, and upgrade populations. Because conversion lift was not always available as an out-of-the-box metric, it was often assembled manually from the canonical offer redemptions model, customer state, order/subscription behavior, and cohort analysis.
Wesley also had to push back on overbroad attribution claims. Some stakeholders argued that even users who did not receive the value of an offer might still have been influenced by seeing a subject line, social post, or general campaign presence, and therefore the promotion should receive credit for all conversions. Walking teams down from that claim was difficult, especially while the promotional calendar was treated as fixed. The argument became easier once external pricing-strategy work, including McKinsey’s involvement, backed recommendations to test promo cadence and discount assumptions more rigorously.
Result
The work improved Peloton’s promotional measurement discipline across roughly 100 offers and promotions during Wesley’s period of influence. Teams made fewer overclaims, promo reporting turnaround tightened, implementation planning improved, and discount-depth decisions became more evidence-based. Promotion reporting increasingly separated redemption from incrementality and made room for cannibalization, pull-forward, competing offers, and user state.
One of the most important outcomes was proper experimentation with holiday promotions. A key recommendation was to skip selected holidays rather than automatically repeating every prior-year promotion. In those tests, Peloton matched or beat revenue expectations from “with promo” forecasts, partly by creating a real sense of urgency for prospective members rather than reinforcing the belief that they could simply wait for the next holiday to buy at a lower price.
The broader result was that Peloton began treating offers less like isolated discount events and more like testable business interventions. The work helped shift promotion strategy toward better causal discipline: who was eligible, who redeemed, who would have converted anyway, which behaviors changed, which cohorts moved, and when a discount actually created incremental value instead of merely claiming credit for demand that already existed.
Building Peloton’s Canonical Offer Redemptions Model
The model gave Peloton a canonical source of truth for offer redemptions across promotional mechanisms, markets, products, users, orders,…
AttributionBusiness AnalysisData AnalysisData IntegrationData ModelingData QualityStakeholder Communication
Situation
Peloton had many mechanisms for promotional discounts and redemptions, but no centralized business concept of an “offer.” Partial offer-redemptions-like models existed in the Corporate Wellness / B2B domain for subscription and hardware discounts with partner attribution. Coupon codes appeared in order models, and subscription discounts appeared in subscription models. Other promotional mechanisms existed through access codes, discount codes, discounted SKUs, subscription SKUs, bundle SKUs, sales-channel-specific logic, and other disconnected implementations.
The problem was that these artifacts described discount mechanics, not the offer itself. Peloton lacked consistent metadata about the promotion, targeting, applicable geography, qualification rules, related products, term length, redemption mechanism, offer grouping, or how long a user, subscription, or order would carry a discount. The business often only knew that a discount had occurred, such as “$X off,” without reliable attribution to why it existed, where it came from, which offer it belonged to, or how it related to other promotions.
This made promotional measurement fragile. There was no inter-promo attribution, no reliable understanding of multi-step promotional offers such as 15% off month one and 5% off month two, and no consistent way to understand a user’s state before, during, or after a promotional period. The business could make broad claims like “we ran a promo January 1–15 and total sales were Y, therefore the promo caused Y,” but that logic could not distinguish eligibility, advertised value, actual redemption value, customer state, order attribution, or downstream behavior.
Task
Wesley needed to create the missing semantic and analytical layer for promotional offers. As an army of one from June 2023 through May 2025, when he hired a new Data Analyst to help steer promotional analytics, he was responsible for the architecture, modeling, stakeholder translation, and source-of-truth design for offer redemptions.
The work needed to catalog historical offers and sub-offers, unify redemption mechanisms across all sales channels, separate advertised discount value from actual system redemption value, and give marketing, promotions, finance, pricing, ecommerce, retail, commercial, and D2C stakeholders a trusted way to analyze promotional activity. “Done” meant creating a canonical model that could explain what an offer was, how it was redeemed, which users/orders/subscriptions/items it touched, where it applied, and how it could be analyzed against broader business metrics.
Action
Wesley cataloged 500+ offers and sub-offers stretching back to 2021, covering 2M+ orders and subscriptions, 1M+ users, all major geographic markets — including the US, Canada, the UK, Germany, and Australia — and every Peloton sales channel, including commercial, D2C, ecommerce, and retail.
He designed the offer dimension as Peloton’s centralized registry for the business concept of an offer. The dimension captured offer metadata such as offer, offer type, related products, offer start, offer end, redemption mechanism, qualifying geographies, and offer group for related or interconnected promotions. This made it possible to reason about promotions as business objects rather than isolated discount artifacts scattered across operational systems.
He also designed redemption facts and mappings for 15 distinct, sometimes competing redemption mechanisms, including coupons, promo codes, access codes, discount codes, discounted SKUs, subscription SKUs, bundle SKUs, sales channels, and related mechanisms. The redemption fact used one row per redemption, but the grain varied by mechanism: in some cases one row represented a user redemption, in others a subscription redemption, order redemption, or order-item redemption. Required fields included redemption timestamp, offer ID, and user ID, while order ID, order item ID, and subscription ID were optional at the unified fact level but required in upstream models when the associated mechanism depended on them.
A key part of the work was identifying and preserving the difference between advertised promotional value and actual redemption value in Peloton’s systems. Wesley surfaced failure points where users appeared to qualify for a discount but were never sent the code, were sent the code but never applied it, applied the code without qualifying cart contents, or encountered implementation differences across teams. Because there was not one consistent implementation team for promotions, learnings from one offer did not automatically transfer to the next. Wesley increasingly pushed teams to consider prior implementations and known failure modes before launching new offers.
Result
The model gave Peloton a canonical source of truth for offer redemptions across promotional mechanisms, markets, products, users, orders, subscriptions, and sales channels. Marketing and the promotions team used it to understand promotional activity more coherently, while finance used it for deeper attribution and promotion-level forecasting versus actuals performance. It also enabled the business to analyze take rates, redemption behavior, offer periods, order attribution, related promotional groups, and gaps between advertised and actual redemption mechanics.
The work changed the business from treating promotions as disconnected discounts to treating offers as measurable business objects. It made previously unanswerable questions possible: which offers were active, which mechanisms redeemed them, which users or orders were affected, which channels carried the promotion, which geographies qualified, how related sub-offers fit together, and where implementation gaps caused advertised value to diverge from actual redemption.
When Peloton later brought in McKinsey consultants to support broader pricing strategy, enough internal stakeholders pointed them to Wesley’s offer redemptions work that the model became their historical source of truth. The consultants partnered deeply and directly with Wesley on offer categorization, historical promotional periods, associated metrics, and swings in correlated business measures because every other source was too disparate to support coherent pricing analysis.
Building Peloton’s Lifecycle Measurement and Experimentation Operating Model
The operating model supported more than 1,000 distinct campaigns across winback, onboarding, cross-sell, upsell, retention, partner…
AttributionCausal InferenceChange ManagementData AnalysisData ModelingExperimentation DesignMetrics DesignStakeholder Communication
Situation
Peloton’s lifecycle and onboarding marketing teams had a measurement and decision-making problem. Campaign strategy relied on legacy definitions, messy segmentation, loose communications-related attribution, and a persistent “we’ve always done it this way” mindset. Marketers often struggled to define the behavioral change they expected from a campaign in a repeatable way, understand long-term communications engagement, compare historical trends, or estimate expected conversion rates at both the customer and campaign level.
Braze and other native platform reporting could show surface-level communications metrics, but Peloton needed a stronger operating model for connecting campaigns to actual customer behavior. The business wanted deeper insight into funnel performance and campaign impact, but there was tension around attribution. Some marketing stakeholders wanted to claim credit for any behavioral shift among users who received an email, even when those users did not open or click it, arguing that there was no way to know whether someone saw the email in their inbox and changed behavior anyway. This created a risk that campaign impact would be systematically overstated.
Task
Wesley needed to help turn Peloton’s Customer 360 and communications data foundation into a practical lifecycle measurement and experimentation operating model. The work needed to support winback, onboarding, cross-sell, upsell, retention, partner campaigns, product launches, recall-related communications, post-install check-ins, potential product issue follow-ups, subscription-owner campaigns, and nearly every non-transactional communications use case.
The team needed to define repeatable behavioral metrics, campaign-level and user-level measurement patterns, funnel-step conversion logic, and experiment designs that could distinguish true behavioral lift from ordinary customer behavior. Just as importantly, Wesley needed to help lifecycle and onboarding marketers plan measurement before campaigns launched, make decisions from the resulting data, and avoid overstating campaign impact when the evidence did not support it.
Action
Wesley and the team built communications-domain measurement around both engagement metrics and purpose-specific behavioral outcomes. At the communications level, they modeled open rates, click rates, delivery rates, bounce rates, unsubscribe rates, and user-level engagement across multiple time windows, including L7D, L14D, L28D, L60D, L90D, L180D, L365D, and lifetime. For multi-step campaigns, they tracked per-step engagement and conversion between steps, such as the share of users who clicked a step-two email and later clicked a step-three email.
The team then connected campaign engagement to the behavioral outcome each campaign was intended to influence. If an email was meant to shift workout frequency, they measured workout-related behavior before and after send, delivery, open, and click timestamps, enabling comparison at each funnel step. If a campaign was focused on purchase behavior, they analyzed sales-related metrics. If a campaign involved recalls, post-install check-ins, or potential product issues, they connected communications to customer support interactions, device signals, and user behavior. For subscription-owner campaigns, they incorporated billing-related metrics. This turned the communications layer into a sandbox for experimentation and impact measurement rather than a reporting surface limited to opens and clicks.
Wesley also helped the team use A/B testing and causal reasoning to challenge overbroad attribution claims. When stakeholders argued that recipients who did not open an email might still have seen it and changed behavior, the team compared received-but-not-opened populations against comparable cohorts intentionally held out from receiving the campaign. This helped test whether there was statistically meaningful lift beyond normal behavior. Even when marketing teams continued to overclaim some campaign impact, the work pushed them to make fewer and more tempered overstatements.
A major part of the work was change management and coaching. Wesley leaned on the strong partnership between the marketing technology team and the lifecycle and onboarding marketing teams. Building dashboards became straightforward once the relevant touchpoints were modeled, but getting marketers to make decisions from the data required close partnership. Wesley and the team coached marketers to define measurement plans before launch, clarify the expected behavioral shift, think in terms of experiments, and use the data proactively rather than reactively. Doing this before leadership pressure arrived made the discussions more collaborative and made it easier to shepherd the teams toward more data-driven campaign planning.
Result
The operating model supported more than 1,000 distinct campaigns across winback, onboarding, cross-sell, upsell, retention, partner campaigns, product launches, and nearly every non-transactional communications use case. The work served campaigns touching 5M+ members and 10M+ leads and supported stakeholders across growth, lifecycle, D2C, ecommerce, retail, B2B, commercial-captured leads, and adjacent business areas.
Targeting improved, conversion rates improved across target-behavior segments, and unsubscribe events dropped. Marketers gained clearer insight into communications engagement, funnel-step behavior, expected conversion patterns, and the actual behavioral outcomes campaigns were designed to influence. The work also improved the quality of marketing decision-making: teams became more likely to plan measurement before launch, use experiments to evaluate impact, and moderate claims when the data did not support full causal credit.
The broader result was that Peloton’s lifecycle marketing measurement moved from legacy segmentation and loose attribution toward a more repeatable experimentation and behavioral-measurement operating model. The Customer 360 and communications data foundation became not just a data asset, but a practical system for planning, measuring, and improving lifecycle customer engagement.
Showing Executives Why End-of-Month Promotions Created Activation Forecast Whiplash
During the experiment, the organization effectively killed the recurring bullwhip effect. Sales and onboarding output became more…
Business AnalysisChange ManagementData AnalysisForecastingJudgment and Decision MakingStakeholder Communication
Situation
At Brinks Home, executive leaders often believed activation and onboarding misses were caused by bottlenecks inside the onboarding team. Financial budgets were locked quarterly and then adjusted at the executive level to balance target expectations, while Wesley’s forecasts were built from actual observed conversion behavior across each step of the customer journey. When the financial budget and operational forecast diverged, the gap became highly visible to leaders across the organization.
A common failure pattern appeared near month end. Sales teams would run aggressive late-month promotions that boosted sales volume just enough to hit the sales budget for the month. However, those late sales did not leave enough time for equipment delivery, onboarding call scheduling, successful activation, revenue recognition, or operational capacity planning in the same month. The result was a recurring bullwhip effect: sales could claim a monthly budget hit, onboarding would still miss its activation budget, and the onboarding team would then be blamed for a timing problem created upstream. The first week of the next month, onboarding was left scrambling with higher inbound call volume, overloaded schedules, and operational stress from the late-month sales surge.
Task
Wesley needed to prove that the issue was not simply an onboarding bottleneck. He needed to show executive leadership that forecast misses were materially affected by timing, distribution, fulfillment delays, activation probability decay, and upstream sales behavior. The goal was to help leaders understand that hitting sales budget late in the month was not equivalent to hitting activation, revenue-recognition, or staffing targets in the same month.
The challenge was both analytical and political. Wesley had already built a forecasting method with strong measured accuracy, but proving model accuracy was not enough. He also needed to explain why the distribution of sales across the month mattered, why late promotional spikes created downstream operational whiplash, and why activation forecasts should be evaluated against the actual timing chain from sale to delivery to onboarding.
Action
Wesley reframed the executive conversation using activation-date analysis. Instead of only forecasting forward from sale date, he inverted the lens and showed, for each activation date, how long ago the underlying sale had been made. This exposed the same delay distributions from the opposite direction and made the timing problem much easier for executives to see. By tying the distribution back to record- and order-level data, Wesley showed that activation outcomes were constrained by sale timing, delivery timing, call scheduling, system complexity, and customer-specific factors rather than by onboarding effort alone.
He then analyzed activation falloff over time. As accounts aged, they became less likely to activate. Cumulative activation curves flattened hard around 25 days, with an inflection around 9 days. Wesley identified factors that influenced those curves, including system complexity, network-map coverage, credit reporting metrics, financing, and other account or order attributes. This helped leaders distinguish between normal operational timing, high-probability activation windows, and aging accounts that were unlikely to recover without intervention.
Wesley presented the analysis directly to senior leadership, including the COO, CMO, CEO, CAO, CTO, and several Sales VPs. He came prepared with core visuals and backup appendix slides for expected pushback. When executives asked “but what about X,” he could answer from prepared supporting analyses instead of letting the conversation lose focus. His proposals were to always run a soft credit check, freeze end-of-month promotions as an experiment, and publish weekly sales targets weighted more heavily toward the early part of the month. He received pushback about added friction and operational impact in the sales process, but leadership approved a two-month experiment.
Result
During the experiment, the organization effectively killed the recurring bullwhip effect. Sales and onboarding output became more reliable, tensions between teams eased, and the company reclaimed revenue that would have been lost or obscured in the noise of late-month promotional surges. Leadership gained a clearer understanding that the onboarding team was not the sole bottleneck and that sales timing, fulfillment timing, customer activation probability, and operational capacity all had to be managed together.
The work shifted the conversation from blame to system design. Instead of treating sales, fulfillment, onboarding, revenue recognition, and staffing as disconnected targets, leaders could see the timing chain that connected them. The analysis also reinforced a durable communication lesson for Wesley: in executive forecast conversations, backup slides are not optional. If a chart was useful during investigation, it should at least live in the appendix, because prepared answers to predictable objections can turn executive pushback into a reputation-building moment.
Building Brinks Home’s Activation Forecasting Model from Onboarding Calls to Upstream Sales Flow
The forecasting work gave Brinks Home a more durable operating view of the customer onboarding funnel. Operations leaders gained better…
Business AnalysisData AnalysisForecastingJudgment and Decision MakingOperations ManagementStakeholder Communication
Situation
At Brinks Home, Wesley’s core domain as a data analyst was activations and customer onboarding: the operational stage where newly sold customers moved through onboarding calls, successful onboarding triggered direct revenue recognition, and billing began according to the customer’s contract length. The onboarding organization needed to understand expected inbound and outbound call volumes, conversion rates, call complexity, and staffing needs. Some onboarding calls were predictably longer or more complex than others, and missed or poorly timed forecasts could affect operational capacity, revenue recognition, and budget attainment.
Wesley initially worked directly and closely with the Operations Director to forecast onboarding activity. As the work matured, he moved further upstream to analyze the two stages that fed onboarding: selling and fulfillment. The organization needed a better way to understand how sales flowed into delivery, how delivery flowed into onboarding, and how delays across those links affected daily, weekly, monthly, and quarterly operational forecasts.
Task
Wesley needed to build forecasting approaches that helped the business anticipate onboarding workload, staffing requirements, conversion outcomes, revenue-recognition timing, and upstream funnel pressure. The work needed to support operations leaders managing call volume and staffing, while also giving sales and executive leaders a clearer understanding of how end-of-month promotional behavior and uneven sales timing created downstream whiplash for fulfillment, onboarding, revenue recognition, and budget performance.
The analytical challenge was not simply to count sales. Wesley needed to estimate the expected distribution of delay between sale, delivery, and onboarding, and then connect that timing model to expected activation volume and revenue-recognition outcomes. The forecasts needed to work across different planning horizons — daily, weekly, monthly, and quarterly — and remain accurate enough over multiple years to support leadership conversations about sales behavior, operations planning, and business performance.
Action
Wesley began by modeling expected inbound and outbound onboarding call volumes, onboarding conversion rates, and call complexity. He analyzed which onboarding interactions were more likely to end successfully, which calls took longer, and which patterns could be anticipated early enough to inform staffing forecasts. This gave the Operations Director a more reliable way to plan activation capacity around expected workload rather than reacting after volume had already arrived.
He then expanded the model upstream into sales and fulfillment. Wesley analyzed the timing chain from sale to delivery to onboarding and developed a loose, inverted Cox-hazards-style methodology to estimate the expected distribution of delay between those stages. Rather than treating every sale as equally likely to activate on the same timeline, the model reasoned about the probability and timing of downstream onboarding based on observed historical delay patterns. This supported daily, weekly, monthly, and quarterly forecasting with relatively high confidence and measured accuracy over several years.
As the forecasting work became more trusted, Wesley used it to facilitate deeper conversations with sales and operations leadership, including SVPs, the COO, and the CMO. The model made visible why hitting forecast early in the month mattered: sales concentrated at the end of the month did not help the business hit intramonth activation, staffing, or revenue-recognition targets in the same way. It also clarified the downstream whiplash created by forced end-of-month promotions, where a late surge in selling could create fulfillment and onboarding pressure without solving the budget or forecast problem leaders thought they were addressing.
Wesley eventually moved further upstream again into lead capture and lead quality. He analyzed sales qualification, geographic area, financing and basket attributes, and other lead-level or customer-level signals that influenced downstream conversion points and forecast reliability. This connected lead generation and sales behavior to fulfillment, onboarding, revenue recognition, and staffing forecasts rather than treating each stage as a disconnected reporting domain.
Result
The forecasting work gave Brinks Home a more durable operating view of the customer onboarding funnel. Operations leaders gained better visibility into expected call volumes, conversion rates, call complexity, and staffing needs. Sales and executive leaders gained a clearer understanding of how upstream selling patterns, fulfillment timing, and end-of-month promotional behavior affected onboarding, revenue recognition, and forecast attainment.
The work also created the analytical foundation for later executive alignment around sales definitions. Because activation forecasts depended on the influx of sales, fulfillment timing, onboarding outcomes, and revenue recognition, discrepancies in what counted as a sale became a critical business issue rather than a semantic reporting disagreement. This led into the later sales-definition reconciliation work, where Wesley helped executives align on a trusted definition of sales for forecasting, accounting, and operational planning.
More broadly, the work shifted the business from reactive onboarding reporting toward an upstream forecasting model that connected leads, sales, fulfillment, onboarding, staffing, and revenue recognition. It helped leaders reason about not only how much demand existed, but when that demand would arrive, how operationally complex it would be, and which upstream behaviors created downstream forecast risk.
Measuring Peloton’s 1P Retail Locations as a Physical Acquisition and Conversion Funnel
The work produced dashboards and reporting, but its impact went well beyond analytics artifacts. The measurement strategy informed actual…
AttributionBusiness AnalysisData AnalysisData ModelingData VisualizationRevenue OperationsStakeholder Communication
Situation
Peloton’s 1P retail locations were physical acquisition, education, trial, support, and brand-experience surfaces, not just stores where sales either did or did not happen. From May 2023 through October 2025, Wesley worked on measurement for the owned retail footprint, which fluctuated between roughly 50 and 150 locations across the United States, Canada, and limited international presence in Germany and the United Kingdom. The analysis also incorporated historical data back to 2019.
The scale of the analytical universe included roughly 800,000 units of foot traffic, 200,000 formal retail leads, and 150,000 unit sales. Formal retail leads showed very high purchase intent: roughly 40% purchased in-store, while another large share converted later through third-party brick-and-mortar, 1P ecommerce, or third-party ecommerce channels such as Amazon. Because of that, store value could not be measured only through same-store sales or direct point-of-sale conversion. Leaders needed to understand which locations created meaningful demand, which local markets justified permanent retail investment, which interactions influenced downstream conversion, and how owned retail affected support, upgrades, and brand perception after the initial interaction.
Task
Wesley needed to help build the analytics and measurement strategy for evaluating Peloton’s 1P retail footprint as a distributed physical-location acquisition and conversion system. The work needed to support executive and operator decisions about store openings, closures, seasonal pop-ups, permanent inline stores, staffing, salesperson efficiency, compensation planning, inventory optimization, and the expected geographic reach of each location.
The core analytical challenge was to reconcile fragmented sources and lead records across a messy customer journey. Peloton needed to connect appointments, foot traffic, product trials, formal leads, in-store sales, extended ecommerce and other-channel sales, device usage and uptime, demo activity, Customer 360 profiles, and public geographic or MSA data. The measurement strategy also needed to account for direct and network effects: which stores produced direct sales, which stores created demand that converted elsewhere, how to weight different interactions in multi-touch attribution, and how physical retail fit into Peloton’s broader channel strategy.
Action
Wesley’s role evolved across the life of the work and often overlapped across several modes: analyst, architect, measurement strategist, manager, and executive partner. He helped stitch together retail, ecommerce, customer, device, and geography data so the business could connect in-person activity to downstream outcomes. The hardest part was reconciling lead records and customer journeys that could span an appointment, a showroom interaction, a formal lead, a later ecommerce purchase, a third-party retail purchase, post-conversion support, or product upgrade activity.
He framed store performance as a physical-location attribution problem rather than a simple reporting problem. Wesley and the broader team analyzed store- and agent-level efficiency, geographic reach, channel spillover, downstream conversion behavior, device readiness, and the relative performance of permanent owned locations versus seasonal pop-up engagements. The work incorporated appointments, foot traffic, trials, sales, extended ecommerce and other-channel sales, device usage and uptime, demo activity, Customer 360 attributes, and public geographic or MSA context. It also examined how different interactions should be weighted in multi-touch attribution and how retail activity influenced post-conversion upgrades, support needs, and broader brand image.
A major part of the action was stakeholder alignment. Executive support for the retail analytics agenda helped prioritize adjacent work around network effects, device uptime, attribution, and customer measurement that was not built exclusively for 1P retail but became essential to interpreting retail performance. Wesley helped align executives across retail, commercial, and marketing so the organization could reason consistently about physical-location performance and channel strategy instead of treating each channel as a disconnected reporting surface.
Result
The work produced dashboards and reporting, but its impact went well beyond analytics artifacts. The measurement strategy informed actual store closures, new openings, operational changes inside stores, salesperson compensation planning, staffing decisions, and inventory optimization. It helped the business evaluate the expected geographic reach of retail locations and compare permanent owned retail footprints against more flexible seasonal or pop-up strategies.
One important strategic finding was that “pulsing” store locations through pop-up-style engagements with lower real estate commitments often outperformed long-term inline stores in comparable geographies. This gave leaders a more nuanced way to evaluate physical retail investment: not simply whether a store produced direct sales, but whether a physical presence created enough acquisition, conversion, support, upgrade, and brand value to justify its real estate and operating model.
The broader result was a stronger operating framework for understanding Peloton’s 1P retail footprint as part of a multi-channel acquisition and customer-engagement system. Retail performance could be reasoned about through direct sales, network effects, downstream conversion, local market context, operational readiness, and customer experience. Because Wesley and the team built strong relationships with retail, commercial, marketing, and executive stakeholders, the analytics directly influenced major strategic and operational decisions rather than remaining a passive reporting layer.
Owning Peloton B2B RevOps Metrics, Revenue Measurement, and LTV Decisioning
The work gave Peloton's B2B function a more durable RevOps analytics foundation: revenue could be evaluated across devices, subscriptions,…
Analytics EngineeringData AnalysisData ModelingData VisualizationMetrics DesignRevenue OperationsStakeholder Communication
Situation
Peloton's B2B business needed a more rigorous operating model for understanding revenue, cost, churn, renewals, and long-term value across a complex commercial footprint. The business could not be measured only at a coarse customer or subscription level: leaders needed to understand performance by device, subscription, location, and partner, while also connecting revenue measurement to support cost, churn risk, renewal behavior, and targeting opportunities.
Task
Wesley played a central role in Peloton's B2B RevOps analytics function. He was responsible for creating and owning the metrics and analysis that helped the business understand per-device, per-subscription, per-location, and per-partner revenue measurement. The work also needed to support churn analysis, support-cost visibility, renewal strategy, and targeting optimization. A key part of the role was defining expected lifetime value across B2B functions and ensuring that B2B methodology could be compared and coordinated with the leaders and engineers building related LTV approaches for D2C.
Action
Wesley developed the analytical framing and metric logic needed to translate B2B activity into decision-ready business measures. He modeled revenue and value across multiple grains — device, subscription, location, and partner — so stakeholders could evaluate which commercial surfaces were creating value, which were underperforming, and how operational decisions affected long-term outcomes. He incorporated churn, support cost, and renewal behavior into the measurement framework rather than treating revenue as an isolated metric.
He partnered closely with B2B leaders to shape the questions the business needed answered and with engineering and analytics counterparts working on D2C lifetime-value methodology. That collaboration helped align B2B and D2C thinking while preserving the differences in how each business function created, retained, and measured value. The resulting work supported renewal targeting and optimization by giving leaders a clearer view of where intervention, partner strategy, or commercial investment could improve outcomes.
Result
The work gave Peloton's B2B function a more durable RevOps analytics foundation: revenue could be evaluated across devices, subscriptions, locations, and partners; churn and support costs could be considered alongside revenue; renewals could be targeted and optimized with better context; and expected LTV could be reasoned about across B2B functions in coordination with D2C methodology. This strengthened Peloton's ability to treat B2B analytics as an operating system for partner strategy, renewal planning, and long-term value creation rather than a set of disconnected reports.
Operating at Senior Manager Scope Before Formal Promotion
The Senior Manager promotion formally recognized scope Wesley had already been carrying for roughly 18 months. His leadership contribution…
At Peloton, Wesley’s formal promotion to Senior Manager happened after he had already been operating above his title for an extended period. When the promotion was announced publicly to the full department, his direct leadership chain stated that he had already been performing the role of a Senior Manager for roughly 18 months and that the promotion was overdue. His scope did not materially expand with the title change; the title caught up to the work he was already doing.
Task
Wesley needed to sustain Senior Manager-level scope while still formally holding the Manager title. The work was broader than managing a direct team: he needed to help build the enterprise data department’s operating model, improve talent systems, raise craft standards, support hiring and development, and keep delivery moving across a fast-growing analytics and data engineering organization.
Action
Wesley managed and coached his direct team while also contributing at the department level across the broader 30+ person data organization. He participated in hiring, coached and developed individual contributors outside his direct reporting line, co-authored leveling guidelines with the Senior Director, shaped expectations for analytics and data engineering craft, and helped establish standards, rituals, and operating practices that made the department more scalable. He continued operating as a player-coach: staying close to architecture and execution while helping other people grow into larger ownership.
Result
The Senior Manager promotion formally recognized scope Wesley had already been carrying for roughly 18 months. His leadership contribution extended beyond his direct team into the department’s talent model, standards, and operating system. This supports a broader department-building narrative while preserving the formal title chronology: he did not hold the Senior Manager title for the entire period, but he was publicly recognized by leadership as having performed at that level before the promotion became official.
Mapping Peloton’s Commercial Equipment Network into a Pre-Subscription Acquisition Funnel
The analysis changed how Peloton thought about commercial environments as acquisition, engagement, and brand-experience surfaces. It…
AnalyticsAnalytics EngineeringData AnalysisData ModelingData VisualizationRoadmap PlanningStakeholder Communication
Situation
Peloton’s commercial business placed connected fitness equipment in environments such as hotels, gyms, campus recreation centers, apartment complexes, corporate wellness settings, and retail trial locations. The strategic premise was simple but difficult to measure: prospective members should be able to experience Peloton wherever they were, without a consumer paywall. That raised several executive-level questions for Peloton for Business: whether commercial engagements benefited partner companies, whether they were profitable on their own, whether they positively reflected the Peloton brand, and whether they landed with Peloton’s target customer base. Beneath those questions was a more specific acquisition and engagement problem: which environments drove quality leads, what distinguished high-performing environments from low-performing ones, and whether Peloton could improve underperforming environments through better service, repair, equipment allocation, or partner strategy.
Task
Wesley was responsible for turning commercial equipment usage into an analyzable pre-subscription acquisition and engagement funnel. The work needed to distinguish subscriber and non-subscriber behavior, understand how different commercial environments performed, and give senior leaders and operators actionable guidance about device uptime, service prioritization, partner renewals, equipment placement, and lead quality. The analysis needed to span more than 30,000 devices, 10,000 locations, 5 million workouts, and 800,000 prospects across partners including Hilton, Hyatt, YMCA, UT Austin, University of Michigan, LA Fitness, and others.
Action
Wesley started as the lead analyst, engineer, and architect for the domain while operating as a team of one, then grew into formal management as the work expanded. He partnered closely with the SVP of Peloton for Business and that leader’s directs, and co-managed ground-operator relationships alongside a senior data analyst, an embedded Manager of Data Insights, and the Director of Commercial Experience. Wesley owned the roadmap, execution, readouts, strategy discussions, coordination, and major parts of the architecture through his departure in October 2025.
The team modeled workouts as events associated separately with users, subscriptions, and devices rather than assuming a fixed relationship between the three. User profiles could be associated with consumer subscriptions relatively directly, but temporary profile associations with commercial subscriptions required deeper domain work. Wesley and a senior analyst built up the attribution knowledge needed to identify commercial usage patterns, while commercial devices were flagged through complex temporal network and graph mappings. The analysis compared locations, geographies, equipment types, and environment types, separating existing subscribers who were “taking Peloton with them” from non-subscriber sampling behavior. It also surfaced behavior such as existing Bike owners trying Tread workouts in commercial gyms and regional differences in how commercial exposure translated into app or hardware conversion.
The work moved beyond generic usage reporting into environment-level segmentation and funnel interpretation. For example, apartment-complex usage showed the longest conversion horizon, roughly 12–24 months, which aligned with lease-cycle timing. Campus recreation centers converted more strongly to app subscriptions while showing degraded hardware conversion, which fit the demographics and ownership constraints of that environment. The team also identified saturation points — for example, cases where all bikes were consistently in use between 6–7 a.m. — and used those patterns to recommend whether to scale equipment up, scale it down, or redistribute devices across locations.
Result
The analysis changed how Peloton thought about commercial environments as acquisition, engagement, and brand-experience surfaces. It informed service and repair prioritization, including where technicians should be sent and which incidents deserved escalation based on lead quality, partner impact, and user experience. It shaped recommendations for how to stock or redistribute devices in partner locations when usage patterns showed saturation or underperformance. The work also supported commercial partner renewals by helping the team understand which locations contributed meaningfully to Peloton’s bottom line and where contract terms needed to reflect actual performance.
The fleet-health components became especially important in a high-profile project with Hilton leadership. Peloton identified that bikes were offline across North America, stitched together the relevant sources, made operational recommendations, and saw meaningful lift in device uptime and usage after the team executed. The same analytical approach became immediately applicable to 1P and 3P retail locations, where display and trial devices had different but comparable lead-capture mechanisms. Uptime and usage insights were also leveraged in contract negotiations with partners such as Dick’s Sporting Goods and Costco in North America. Overall, the work gave Peloton a durable framework for understanding commercial equipment not merely as deployed hardware, but as a measurable pre-subscription acquisition and engagement funnel.
Building Peloton’s Customer 360 and Lifecycle Experimentation Data Foundation
The Customer 360 and communications models became a durable substrate for personalization, lifecycle messaging, and behavioral measurement…
AnalyticsAnalytics EngineeringCausal InferenceData GovernanceData ModelingData QualityExperimentation DesignStakeholder Communication
Situation
In early 2023, Peloton migrated to Braze as its centralized marketing communications platform, with feeds from disparate sales, engagement, billing, customer management, and other enterprise systems. Much of the original pipeline logic had been shifted from older in-house destinations with the intention of auditing it later, but those audits did not happen; the teams and architects who built the logic later left the company. By the time Wesley picked up Peloton's Customer 360 work in May 2024, marketers and lifecycle operators were often guessing what fields meant, whether they were maintained, and whether they could safely be used for targeting. Some campaigns were being built from mislabeled or misleading columns, and consent or regional privacy mistakes could create legal risk. At the same time, Braze's native reporting gave clear directional delivery and open-rate metrics, but Peloton lacked a durable way to connect communications to downstream customer-level behavior.
Task
Wesley was responsible for helping turn fragmented, poorly understood customer and communications data into a governed customer intelligence layer that could support personalization, lifecycle messaging, experimentation, and reliable cross-functional decision-making at consumer scale. The work needed to span Customer 360 models, communications models, consent workflows, and nearly every centralized enterprise data domain, while remaining usable by marketers, lifecycle leaders, product teams, B2B operators, marketing analytics, product analytics, and the broader data organization. The resulting customer intelligence layer represented roughly 5 million users and more than 10 million records when including prospects.
Action
Wesley served as the managing leader and co-architect for the Customer 360 and communications data-modeling effort. He directly managed the lead analytics engineer and warehouse architect, coordinated architecture and timeline discussions across the broader working group, and contributed hands-on to orchestration strategy, testing mechanisms, and data contract negotiation. The team integrated sales and order activity, member engagement, social activity, billing and subscription status, commercial and corporate-wellness engagement, rewards-program activity, promotional-offer engagement, support interactions, retail interactions, survey responses, hardware ownership attributes, and many other customer-level features.
The highest-volume first-party sources — workouts and web events — were ingested using a change-data-capture pattern rather than full daily reprocessing: only new or updated workout and event records since the last successful run were pulled into the Customer 360 layer, which kept the pipeline performant at consumer scale and made backfills targeted rather than full-table reruns whenever an upstream source changed shape. This was necessary because full reprocessing of Peloton's entire historical workout and web-event volume on every run would not have been sustainable given the size of the estate and the freshness requirements from lifecycle and marketing teams.
The team made explicit tradeoffs between freshness and correctness — including Wesley's repeated framing of whether it was better to be "80% correct or 100% stale" — and clarified which attributes were truly critical for activation. Wesley also partnered with the communications platform team to implement safeguards in Braze and helped integrate Customer 360 into and back out of Peloton's dedicated consent platform.
For measurement, Wesley and the team worked with operators to define trusted campaign measurement strategies and a set of go-to behavioral metrics, such as average daily workouts over the last 7 days versus the last 30 days and last CFU product purchase date. They coached marketers on experiment design, sample-size requirements, statistical significance, sample bias, and causal inference techniques, moving Peloton from a state where lifecycle experimentation was functionally immature toward a reusable experimentation and measurement operating model. Wesley and his lead analytics engineer also presented key architectural decisions to the broader enterprise data team, including how to integrate new domains and attributes into Customer 360 and how to write Customer 360 outputs back into domain models without creating dependency loops. Those materials became a foundation for broader standards discussions and centralized design resources across Peloton's 30+ person enterprise data organization.
Result
The Customer 360 and communications models became a durable substrate for personalization, lifecycle messaging, and behavioral measurement across Peloton. Customer 360 v1 was delivered with a major architecture presentation in September 2024 and continued improving through at least May 2026. Communications models began in May 2025 and were delivered in July 2025 alongside experimentation-platform infrastructure. The system powered or supported an estimated 500–750 campaigns across winback, onboarding, cross-sell and upsell, retention, partner campaigns, weekly content picks, product launches, recall-related hardware communications, and more. The work served nearly every major vertical outside finance and legal, including lifecycle, product, international, ecommerce, content, commercial, corporate wellness, member support, supply chain, retail, hardware quality, customer insights, and B2B leadership. It gave Peloton a governed, consent-aware, enterprise-wide customer intelligence layer for roughly 5 million users and more than 10 million users/prospects, and it continued fueling communications campaigns after Wesley left the company.
Vitality AIA Workout Rewards Integration — Data Engineering for Reliable Partner Workflows
The system reliably processed roughly 50–200 workouts per day for about 800 enrolled Oceania members without manual intervention,…
Peloton partnered with Vitality AIA, a fitness-focused rewards partner in Oceania, to increase member engagement and market presence. The integration needed to capture member workouts, validate them against strict qualification criteria, and transmit eligible workouts to Vitality's REST API so members could receive reward points. The system had several reliability and trust risks: invalid account IDs, cross-market account-linking errors, API credential expiration, upstream data-quality changes, and mismatched workout-duration criteria that could incorrectly disqualify valid workouts.
Task
I led the initiative from technical service design through delivery and ongoing support. The work required more than a one-off integration: it needed an auditable, retry-safe data product that business, product, partner, support, and engineering teams could trust. I also used the project to mentor junior engineers on resilient pipeline design, idempotence, operational monitoring, and partner-facing accountability.
Action
I designed and delivered an end-to-end system using Airflow, dbt, Redshift, Python, S3, and REST API calls. Python scripts ingested workout and account-linking data using a change-data-capture pattern — pulling only new or updated workout and enrollment records since the last successful run, rather than reprocessing Peloton's full first-party workout volume on every cycle — which kept the pipeline fast and made it safe to backfill narrowly when something failed. dbt models encoded qualification criteria and tests, Airflow orchestrated the workflow, and every outbound API response was captured in S3 and Redshift for auditability. The pipeline was built to be idempotent and retry-safe, so failed or unsent workouts could be backfilled automatically instead of requiring manual repair.
I also handled the messy data-modeling parts of the integration: time-bound entity resolution for many-to-many account mappings, qualification logic based on enrollment state at the time of workout, and explicit reason codes for non-qualification. To make the system explainable, I created a Looker dashboard that surfaced every enrolled member's workout with its qualification status and reason, giving support and partner teams a definitive answer when members asked why points were or were not awarded.
During QA, Vitality testers flagged missing points for some workouts. Rather than treating the requirements as fixed or arguing from intuition, I analyzed actual workout-duration distributions and found that 99.5% of "20-minute" classes ran at least 18.5 minutes. I used that evidence to recommend a more accurate qualification threshold. Later, when an upstream system changed discipline labels from "bike" to "cycling," dbt tests and the health dashboard caught the falloff in transmitted events quickly. I updated the model logic and backfilled all unsent workouts in the next cycle.
Result
The system reliably processed roughly 50–200 workouts per day for about 800 enrolled Oceania members without manual intervention, including during upstream outages and API failures. Support inquiries became answerable from the audit trail rather than from guesswork. The integration supported Peloton's Oceania partnership investment while giving junior engineers reusable patterns for resilient data engineering: idempotent orchestration, explicit data contracts, auditability, observability, and business-facing explainability.
Stepping Back to Unblock Four-Team Coordination
The project was completed in less than 2 business days, versus the original 2-week estimate from managers. This unclogged development…
Judgment and Decision MakingLeadershipSystems Thinking
Situation
Four teams (your analytics team, data platform, marketing analytics, and marketing technology) needed to coordinate around repointing an ML model to a new centralized model. The downstream output also needed to be reintegrated into centralized models and served to marketing campaigns. All four individual contributors were competent with skill overlap, but managers were adding redundant voices to coordination meetings.
Task
You needed to decide whether to stay involved in the coordination meetings or step back, and you pushed your managerial peers to do the same.
Action
You recognized that the ICs had high skill overlap, low context overlap, clear deliverables, existing rapport with each other, and mature operating styles. You opted out of the coordination meetings entirely, removing managerial friction from the process and trusting the ICs to self-organize.
Result
The project was completed in less than 2 business days, versus the original 2-week estimate from managers. This unclogged development pipelines and became a story demonstrating how quickly the organization could move when cutting redundant managerial friction.
Scaling from Solo IC to Leading a Team of 7 While Expanding Stakeholder Coverage from 5 to 30+ Leaders
The team scaled from 1 to 7 people while stakeholder coverage expanded from 5 to 30+ senior leaders. Roadmap delivery remained…
ExecutionLeadershipManagement of Personnel ResourcesMentoringOrganizational DevelopmentRoadmap PlanningStakeholder CommunicationTeam Building
Situation
Wesley was brought into Peloton’s revenue-generating growth verticals as a solo hybrid engineer/manager supporting five senior leaders across 1P Retail, 3P Retail, Strategic Partnerships, Commercial, and International. His VP had stepped back to focus on Finance, which left Wesley responsible for technical delivery, stakeholder management, strategic planning, and ad hoc decision support across several business lines. As demand grew, the initial model created a bottleneck: too much context, too many stakeholder relationships, and too much technical ownership were concentrated in one person.
Task
As the team grew from one person to seven, Wesley needed to distribute ownership without losing stakeholder trust, delivery quality, or strategic coherence. He needed to match each team member to the right vertical, product area, and stakeholder relationship based on their strengths and growth potential while expanding coverage from 5 senior leaders to 30+ leaders and preserving the team’s reputation for reliable roadmap delivery.
Action
Wesley deliberately turned his solo operating model into a distributed team model. He mapped the work by business domain, stakeholder surface area, technical complexity, and team-member growth opportunity, then progressively transferred ownership rather than simply assigning tasks. He paired team members with verticals where they could build durable context, own recurring stakeholder relationships, and make decisions close to the work. He stayed close enough to coach, unblock, and protect quality while creating room for each person to become the trusted face of their domain.
He also built operating rhythms that made ownership visible: roadmap planning, business-facing prioritization, ad hoc request management, and review mechanisms that kept quality high without forcing every decision back through him. As the team matured, he moved from being the central executor to being an allocator of context, judgment, and accountability. The goal was not only to reduce his own bottleneck but to create a team that could sustain delivery, stakeholder trust, and technical standards without dependence on a single leader.
Result
The team scaled from 1 to 7 people while stakeholder coverage expanded from 5 to 30+ senior leaders. Roadmap delivery remained consistently high, with Wesley’s team delivering 90%+ of advertised roadmap commitments across 8 consecutive quarters. The scope and breadth of projects grew substantially while ad hoc request cycle time improved from roughly two-week delays when Wesley was solo to under one day 70% of the time and under two days 90% of the time by the end. Wesley became known for unusually strong stakeholder relationships compared with peers, and three team members were promoted: two Senior Analytics Engineers to Staff Analytics Engineer and one Analyst to Senior Analyst. The team continued to operate with high autonomy and sustained impact after Wesley transitioned out, demonstrating that the organization had become scalable rather than leader-dependent.
Designing Organizational Design Review Process to Eliminate Siloed Data Work and Reduce Operational Failures
Over 14 months, tier 1 Airflow failures dropped from 2-3/week to 1 every 3-4 weeks. Eliminated ~200 redundant models out of 1.5k (~13%…
Peloton's data organization was a patchwork of merged teams with siloed domains. The dbt data warehouse had ~1.5k models organized in separate lineage graphs with high redundancy, undocumented assumptions, and tangled Airflow DAGs. Teams rarely collaborated—engineers said "I don't want to bother them"—and lateral visibility was near zero. The organization was experiencing 2-3 tier 1 Airflow failures (on-call incidents) per week.
Task
You were responsible for creating visibility, breaking down silos, establishing technical standards, and improving operational reliability across a ~30-person distributed data department while enabling engineers to collaborate and reduce duplicate work.
Action
You designed a dual-track design review process: (1) Weekly "showcase" sessions (a hard gate for project development, attended by VP and ~30 people) where engineers presented work across models, dashboards, and exploratory analyses—creating cross-team visibility and engagement; (2) Biweekly roundtable with analytics engineers to discuss standards, friction points, and technical decisions. The roundtable produced formal documentation for model layering, naming conventions, orchestration, testing, and refresh strategies. You owned the showcase agenda, drove participation, and integrated it with broader initiatives (Tech Debt Extravaganzas, EDA Days). You also implemented lineage testing via dbt integrated into a containerized development environment to prevent future redundancy.
Result
Over 14 months, tier 1 Airflow failures dropped from 2-3/week to 1 every 3-4 weeks. Eliminated ~200 redundant models out of 1.5k (~13% deduplication). Models showed tighter testing, better documentation, and faster iteration cycles. Cross-team collaboration emerged (e.g., co-hosted user model refactor presentation). Automated lineage testing prevented future recurrence. Process was handed to Senior Director and continued to evolve after your departure.
Transforming a Struggling Inherited Team Through Psychological Safety and Distributed Ownership
The team delivered the long-overdue refactor in two weeks, just in time for a major product launch and months ahead of the prior…
Active ListeningCross-Functional CollaborationEmpathyExecutionLeadershipMentoringOrganizational DevelopmentProject ManagementTeam Building
Situation
You inherited two team members — an analytics engineer and a data analyst — from a struggling team that was siloed, behind schedule, and producing work other teams were hesitant to use. Their major refactor was roughly 6–9 months overdue and needed to land in time for a major product launch. The inherited team carried significant tech debt, missed commitments, and low morale. One analyst had been verbally and emotionally abused by a previous leader and had repeatedly been told she was bad at her job. Your existing team of about five had built a stronger culture of velocity, incremental improvement, and collaborative ownership, so the challenge was not only technical delivery but reintegration, trust repair, and sustainable performance.
Task
You were responsible for integrating the two inherited team members into your team, unblocking the overdue refactor, preserving your team’s roadmap credibility, and helping each person feel valued and capable. You needed to move quickly enough to support the product launch while avoiding the mistake of treating the problem as merely a project-management failure.
Action
Within 48 hours of the organizational shift, you held listening sessions with the new team members to understand their pain points, pressures, prior team dynamics, and sense of value. You broke the large refactor into smaller, visible, trackable tickets so the team could collaborate and make progress without being overwhelmed by the size of the inherited problem. You created space for the lead engineer to present the refactored work to the broader team, rebuilding trust and credibility around his technical work. You redistributed business-facing ad hoc requests across the team to share load and demonstrate that “everyone owns everything” was not just rhetoric. You and the existing team also got hands-on with the inherited codebase to validate the refactored work, build shared context, and create psychological safety around asking for help.
Result
The team delivered the long-overdue refactor in two weeks, just in time for a major product launch and months ahead of the prior trajectory. This unblocked features expected 3–6 months later. The previously mistreated analyst went on to mentor a more junior analyst and ran point on several major concurrent partnership launches. The team maintained velocity and held a three-week schedule buffer through your final two weeks, with team members sustaining performance independently after your departure. The story became evidence that strong support, psychological safety, and distributed ownership can unlock both human confidence and technical delivery.
Establishing Tableau as the Executive Reporting Standard and Training Organization
Tableau became the standardized tool for executive reporting across the organization. Data professionals gained confidence in using…
The candidate was responsible for acquisition-side executive reporting displayed in Tableau and fed through a SQL Server on-prem instance. The organization had multiple data professionals at varying skill levels who needed guidance on how to leverage Tableau and navigate the data warehouse. There was no standardized approach to building dashboards or training analysts.
Task
The candidate needed to serve as Tableau server admin, ensure system stability, and train an array of data professionals across the company on how to effectively use Tableau for their analytics needs while guiding them through the data warehouse structure.
Action
The candidate built parameterized dashboards with controls for frequently-asked-about attributes, making it easy for stakeholders to self-serve and explore variations without requiring custom queries. They conducted office hours with data professionals across the company, providing hands-on coaching and guidance. They documented and shared historical knowledge about the data warehouse structure and best practices. They maintained Tableau server stability and performance while scaling the platform to support more users and use cases.
Result
Tableau became the standardized tool for executive reporting across the organization. Data professionals gained confidence in using Tableau and the data warehouse independently. The candidate's parameterized dashboards reduced ad-hoc request volume and enabled faster decision-making. The organization developed a more data-literate workforce with consistent standards for analytics and reporting.
Modeling Mutable Sales Orders for Forecasting and Accounting Reconciliation
The model successfully handled order mutations and late-arriving facts, enabling accurate forecasting while maintaining accounting…
The candidate was tasked with building end-to-end customer onboarding data models from lead capture through first billing. The sales order model proved to be the most complex component because orders could be edited at any point in time—customers could add or remove line items, change payment methods, or modify quantities. This created significant challenges for both accounting reconciliation and forecasting accuracy, as the same order could have different contents when viewed at different points in time.
Task
The candidate needed to design a data model that could handle late-arriving facts and order mutations while providing both sales leadership with a consistent snapshot for forecasting and accounting teams with a complete audit trail for reconciliation.
Action
The candidate created a solution that functionally snapshotted orders based on criteria that couldn't change, while maintaining separate late-arriving facts for accounting reconciliation. They identified immutable qualifying events and status-change gates that would define when an order was "complete" for forecasting purposes. They then built dashboards showing both metrics side-by-side, with candlestick charts that categorized and explained the differences between the two definitions over time. The candidate conducted extensive training and explanation to get stakeholders on board with the different definitions and the reasoning behind them.
Result
The model successfully handled order mutations and late-arriving facts, enabling accurate forecasting while maintaining accounting reconciliation. Sales leadership and accounting teams gained confidence in the data. The candidate earned significant trust from senior leadership across the company through their ability to solve a complex technical problem that had business-wide implications. Connecting lead records to orders to customer records became straightforward once the foundational order model was established.
Aligning Executives Around a Single Definition of Sales
Executive leadership gained clarity on sales definition impact and shifted from skepticism to trust. The sales team stopped pushing back…
Cross-Functional CollaborationData AnalysisData VisualizationJudgment and Decision MakingRelationship BuildingStakeholder CommunicationTableau
Situation
While building customer onboarding forecasting models, the candidate discovered that Accounting and Sales teams had been using conflicting sales definitions for years without reconciliation. Numbers shifted unexpectedly, threatening forecast credibility. Multiple stakeholders across the organization were pulling the same metric in different directions, and the CMO struggled to explain the sales definition during an executive boardroom meeting focused on funnel diagnosis.
Task
The candidate needed to identify the root cause of the sales definition discrepancy, build a solution that both teams could trust, and present findings to executive leadership (COO, CEO, CMO, Sales VPs) in a high-stakes boardroom setting to align the entire organization on a single definition.
Action
The candidate diagnosed the problem by connecting with stakeholders adjacent to the customer onboarding process and learning how each was interpreting "sale" differently. They took ownership of tracking down why numbers shifted and getting everyone aligned. They built Tableau dashboards specifically designed to compare variations in sales definition criteria, including parameters and controls for hot-button attributes that stakeholders frequently questioned. When called into the executive boardroom, they used Tableau to live-filter and show the deltas, demonstrating how shifting sales dates by a few days based on different criteria could drastically impact budget attainment, forecasts, and quotas. They also created candlestick charts to visualize and categorize reconciliation differences between the two definitions.
Result
Executive leadership gained clarity on sales definition impact and shifted from skepticism to trust. The sales team stopped pushing back against the candidate's analyses and recognized they could rely on the candidate to explain any future deltas. The candidate was given increased authority in sales team training and moved from being seen as a critic of sales methodology to being a trusted technical advisor endorsed by senior leadership. The organization achieved alignment on sales definitions, enabling reliable forecasting and accounting reconciliation.
Philosophy
Decision making
Data-Driven Threshold Setting
When facing ambiguous requirements or conflicting signals (like whether "20-minute" classes should qualify), don't argue or guess — collect data, analyze the distribution, and let the empirical evidence inform the decision. Present findings to stakeholders and adjust criteria to match real-world behavior.
Leadership
Learning Readiness & Environmental Design
You can't teach someone a lesson they aren't ready to learn. Managing the learning environment and making the lesson relevant to the student are both extremely important.
Leadership
Psychological Safety as the Foundation for High Performance
Strong culture of support and psychological safety is the best antidote to low performance and disengagement. Confidence injection through trust-building, not just technical fixes, unlocks velocity and capability. People perform at their best when they feel valued, safe to ask for help, and supported by peers.
Leadership
Playing to Strengths Over Forcing Fit
Deliberately match team members to opportunities based on their individual strengths, interests, and growth potential rather than forcing them into predetermined boxes. Create space for people to succeed by aligning their capabilities with business needs simultaneously.
Leadership
Delegation as Strategic Leverage, Not Task Offloading
I don't delegate work just to free up my time—I delegate to create growth opportunities for my team members and to match them to problems where they can excel and own outcomes. The goal is to identify where team members can help me AND the business simultaneously, creating space for me to reinvest in them and focus on higher-leverage activities.
Leadership
Data Teams Should Be the Most Data-Driven Group in the Company
Data and analytics teams should be the most data-driven group in their own company — not just the group that supplies data-driven decisions to everyone else. If any other business function operated the way most data orgs operate internally — without instrumented visibility into their own throughput, quality, or ROI — they'd be the first ones raising alarms about "flying blind." Data teams rarely hold themselves to that same standard.
This matters because data and analytics work has historically struggled to tie itself to fiscal value. Without instrumentation of the function's own output — velocity, reliability, ramp-up, incident cost, tooling ROI — there's no credible way to make the case for further investment, and no way to know whether the org is actually improving. You can't argue for growth in a function you refuse to measure.
In practice, this means treating the data org itself as a first-class subject of analysis: instrumenting engineering velocity and developer experience the same way you'd instrument a customer funnel, building objective, evidence-based systems for talent calibration and promotion instead of manager intuition, and tracking reliability (SLA adherence, incident rates) with the same rigor applied to production data products. Anecdote is not a substitute for measurement, even — especially — when the subject is your own team.