Tech Lead Manager - Autonomous Connectors

What we are building

We are building an AI system that creates data connectors by itself and keeps them working by itself.

No engineer should need to manually build every connector. No engineer should need to come back six months later because the source API changed.

Work that traditionally takes weeks or months should take hours. But building a connector is not the hardest part.

The real question is: Would you trust this system to run by itself, with nobody watching, for months?

That is the job.

The Problem

Every data company has the same problem. There is always another source a customer wants that you do not support.

Today, supporting that source means an engineer has to understand the API, implement authentication, pagination, schema handling and incremental syncs, test the connector, deploy it and maintain it indefinitely.

We want an agent to do most of this autonomously.

It needs to understand API documentation, generate connector logic, validate the data and deploy the connector.

Then the harder part starts.

APIs change. Schemas evolve. Authentication breaks. Rate limits change. Fields disappear. New failure modes appear in production.

The system needs to detect those changes, understand what happened, decide whether it can safely repair the connector, validate the fix and know when to ask a human for help.

“The AI built it” is not good enough. The connector has to be correct.

If a connector silently produces bad data, a customer dashboard may be wrong and someone may make a bad decision based on it.

Your job is to make autonomous connectors trustworthy.

Your Role

• You will lead a team of 4 to 6 engineers while continuing to be deeply technical.
• Roughly 60 percent of your time will remain hands on. That includes architecture, design, coding, debugging, evaluations, code reviews and production issues.
• This is not a people management role with occasional coding.
• You will own a major part of the Connector Builder Agent, along with parts of our existing connector platform and database connector infrastructure.
• Other teams will own other parts of the system. You will work closely with them.
• Exactly what you own will depend on your strengths and what the team needs when you join. We would rather build the role around a strong engineer than put someone into a fixed box.

What you will work on

The central problem is deciding what the system can safely do by itself and where it needs human intervention.

You will work on problems such as understanding API documentation automatically, inferring authentication and pagination, discovering schemas, handling schema evolution, generating connector code, detecting API changes, repairing failures, scoring confidence and building evaluation systems that tell us whether an autonomous action was actually correct.

You will also help answer harder questions.

• How do we know a generated connector is correct?
• Which failures can an agent repair safely?
• When should the system stop and ask a human?
• How do we catch an API change before the customer does?
• How do we ensure that a model upgrade does not silently degrade hundreds of connectors?
• How do we test systems whose outputs are not deterministic?

These are the problems you will help solve.

What success looks like

• Within your first few months, you should form a clear view of what trusted autonomy means for the systems you own.
• You should establish measurable correctness criteria, build strong automated evaluations and define clear confidence thresholds and escalation paths.
• Within six months, we expect your part of the system to autonomously build or maintain a meaningful class of connectors with measurable reliability.
• You should also have raised the technical bar of the team around you.

The leadership part

• You will hire 2 to 3 engineers over the next year.
• You will help them become significantly better engineers.
• A year after joining your team, people should be solving harder problems than when they started. Some should be ready for promotion.
• If growing engineers does not interest you, this is probably not the right leadership role.
• You should already be the person engineers come to when the problem is difficult, even if you have never had a formal management title.
• When something breaks in production, you want to understand why.
• Not because we expect people to work all the time, but because you care whether the systems you build actually work.

Who will thrive here

• You have built serious backend, infrastructure or distributed systems.
• You have also built real systems with LLMs and have experienced the gap between something working in a demo and surviving production.
• You have dealt with outputs that change between runs.
• You have built evaluations around probabilistic systems.
• You have had to decide when a model should act autonomously and when deterministic software or a human should take over.
• You want to lead engineers without giving up engineering.
• You are comfortable working on ambiguous problems where the architecture is not already known.

Who this role is probably not for

• If you want to stop coding and become a full time people manager, this role will not work.
• If your experience with LLMs is primarily prompt engineering or prototypes, the jump will be significant.
• If you strongly prefer systems where correctness can be completely captured through deterministic code and unit tests, this problem may be frustrating.
• We pay competitively, but compensation alone is unlikely to be the reason someone chooses this role.
• The reason to join is the problem itself, the ownership you will have and how early the technology still is.

What we look for

• You have at least 8 years of experience building backend, infrastructure or distributed systems.
• You have at least 1 year of technical leadership experience, with or without the formal title.
• You have operated production systems and dealt with incidents, on call, reliability and SLAs.
• You have built and operated an LLM powered system in production where correctness, reliability, latency or cost mattered.
• You have hands on experience with areas such as agents, evaluations, retrieval, tool use, model failure modes or reliability.
• You have experience with multi tenant systems, high availability or large data volumes.
• Our stack is primarily Java and Kubernetes. If you are strong in another JVM language or a similar systems language, you should be able to ramp quickly.
• Experience with data infrastructure, CDC, ETL, database internals or open source systems is useful but not required.
• Strong systems engineers can learn the domain.

Your first three months

In your first month, learn how our connectors work today, where the agent performs well, where it fails and how the team operates.

In your second month, form your own view of what trusted means for your area and begin building the evaluations and reliability mechanisms needed to prove it.

By your third month, you should be making architecture decisions, taking ownership of a major part of the system and starting to hire.

Why this role

• Very few teams are building autonomous AI systems that operate production infrastructure where being wrong has real consequences.
• This is not a chatbot. It is infrastructure that has to remain correct, quietly, for months.
• If that kind of problem excites you, there are not many places working on it this early.
• You can talk to anyone in the company, including the CEO.
• Architecture decisions in your area are yours.
• What you are trusted with depends on what you can do, not your title.
• Several of our engineering managers started as senior engineers.