Analytics Engineering Tech Lead, Scribd

• You are equally comfortable as the modeler and the analyst. You can build the pipeline, define the metric, and defend the number in a room full of executives
• You are skeptical by default. When payment success rate drops four points, your instinct is to go find the field that changed meaning, not to write the narrative. You have opinions about how payments data should be structured to prevent misleading narratives
• You are pragmatic. You ask what the right next version is, and you use AI where it creates measurable value
• You communicate early and plainly, and you write things down. Methodology and model documentation are part of the deliverable
• 8+ years of experience in analytics engineering, data engineering, business intelligence engineering or a related discipline
• Deep, hands-on payments expertise: including direct experience with processor data from Stripe, Adyen, Braintree, PayPal, or similar
• Practical experience with identity and authentication data
• Depth in governed, canonical data models and semantic layers, and a track record of defining a metric, defending it under scrutiny, and versioning it when its inputs changed
• Advanced SQL and production experience with Databricks, AWS, Looker, Airbyte, Fivetran, or comparable platforms, including orchestration, transformation frameworks, and automated testing
• Experience making data reliable for AI consumption
• Proven ability to influence senior product and engineering leaders and translate complex payment economics into clear business trade-offs

Desirable

• This role supports the pillars that own payments, identity, security as well as trust & safety systems — the foundations that let Scribd securely monetize and protect its products. It is the senior-most analytics engineering role for these pillars and a purely technical leadership position with no direct reports
• You will report to the Director, Analytics Engineering, and work embedded alongside Product Analytics, Data Science, Product, and Engineering partners
• Mandate. Give core business concepts one authoritative definition, and make sure the numbers survive a PSP migration, a schema change, or a new market launch without silently going wrong. For Trust & Safety, make it possible to say with confidence how much violating content exists on Scribd and how much of it users see with numbers that stay comparable as moderation models, policies, and review processes change
• Core philosophy. A metric definition is an engineering artifact. We care about lineage, observability, and data quality as much as the dashboard on top — because a number that quietly breaks upstream is worse than no number at all
• Own the canonical data models for payments, billing, and subscriptions in Databricks modeled once across Scribd, Everand, and Fable so a new market, or payment method doesn't require a rewrite, and built with the next engineer and the AI tools on top as explicit consumers
• Own the KPI and semantic layer for payments and identity exposed through self-serve dashboaring/AI tools
• Extend the same discipline to Trust & Safety, owning the models and metrics behind prevalence and exposure, including evaluation of AI-generated moderation labels
• Drive quality, observability, and lineage so a regional login challenge rate change or processor routing change is caught in days, not quarters and root-cause discontinuities to separate real customer or processor behavior from migration artifacts and data quality issues
• Build AI tools on trusted foundations, grounded in certified metrics and tables, kept in sync as definitions change, and validated with evaluation sets that prove the answers are right
• Raise the technical bar, set modeling and metric conventions, influence source-system changes before they land, and mentor analysts and analytics engineers in these domains