Senior Engineering Manager

Nexla is the data layer for enterprise AI. We give AI apps and agents the connectivity, context, and governance to work across more than 1,000 enterprise systems in real time, and we process over a trillion records a month doing it. DoorDash, LinkedIn, Johnson & Johnson, Instacart, and LiveRamp run mission-critical data on us. Honorable Mention in the Gartner Magic Quadrant™ for Data Integration Tools, and top-rated by customers on Gartner Peer Insights four years running. Founded 2016, remote-first, headquartered in San Mateo.

Our values are short and we actually use them: Have Empathy. Be Curious. Be Intellectually Honest. Achieve Excellence. Remember to Relax.

• The architecture across connectors and runtime. How we abstract a thousand systems, how we handle JSON, Parquet, and Avro at throughput, how work gets scheduled and recovered when a node dies. You make those calls and you write the hard parts yourself.
• Reliability of everything your team ships, on-call included. Fewer failures reaching customers, faster detection when they do, and a release and test path that catches the obvious things before a customer does.
• What ships and in what order. You work directly with product, customer success, and support on what customers actually need, and you decide what gets built, what gets deprecated, and what waits.
• The engineers around you. Hiring, growth, and raising the technical bar, mostly through design review and pairing rather than process. As the team grows you will build tech leads under you and hand off implementation ownership, without handing off architectural accountability.

Ninety days in: you have shipped something non-trivial to production, named the two worst parts of the current design with a proposal attached, and the team has started routing hard design questions to you before they route them upward.

• 12+ years building backend systems, and you are still hands-on. You can point at code you wrote recently and are proud of.
• Deep JVM experience. You have debugged distributed systems where the failure was not in the code you wrote.
• Production depth in Kafka, Kubernetes at high throughput, Redis or Memcached, and APIs over gRPC and REST.
• You have led engineers technically and carried direct reports: design review, mentoring, hiring, and the harder performance conversations.
• You use AI tools in your actual work and can say specifically where they help and where they mislead you.

• Data integration, ETL, or iPaaS background.
• Experience with Ray, Spark, or Flink for distributed or AI data processing.
• You have run DevOps and QA alongside an engineering team and know what good looks like in both.

• Urgency is your default. You'd rather ship a good answer this week than a perfect one next quarter, and you make that call without being asked.
• You own the outcome, not your slice of it. When something breaks between two teams, you fix it rather than route it.
• You close loops. What you pick up gets finished, and the people around you stop having to follow up.
• You set the pace. The team will calibrate its urgency to yours, and you know that.
• You want design authority across a wide surface without giving up the keyboard.

One thing to be clear about: this is a broad team and a broad stack, and you will not be the deepest expert in every corner of it. What we need is someone with the judgment to know where to go deep and the honesty to say when they are out of their depth.

How we hire
Five conversations, about one to two weeks end to end.

• Low-level design. Working through real code and real design detail rather than a puzzle. 60 min.
• High-level design. How you shape systems at scale: throughput, failure modes, and the tradeoffs you would defend under pressure. 60 min.
• Call with our Head of Product. How you work with a product: what you push back on, how you sequence, and how you decide what does not get built. 45 min.
• Bar Raiser with our CTO. Sign-up for Express.dev, use the product and prepare a presentation on how you would make our product better. 30 min.
• Call with our CRO. Ownership, judgment, and how you raise the bar of the people around you. 45 min.

• →What we are building now. MCP Studio and Express, our two newest bets.
• →Who uses us, and why. nexla.com/customers
• →The product in engineer terms. docs.nexla.com
• →Our CEO on why we take "Remember to Relax" seriously. Read the founder story
• →Everything else. nexla.com  ·  Blog  ·  All open roles

A few large companies - DoorDash, SentinelOne, Johnson & Johnson, LinkedIn, Amex, Integrity Marketing, among them use Nexla for data integration. Connectors, runtime, transformations, scheduling, the parts of the stack where data has to move between systems reliably.

The reason this is an interesting moment to join is what the agent shift is doing to the category. Data integration used to mean "land this data in that warehouse so a human can look at it." That product is mature. What it's becoming is closer to "an agent asks a business question, and the platform figures out which data and what code and which APIs add up to a real answer." That's a much bigger problem, and most of the architecture for it hasn't been built yet by anyone.

A concrete example. A revenue team wants to ask "which enterprise customers are showing renewal risk" and get a real answer through whatever agent or app they work in. Today there is no clean way to answer that question, it requires CRM, usage, support, and billing data joined in org-specific ways, and the calling agent can't just invoke a tool that returns the right answer unless someone first establishes whether the underlying data is even capable of producing one.

That is the system we are building. A probe agent investigates the data plane whether the right fields are populated, whether freshness is adequate, whether the joins exist, whether credentials cover the required scope and returns a grounded feasibility answer. Where there are gaps, Express.dev composes the pipelines to close them. The capability is then exposed as an MCP server: "renewal risk" as a curated product, with the business logic correct and the query semantics described well enough that the calling agent uses it as intended. The MCP Gateway governs which agents can call which capabilities, with the policies, audit, and observability an enterprise control plane requires.

The bet is that ten years of connector work, an enterprise customer base, and a runtime that already moves real volume are the right foundation to define this layer from.