Member of Technical Staff

Technical Staff Engineer Role

Members of Technical Staff (MTS) are the senior engineers who build the platform that everything else at Beacon runs on. You will own a piece of the core stack end-to-end: design, implementation, operations, and the long-term technical direction of that area. This is a Staff Engineer role in everything but name. We run flat. The work is systems engineering at its core.

Multi-tenant data infrastructure across very different portcos. Event-driven pipelines that have to be correct under partial failure. Service architectures that have to stay simple as the product surface grows. APIs and SDKs that other engineers — including FDEs out in the field — will build on every day. ML and agentic systems are part of the stack. They sit on top of a foundation that has to be solid first.

This is not infrastructure for its own sake. The platform has to be solid before anything else at Beacon works. That is the job.

You will own one of these areas end-to-end:

• Data platform. The cross-portco data lake on Iceberg with Snowflake or Databricks as the query engine. Per-portco S3 and KMS isolation. The ingestion pipeline from Quick Books, Hub Spot, Salesforce, Post Hog, Intercom, Linear, Slack, Gmail, Postgres, Stripe, Zendesk, and our internal tools. The canonical data model that survives contact with very different portcos. The catalog and semantic layer on top so a query like "show me sales across all portcos" actually resolves.
• Core services and APIs. The backend services that everything else at Beacon depends on: identity, access control, audit, workflow orchestration, the internal APIs that FDEs and ops engineers build against. The bar here is not novelty. It is correctness, latency, observability, and the kind of API design that ages well.
• Multi-tenant isolation. Per-portco data, compute, and credential boundaries. Cross-cloud (AWS and Azure) connectivity. Regional residency for portcos in regulated verticals. This is the unglamorous infrastructure work that determines whether we can onboard portco 50 as fast as portco 5.
• Workflow and action runtime. The execution layer that runs operational workflows across the three domains. Typed action surfaces, idempotency, retries, rollback paths, human-in-the-loop approval gates, audit trails. Some workflows are scripted. Some are model-driven. The runtime treats them as variations of the same primitive.
• Observability and evals. The harness that tells us whether the system is working: traces, metrics, structured logs, replay infrastructure, regression suites, the ability to safely A/B-test changes across the portfolio. Both for traditional services and for model-driven workflows.
• Safety and blast radius. Wrong actions against a portco's customers, revenue, or product are the worst kind of mistake we can make. Designing the autonomy tiers, the kill switches, the per-action-class blast-radius caps, and the audit surfaces is foundational platform work, not an afterthought.

• Senior engineering depth. Staff or principal-equivalent. You have built and operated systems that real businesses depend on. You write clean, idiomatic code in at least one of Python, Go, Rust, or Type Script, and you can work in any of them. You have an opinion on how to structure a service and you can defend it without raising your voice.
• Distributed systems intuition. You have lived through enough production incidents to know where things actually break. Idempotency, partial failure, retry semantics, eventual consistency, schema evolution, multi-tenant isolation. These are not concepts you read about. They are things you have debugged at 2am.
• Data infrastructure experience. You have built or operated something non-trivial on a modern data stack:
  Kafka, Spark, dbt, Iceberg, Snowflake, Databricks, Big Query, or comparable. You understand the difference between a warehouse and a lake, and when each is the right answer.
• Platform mindset. You build for the engineer two seats over as much as for the end user. Your APIs are easy to use correctly and hard to use incorrectly. You write the documentation. You make the migration path obvious. You treat developer experience as a…